security-mcp 1.1.4 → 1.3.1

package/skills/linddun-privacy-analyst/SKILL.md

@@ -194,3 +194,105 @@ If internet permitted:
 - `requiredActions`: ordered action list
 - `complianceImpact`: framework mappings
 - `beyondSkillMd`: true — this agent is entirely beyond-policy
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "PII-rich endpoint or data store identified during LINDDUN analysis", "exploitHint": "Exfiltration via IDOR, mass-assignment, or analytics SDK misconfiguration" }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "SHA-256 email hash used as pseudonym (reversible via rainbow table)", "location": "src/models/user.ts" }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "Third-party analytics SDK with unconstrained webhook callback URL", "escalationPath": "SSRF to instance metadata → IAM token → S3 PII bucket" }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["GDPR Art. 35", "CCPA §1798.150", "HIPAA §164.514"], "releaseBlock": true }]
+  }
+}
+```
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **LLM-Assisted Re-identification of "Anonymised" Datasets (CWE-359 / ATT&CK T1530 / Sweeney 2002 k-anonymity paper):** Adversaries feed quasi-identifier fields (ZIP code, DOB, gender, device type) into an LLM alongside public data sources (voter rolls, LinkedIn, breach dumps) to collapse k-anonymity at scale — a re-identification attack that statistical models underestimate. Modern LLMs reduce the data-point threshold for re-identification from 5+ fields to as few as 2–3 correlated attributes. Test by: extract all non-PII attributes from each data model; prompt GPT-4o with the combination and a public dataset (e.g., US Census) and ask it to identify a specific individual; flag any schema where the LLM produces a confident match with < 5 quasi-identifiers. Finding threshold: any entity record with k < 5 under LLM-assisted adversary model.
+
+- **Harvest-Now-Decrypt-Later Attack on Pseudonymised Tokens (NIST IR 8413 / PQC Migration / FIPS 203 ML-KEM):** Nation-state actors archive TLS-captured traffic today containing pseudonymised identifiers encrypted with RSA-2048 or ECDH P-256. When cryptographically relevant quantum computers (CRQCs) arrive (~2030 per NIST), these tokens become fully reversible. Any PII pseudonymised with RSA-based key exchange that must remain private beyond a 5-year horizon is already compromised. Test by: inventory all pseudonymisation key exchange mechanisms (`grep -r "RSA\|ECDH\|P-256\|rs256\|ES256" src/`); check data retention policies — flag any PII-bearing token stored beyond 5 years without post-quantum migration plan. Finding threshold: any long-lived pseudonymous identifier using pre-quantum cryptography with retention > 5 years.
+
+- **Consent State Stale Cache Exploitation via Async Worker Race (CVE-2023-28432 class / ATT&CK T1499.003):** Background workers (email queues, retargeting exporters, recommendation engines) read consent state from a Redis or in-memory cache seeded at job-enqueue time. A user withdraws consent and the DB record updates, but the already-enqueued jobs carry a stale consent snapshot and complete the processing — violating GDPR Art. 7(3) right to withdraw consent. This was observed in real-world GDPR enforcement actions (e.g., Meta's 2023 €390M fine for consent bypass via "legitimate interest" fallback). Test by: withdraw consent for a test user via the API; immediately inspect the job queue for enqueued tasks referencing that userId; confirm each job re-reads live consent state (`grep -r "consent" src/workers/ src/queues/`); measure delay between consent revocation and job suppression. Finding threshold: any job that completes PII processing > 5 seconds after consent revocation.
+
+- **Analytics SDK PII Leakage via Auto-Captured URL Parameters (Real Incident: Meta Pixel HIPAA breach 2022 / ATT&CK T1567.002):** Third-party analytics pixels (Meta Pixel, Google Analytics, Segment auto-track) capture `window.location.href` and `document.referrer` before any application-layer sanitisation runs, exfiltrating PII embedded in query parameters (e.g., `?email=user@example.com`, `?userId=123`, `?token=abc`). The 2022 Meta Pixel healthcare breach affected 3M+ patient records across 33 hospital systems. PII-in-URL is invisible to server-side log analysis. Test by: use Playwright to load every authenticated page with a synthetic PII-laden URL (`?email=test%40evil.com`); intercept all outbound HTTP requests via `page.on('request', ...)`; flag any request to a third-party domain that contains the injected PII value. Finding threshold: any third-party beacon containing PII present in the page URL.
+
+- **Right-to-Erasure Gap in ML Training Snapshots and Cold Storage (GDPR Art. 17 / ATT&CK T1530 / EU AI Act Art. 10):** GDPR Art. 17 erasure requests are satisfied for the live database but PII persists in: S3/Glacier data lake snapshots, BigQuery export tables, Elasticsearch document indexes, ML model training datasets, and CDN-edge-cached profile pages. The EU AI Act (enforcement 2026) additionally requires that high-risk AI systems support data subject rights in training data — i.e., the right to have one's data removed from a training set. Regulatory audits now enumerate all downstream stores. Test by: build an erasure verification job that queries each registered downstream system for a deleted userId 72 hours post-deletion (`SELECT * FROM bq_export WHERE user_id = ?`; Elasticsearch `GET /users/_doc/{id}`; `aws s3 ls s3://snapshots/ | grep {userId}`); flag any non-zero result. Finding threshold: PII present in any downstream store 72 hours after erasure request.
+
+- **Timing and Response-Size Side-Channel for User Presence Inference (LINDDUN Detecting / CWE-203 / ATT&CK T1592.002):** Authentication and account-lookup endpoints that return differential response latency or content-length for "user exists" vs "user not found" allow an adversary to enumerate valid user accounts — violating the LINDDUN Detecting threat category — without any PII being returned in the response body. This class of oracle was exploited in the 2016 LinkedIn scraping campaign and is present in most OAuth 2.0 password-reset flows. Content-scanning and SAST tools pass because no PII appears in the response. Test by: send 1,000 requests each to a known-valid and known-invalid identifier against `/auth/login`, `/auth/forgot-password`, and `/api/users/{id}`; compute p50/p99 latency delta and Content-Length delta; flag if latency delta > 5 ms or content-length delta > 50 bytes across the distribution. Finding threshold: statistically significant delta (t-test p < 0.05) between hit and miss response timing or size.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 privacy attack cases in the LINDDUN domain that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | Quasi-identifier linkage attack | Scanner flags explicit PII fields (email, SSN) but ignores indirect combinations: ZIP + DOB + gender re-identifies 87% of Americans (Sweeney). No single field triggers an alert. | Extract the set of non-PII attributes per data model; run k-anonymity check — flag any combination with k < 5 across realistic user population |
+| 2 | Analytics SDK silently forwarding PII via URL or referrer | Third-party pixels and analytics snippets capture the full page URL including query params (e.g. `?email=user@example.com`) before any sanitization runs. Scanner tests API responses, not browser-sent requests. | Audit every analytics integration for auto-capture scope; search for `window.location.href`, `document.referrer`, `utm_*` patterns logged alongside user sessions; replay with a synthetic PII-laden URL |
+| 3 | Right-to-erasure gap via derived data stores | User record deleted from primary DB but PII persists in: search indexes (Elasticsearch/Algolia), ML training snapshots, cold-storage analytics exports, CDN-cached profile pages. Scanner only checks the primary DELETE code path. | Enumerate every downstream system in the data flow diagram; for each, verify a deletion propagation mechanism exists and is tested with a real erasure call |
+| 4 | Consent state not propagated to asynchronous workers | Consent withdrawn on the frontend; the revocation event is written to the DB. However, background jobs (email queues, recommendation engines, retargeting exports) read a stale consent cache and continue processing. Scanner audits synchronous code paths only. | Trace consent-check logic into every async consumer (queues, crons, webhooks); confirm each re-reads live consent state rather than a cached snapshot |
+| 5 | Fingerprinting via timing or response-size side-channels (Detecting threat) | No PII is returned in the response body, so content-scanning tools pass. But differential response latency or byte-length for "user exists" vs "user not found" allows presence inference — violating the LINDDUN Detecting category. | Measure p50/p99 response time for existing vs non-existing identifiers across 1000 samples; flag if delta > 5 ms; similarly diff response Content-Length |
+
+---
+
+## §TEMPORAL-THREATS
+
+Privacy threats materialising in the 2025–2030 window that LINDDUN-informed defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to Privacy Domain | Prepare Now By |
+|--------|--------------|------------------------------|----------------|
+| Harvest-now-decrypt-later attacks on pseudonymised data | 2025 (active) | Adversaries archive encrypted PII today to decrypt once CRQCs arrive; pseudonymisation via RSA-based tokens provides no long-term protection | Migrate pseudonymisation tokens and encryption of long-lived PII to ML-KEM (FIPS 203) / AES-256-GCM; audit data retention — delete what doesn't need to outlive the quantum threat window |
+| LLM-assisted re-identification of "anonymised" datasets | 2025–2026 (active) | LLMs correlate quasi-identifiers across public datasets at scale, collapsing k-anonymity protections that were adequate against manual analysis | Apply differential privacy (ε-DP) to any published aggregate or ML training data; validate anonymisation against LLM-assisted adversary, not just statistical models |
+| EU AI Act risk classification of profiling systems | 2026 (enforcement) | Systems that perform behavioural profiling or automated decision-making on individuals are classified high-risk and require DPIA + conformity assessment | Audit all recommendation, scoring, and targeting features against AI Act Annex III; pre-register DPIAs for any feature that scores, ranks, or filters individuals |
+| Data broker regulation and cross-context tracking bans | 2026–2027 | US state privacy laws (CPRA, VCDPA, CPA) increasingly ban cross-context behavioural advertising without explicit consent; violations now carry per-record fines | Audit all third-party SDK data flows; implement server-side tagging to eliminate client-side PII leakage to ad networks |
+| Mandatory data minimisation in generative AI training (EU AI Act / GDPR joint guidance) | 2026–2027 | Any fine-tuning on user data without explicit consent for that purpose will constitute unlawful processing; current fine-tune pipelines rarely validate consent scope | Implement consent-scope checks in every data pipeline that feeds model training; purge user data from training sets upon erasure request |
+
+---
+
+## §DETECTION-GAP
+
+What current privacy monitoring CANNOT detect in the LINDDUN domain, and what to build to close each gap.
+
+- **Quasi-identifier linkage across data stores**: No SIEM rule fires because no single PII field is accessed. Need: data-access graph that correlates queries touching ZIP, DOB, gender, and device ID within the same user session — alert when 3+ quasi-identifiers are joined without a documented legitimate purpose.
+- **Analytics SDK PII leakage via browser-collected URLs**: Server-side logs show clean API requests; the exfiltration happens in the browser before the request is sent. Need: CSP `connect-src` inventory + periodic synthetic test that loads key pages with PII in query params and inspects outbound network calls via a proxy (Playwright + Burp).
+- **Stale consent propagated to async workers**: The consent DB record is updated; the background worker reads from a Redis cache with a 24-hour TTL. Need: consent-change events must invalidate all downstream caches synchronously; add a canary test that withdraws consent and verifies the next queued job for that user is suppressed within < 5 seconds.
+- **Right-to-erasure incompleteness in cold storage**: Primary DB erasure looks correct in application logs. Glacier, BigQuery export tables, and Elasticsearch indexes are never checked. Need: erasure verification job that queries all registered downstream systems for the deleted user ID 72 hours post-deletion and alerts on any non-zero result.
+- **Timing/size side-channel presence inference (Detecting)**: No application log records "user existence leaked." Need: p99 latency and Content-Length monitoring per authentication/lookup endpoint; statistical alert if the delta between hit and miss paths exceeds 5 ms or 50 bytes across a rolling 1-hour window.
+
+---
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any LINDDUN threat category clean without explicit evidence of checking. For each category, output one of:
+- `CHECKED: [N files] | [patterns used] | CLEAN`
+- `CHECKED: [N files] | [patterns used] | [N findings, all fixed]`
+- `SKIPPED: [reason — must be "not applicable: [evidence]"]`
+
+**Silent skip = FAILED COVERAGE.** The orchestrator flags this as a quality gap.
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      { "class": "LINDDUN:Linking", "filesReviewed": 34, "patterns": ["userId in analytics events", "cross-context correlation"], "result": "CLEAN" },
+      { "class": "LINDDUN:Identifying", "filesReviewed": 34, "patterns": ["email hash", "IP+UA fingerprint"], "result": "2 findings, both remediated" },
+      { "class": "LINDDUN:NonRepudiation", "filesReviewed": 18, "patterns": ["audit log granularity", "action attribution"], "result": "CLEAN" },
+      { "class": "LINDDUN:Detecting", "filesReviewed": 22, "patterns": ["last-seen APIs", "read receipts", "timing side-channel"], "result": "CLEAN" },
+      { "class": "LINDDUN:DataDisclosure", "filesReviewed": 29, "patterns": ["PII in error messages", "third-party SDK scope"], "result": "1 finding, remediated" },
+      { "class": "LINDDUN:Unawareness", "filesReviewed": 8, "patterns": ["privacy notice presence", "consent UI"], "result": "CLEAN" },
+      { "class": "LINDDUN:NonCompliance", "filesReviewed": 15, "patterns": ["retention policy", "DPIA existence", "erasure completeness"], "result": "CLEAN" }
+    ],
+    "filesReviewed": 47,
+    "negativeAssertions": [
+      "Linking: cross-context userId correlation searched across 34 files — 0 unmitigated paths",
+      "DataDisclosure: PII in error messages searched across 29 files — 1 finding fixed inline"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```

package/skills/logic-race-fuzzer/SKILL.md

@@ -65,3 +65,446 @@ Find race conditions, business logic flaws, and arithmetic vulnerabilities.
 - Concurrent request sequence that reproduces the issue
 - Database/cache state before and after the race
 - Fixed code using atomic operations or distributed locks written inline
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "...", "exploitHint": "..." }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "...", "location": "..." }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "...", "escalationPath": "..." }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["..."], "releaseBlock": true }]
+  }
+}
+```
+
+---
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+### 1. Double-Spend via Async Await Gap (CVE-2023-23916 class)
+
+**Attack technique:** In any async handler where a balance read precedes a deduction, a second
+concurrent request can observe the pre-deduction balance. Both transactions succeed, debiting
+only once from the account. This pattern is rampant in Node.js microservices using Prisma
+without explicit row-level locking.
+
+**Concrete detection method:**
+```bash
+# Grep for balance read followed by update without transaction or locking
+grep -rn "findUnique\|findFirst" src/ | grep -i "balance\|credit\|wallet\|fund" | \
+  while read line; do
+    file=$(echo $line | cut -d: -f1)
+    # Check if file uses $transaction() or SELECT FOR UPDATE
+    grep -l "\$transaction\|SELECT.*FOR UPDATE\|selectForUpdate" "$file" || echo "MISSING_LOCK: $file"
+  done
+```
+
+**Finding criterion:** Any balance-affecting endpoint where the read and write are not wrapped
+in a serializable transaction or SELECT FOR UPDATE. Reproduce with:
+```bash
+ab -n 200 -c 50 -p payload.json -T application/json http://target/api/transfer
+# Verify: final balance < expected minimum (funds created from nothing)
+```
+
+---
+
+### 2. Redis INCR/EXPIRE Non-Atomic Rate Limit Bypass
+
+**Attack technique:** A rate limiter that calls INCR then EXPIRE as two separate commands has a
+TOCTOU window. If the process crashes or a network partition occurs between INCR and EXPIRE,
+the counter persists forever — permanently locking the key. Conversely, a fast concurrent
+burst can exhaust the window before EXPIRE fires, allowing unlimited requests.
+
+**Concrete detection method:**
+```bash
+grep -rn "redis.*incr\|client\.incr\|\.incr(" src/ | grep -v "lua\|eval\|multi\|pipeline"
+# Any INCR not followed immediately by an atomic EXPIRE in the same Lua script is vulnerable
+```
+
+**Fix template:** Replace with atomic Lua:
+```lua
+local current = redis.call('INCR', KEYS[1])
+if current == 1 then redis.call('EXPIRE', KEYS[1], ARGV[1]) end
+return current
+```
+
+---
+
+### 3. Mass Assignment Privilege Escalation (OWASP API6:2023)
+
+**Attack technique:** When ORM models accept arbitrary JSON from `req.body` without an explicit
+allowlist, an attacker can set fields like `role`, `isAdmin`, `tier`, `verified`, or `balance`
+directly. This is distinct from parameter pollution — the payload looks structurally valid.
+
+**Concrete detection method:**
+```bash
+# Express/Fastify: find raw body spreads into ORM create/update calls
+grep -rn "\.create(\|\.update(\|\.upsert(" src/ | grep -v "allowlist\|pick(\|omit("
+# Then check if req.body is passed directly
+grep -rn "req\.body" src/ | grep -v "zod\|joi\|validate\|schema"
+```
+
+**Finding criterion:** Any ORM mutation accepting `req.body` without a Zod/Joi allowlist schema
+applied at the route boundary. Fields to verify are excluded: `role`, `isAdmin`, `plan`,
+`balance`, `credits`, `verified`, `stripeCustomerId`.
+
+---
+
+### 4. AI-Assisted Race Condition Discovery (Emerging Threat, 2025)
+
+**Attack technique:** LLM-powered fuzzing tools (e.g., Mayhem, CodaMOSA, and custom GPT-4-based
+harnesses) can automatically generate concurrent request sequences from OpenAPI specs and
+exhaustively model state interleavings. An adversary with access to a public API spec and an
+LLM harness can discover race windows in hours that would take a human days. This means any
+publicly documented API endpoint with shared-state side effects is now a viable automated
+target.
+
+**Concrete detection method (defensive):**
+- Export all route definitions and run `race-the-web` or a custom ab/wrk2 harness against
+  every state-mutating endpoint with concurrency ≥ 50.
+- For AI-assisted attack simulation: feed the OpenAPI spec to a locally-hosted LLM and ask it
+  to enumerate all async await gaps and concurrent state mutation paths.
+
+```bash
+# Run concurrent hammering against every POST/PUT/PATCH endpoint
+npx race-the-web --config race-config.yaml --concurrency 100 --requests 500
+```
+
+**Finding criterion:** Any endpoint where a concurrent load test produces a final system state
+that differs from the sum of all successful response payloads.
+
+---
+
+### 5. Integer Overflow in Quantity × Price Multiplication (CWE-190)
+
+**Attack technique:** When quantity and unit price are stored as 32-bit integers and multiplied
+server-side without overflow guards, an attacker supplying `quantity=2147483648` can cause the
+total to wrap to a negative number (or zero), resulting in a free or negative-cost order. This
+was exploited in multiple e-commerce platforms in 2022–2024.
+
+**Concrete detection method:**
+```bash
+# Find multiplication of user-controlled numeric fields
+grep -rn "quantity.*price\|price.*quantity\|qty.*amount\|amount.*qty" src/ | \
+  grep -v "BigInt\|bigint\|Decimal\|decimal\|Math\.imul"
+# Also check for lack of upper-bound validation on quantity inputs
+grep -rn "z\.number()\|Joi\.number()" src/ | grep -v "\.max(\|\.positive(\|\.int("
+```
+
+**Finding criterion:** Any money calculation using native JavaScript `number` type (IEEE 754
+float, 53-bit mantissa) or uncapped integer multiplication. All monetary arithmetic MUST use
+`BigInt` or a decimal library (`decimal.js`, `dinero.js`). All quantity inputs must have an
+explicit `.max()` bound in validation schemas.
+
+---
+
+### 6. Supply Chain: Malicious npm Package Injecting Timing Attacks (Post-2024)
+
+**Attack technique:** Compromised npm packages (e.g., the `event-stream` pattern) can inject
+code that introduces intentional timing side channels. A malicious `parseAmount()` patch in a
+transitive dependency can leak whether a given account balance is above or below a threshold
+by varying response time by ~2ms per bit — invisible to functional tests but detectable by
+statistical timing analysis after ~10,000 samples.
+
+**Concrete detection method:**
+```bash
+# Audit all transitive dependencies for recently published/updated packages
+npm audit --json | jq '.vulnerabilities | keys[]'
+npx better-npm-audit --level critical
+# Check for suspicious timing patterns in hot paths
+grep -rn "setTimeout\|setInterval\|Date\.now()\|performance\.now()" node_modules/.pnp* 2>/dev/null || \
+  find node_modules -name "*.js" -newer package-lock.json -not -path "*/test/*" | head -20
+```
+
+**Finding criterion:** Any recently-modified transitive dependency touching arithmetic or
+comparison functions in payment or authentication hot paths. Cross-reference with OSV.dev
+and the Socket.dev supply chain scanner.
+
+---
+
+### 7. Post-Quantum Threat to Idempotency Key HMAC Signing
+
+**Attack technique:** Many idempotency key schemes use HMAC-SHA256 to sign the key + timestamp
+to prevent replay. With a Cryptographically Relevant Quantum Computer (CRQC), Grover's algorithm
+reduces HMAC-SHA256 brute-force from 2^256 to 2^128 — still safe for symmetric keys. However,
+if idempotency keys are also bound to RSA or ECDSA signatures (e.g., signed JWTs), those
+signatures will be fully broken. An attacker who harvests signed idempotency tokens today can
+replay them after CRQC deployment.
+
+**Concrete detection method:**
+```bash
+# Find idempotency key validation that relies on RSA/ECDSA-signed tokens
+grep -rn "idempotency\|Idempotency" src/ | grep -v "HMAC\|sha256\|sha512"
+grep -rn "jwt\.verify\|RS256\|ES256\|RS384" src/ | grep -i "idempot\|replay\|dedup"
+```
+
+**Finding criterion:** Any idempotency scheme relying on asymmetric cryptography for token
+integrity. Migrate to HMAC-SHA256 or ML-KEM-based MACs for long-lived tokens. Flag for the
+CryptoSpecialist agent.
+
+---
+
+### 8. TOCTOU in File-Based Job Lock Files
+
+**Attack technique:** Job processors that use filesystem lock files (`.lock`, `.pid`) to prevent
+duplicate execution have a TOCTOU window between `fs.existsSync()` and `fs.writeFileSync()`.
+On NFS-mounted volumes or containerized environments with shared storage, two workers can
+simultaneously observe the lock as absent and both proceed — causing duplicate job execution.
+This is a common pattern in legacy cron-to-container migrations.
+
+**Concrete detection method:**
+```bash
+# Find lock file patterns that are not using O_EXCL or atomic file creation
+grep -rn "existsSync\|statSync\|accessSync" src/ | grep -i "lock\|pid\|mutex"
+grep -rn "writeFileSync\|openSync" src/ | grep -i "lock\|pid"
+# O_EXCL flag check — this is the only safe pattern:
+grep -rn "O_EXCL\|wx'" src/ | grep -i "lock\|pid"  # must have results
+```
+
+**Finding criterion:** Any lock file mechanism not using `fs.openSync(path, 'wx')` (O_EXCL
+mode) or a database-level advisory lock. The `'wx'` flag fails atomically if the file exists.
+Replace all `existsSync + writeFileSync` lock patterns with atomic `openSync(..., 'wx')`.
+
+---
+
+## §LOGIC_RACE_FUZZER-CHECKLIST
+
+1. **Double-spend via concurrent balance deduction** — Mechanism: two simultaneous POST
+   /transfer requests read the same balance before either write commits. Grep for
+   `balance`, `wallet`, `credit` reads not inside `$transaction()` or `SELECT FOR UPDATE`.
+   Finding: final balance lower than both transactions combined, or negative.
+
+2. **Negative quantity acceptance in order creation** — Mechanism: attacker submits
+   `quantity: -100` to refund endpoint, receiving credits without spending. Grep Zod/Joi
+   schemas for quantity fields missing `.positive()` or `.min(1)`. Finding: API accepts
+   negative quantities and adjusts balance accordingly.
+
+3. **Redis rate limit bypass via non-atomic INCR/EXPIRE** — Mechanism: burst 100 requests
+   in <1ms before EXPIRE fires; counter never gets TTL. Grep for `redis.incr` not followed
+   by Lua eval. Finding: rate limit counter persists beyond window or burst succeeds past limit.
+
+4. **Mass assignment role escalation** — Mechanism: POST body includes `"role":"admin"` or
+   `"isAdmin":true`; ORM applies it without allowlist. Grep for `.create(req.body)` or
+   `Object.assign(model, req.body)`. Finding: user gains elevated role via crafted payload.
+
+5. **Float arithmetic precision loss in money** — Mechanism: `0.1 + 0.2 !== 0.3` in
+   JavaScript causes rounding errors in accumulated transactions. Grep for `parseFloat`,
+   `toFixed`, or arithmetic on price/amount/balance fields. Finding: total differs from
+   expected by >0 cents over multiple operations.
+
+6. **Idempotency key replay across users** — Mechanism: idempotency key namespace is not
+   scoped per user; attacker reuses another user's key to replay their transaction. Grep for
+   idempotency key lookup without user ID scoping. Finding: key from user A accepted for
+   user B's request, returning user A's cached response.
+
+7. **Bull/BullMQ duplicate job on worker restart** — Mechanism: job marked active but
+   worker crashes before marking complete; re-queued on restart; processed twice. Grep for
+   `queue.add()` without `jobId` deduplication option. Finding: job processing count >1 for
+   the same logical event in logs.
+
+8. **TOCTOU on inventory deduction** — Mechanism: two concurrent purchase requests both
+   check `stock > 0`, both pass, both decrement — final stock goes negative. Grep for
+   inventory/stock reads without `SELECT FOR UPDATE` or optimistic locking version field.
+   Finding: `stock` column < 0 after concurrent purchase load test.
+
+9. **Integer overflow in total price calculation** — Mechanism: `quantity * unitPrice` with
+   uncapped integer input overflows signed 32-bit, wrapping to negative. Grep for price
+   multiplication not using `BigInt` or `Decimal`. Finding: order total is negative or zero
+   for extreme quantity inputs.
+
+10. **Webhook duplicate delivery without deduplication** — Mechanism: provider retries
+    webhook on timeout; handler processes event twice; payment credited twice. Grep for
+    webhook handlers without idempotency key storage in DB. Finding: duplicate credit/order
+    row created for single webhook event ID.
+
+11. **Async await gap in multi-step state machine** — Mechanism: handler reads state,
+    `await`s external call, another request mutates state during await, handler resumes
+    with stale state and overwrites it. Grep for state reads followed by `await` and
+    subsequent state writes without re-read or optimistic lock. Finding: state machine
+    transitions to invalid state under concurrent load.
+
+12. **Quota bypass via concurrent quota check and consumption** — Mechanism: concurrent
+    API calls all pass quota check simultaneously; each consumes quota; total exceeds limit.
+    Grep for quota/limit checks using two-step read+decrement outside a transaction.
+    Finding: usage counter exceeds configured maximum after concurrent burst test.
+
+---
+
+## §POC-REQUIREMENT
+
+For every CRITICAL or HIGH finding in this domain:
+
+1. **Write the working PoC FIRST** (exact payload, exact request, observed impact)
+2. **Confirm the PoC reproduces the issue** — show actual vs. expected state
+3. **THEN write the fix**
+4. **THEN verify the PoC fails against the fix** — rerun and confirm fix holds
+5. **Record the PoC in findings JSON under `exploitPoC`**
+
+**PoC skipping = finding severity downgraded to MEDIUM automatically.**
+
+### PoC Template for Race Conditions:
+
+```bash
+# Step 1: Establish baseline state
+BEFORE=$(curl -s -H "Authorization: Bearer $TOKEN" http://target/api/balance | jq .balance)
+echo "Balance before: $BEFORE"
+
+# Step 2: Fire concurrent requests
+for i in {1..50}; do
+  curl -s -X POST http://target/api/transfer \
+    -H "Authorization: Bearer $TOKEN" \
+    -H "Content-Type: application/json" \
+    -d '{"amount": 100, "to": "attacker"}' &
+done
+wait
+
+# Step 3: Observe post-race state
+AFTER=$(curl -s -H "Authorization: Bearer $TOKEN" http://target/api/balance | jq .balance)
+ATTACKER=$(curl -s -H "Authorization: Bearer $ATTACKER_TOKEN" http://target/api/balance | jq .balance)
+echo "Balance after: $AFTER (expected: $((BEFORE - 100)))"
+echo "Attacker received: $ATTACKER (expected: 100)"
+# FINDING: if ATTACKER > 100 — double spend confirmed
+```
+
+### PoC findings JSON entry:
+```json
+{
+  "findingId": "RACE-001",
+  "severity": "CRITICAL",
+  "title": "Double-spend via concurrent balance deduction",
+  "exploitPoC": {
+    "command": "ab -n 200 -c 50 -p transfer.json -T application/json http://target/api/transfer",
+    "payload": "{\"amount\": 100, \"to\": \"attacker\"}",
+    "observedImpact": "Attacker balance increased by 800 from a single 100-unit source",
+    "reproduced": true,
+    "fixVerified": true
+  }
+}
+```
+
+---
+
+## §PROJECT-ESCALATION
+
+Immediately call `orchestration.update_agent_status` with `"CRITICAL_ESCALATION"` and halt
+normal execution flow when ANY of the following conditions are detected:
+
+1. **Confirmed double-spend with monetary impact** — Any race condition where a concurrent
+   PoC produces more funds/credits than were legitimately input. Escalate immediately; do not
+   wait for full scan completion. This is a P0 production incident if the service is live.
+
+2. **Mass assignment grants admin/root privileges** — A PoC payload that promotes a regular
+   user to admin, superuser, or bypasses billing tier restrictions via body injection. The
+   entire authorization model must be reassessed by the full orchestrator.
+
+3. **Idempotency key namespace collision enabling cross-user replay** — If user A's
+   idempotency token can be replayed as user B, this is a fundamental authentication flaw
+   that affects every transaction in the system. Escalate before continuing.
+
+4. **Integer overflow to negative total enabling free or paid-refund order** — A PoC that
+   places an order with negative total, triggering a real payment refund or free fulfillment.
+   Escalate to compliance GRC agent simultaneously — this may constitute fraud facilitation.
+
+5. **Duplicate webhook processing confirmed with external payment provider** — If Stripe,
+   PayPal, or any payment webhook fires credits twice and the system accepts both, escalate
+   immediately. Financial reconciliation is now broken; every transaction must be audited.
+
+6. **Supply chain package found injecting timing code into payment hot path** — A transitive
+   npm dependency modified within the last 30 days that touches arithmetic in payment or
+   balance calculation code. Escalate to CISO orchestrator for supply chain incident response.
+
+7. **TOCTOU on authentication token validation** — If a race between token validation and
+   token revocation allows a revoked token to be used, escalate. This is an authentication
+   bypass affecting all session security.
+
+8. **Quota bypass enabling resource exhaustion or billing fraud** — If concurrent API calls
+   can exceed hard resource limits (e.g., API call quotas, storage limits, seat licenses),
+   escalate to compliance GRC. Billing integrity is compromised.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 attack cases in this domain that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | Second-order / stored payload executed in different context | Scanner checks input context, not execution context | Store payload safely; trigger in separate request/session |
+| 2 | Unicode normalisation bypass | Regex filters run before normalisation; attacker uses homoglyphs or composed forms | Submit Ⅰ (U+2160) or ＜ (U+FF1C) variants of known-bad strings |
+| 3 | Polyglot payload active in multiple sinks simultaneously | Scanners test one injection class per payload | `'"><script>{{7*7}}</script><!--` — SQL + XSS + SSTI in one request |
+| 4 | Out-of-band exfiltration (DNS/HTTP callback) | Scanner looks for inline response difference; OOB leaves no visible trace | Use Burp Collaborator / interactsh; inject DNS lookup payload |
+| 5 | Race condition between check and use (TOCTOU) | Sequential scanners don't model concurrency | Send two simultaneous requests to the same state-changing endpoint |
+
+---
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to This Domain | Prepare Now By |
+|--------|--------------|--------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | Harvest-now-decrypt-later attacks active today; RSA/ECDSA keys signed today will be broken | Inventory all RSA/ECDSA usage; migrate long-lived data to ML-KEM (FIPS 203) |
+| AI-assisted adversaries at scale | 2025–2027 (active) | LLM-powered fuzzing finds 10× more edge cases; automated PoC generation | Assume attackers have LLM help; expand test surface to match |
+| EU AI Act full enforcement | 2026 | High-risk AI systems require mandatory conformity assessments | Classify all AI features against AI Act tiers now |
+| Post-quantum TLS migration deadline | 2028–2030 | Browser vendors will drop classical-only TLS connections | Begin TLS agility assessment; test hybrid key exchange |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | SBOM and SLSA attestation are becoming legally required | Achieve SLSA L2 minimum; generate CycloneDX SBOM per release |
+
+---
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in this domain, and what to build to close each gap.
+
+**Standard gaps that MUST be checked:**
+
+- **Second-order attack execution**: The storage request looks safe; only the retrieval+execution step is dangerous. Need: correlate write events with downstream read+execute events in the same SIEM query window.
+- **Timing-side-channel leakage**: No log event emitted; only observable as microsecond response-time variance. Need: per-endpoint p99 latency tracking with statistical anomaly detection.
+- **Low-and-slow credential stuffing**: Individually, each request is under rate limits. Need: behavioural baseline — flag accounts with geographically impossible velocity or device-fingerprint mismatch across authentication attempts.
+- **Insider exfiltration via legitimate process**: Authorised exports, reports, and data downloads that individually are permitted but collectively constitute data exfiltration. Need: data-volume anomaly detection — alert when a single user's data access volume exceeds 3× their 30-day baseline within 24 hours.
+- **Cross-agent attack chains**: Phase 1 finding A + Phase 1 finding B = CRITICAL chain invisible to either agent alone. Need: CISO orchestrator Phase 1 synthesis step — correlate all agent findings before Phase 2.
+
+**Domain-specific detection gaps for logic-race-fuzzer:**
+
+- **Race condition in production traffic**: Standard APM shows elevated p99 but no log entry for the race event itself. Need: distributed tracing with concurrent request correlation — flag any two request spans that overlap in time and mutate the same resource ID.
+- **Slow double-spend over days**: Attacker spaces concurrent requests hours apart to avoid rate limiting. Need: balance integrity check — periodic reconciliation job that computes expected balance from transaction ledger and alerts on discrepancy.
+- **Negative balance after float rounding**: Rounding errors accumulate over thousands of transactions but individual transaction logs appear correct. Need: end-of-day balance reconciliation comparing ledger sum to stored balance with zero tolerance.
+
+---
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any attack class clean without explicit evidence of checking. For each item, output one of:
+- `CHECKED: [N files] | [patterns used] | CLEAN`
+- `CHECKED: [N files] | [patterns used] | [N findings, all fixed]`
+- `SKIPPED: [reason — must be "not applicable: [evidence]"]`
+
+**Silent skip = FAILED COVERAGE.** The orchestrator flags this as a quality gap.
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [{ "class": "Double-Spend Race Condition", "filesReviewed": 47, "patterns": ["findUnique", "balance", "$transaction"], "result": "CLEAN" }],
+    "filesReviewed": 47,
+    "negativeAssertions": ["Race condition: balance mutation patterns searched across 47 files — all wrapped in $transaction()"],
+    "uncoveredReason": {}
+  }
+}
+```
+
+---
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "logic-race-fuzzer",
+  "resolved": true,
+  "remediationTemplate": "one-line description of what was done",
+  "falsePositive": false
+}
+```
+Call `security.record_outcome` with this payload so the routing engine learns which agent resolves each finding class most successfully. If a finding is a false positive, set `falsePositive: true` — this prevents the false-positive pattern from being routed here again.