Chain Recognition

Why chains are invisible

A single-vulnerability view of a target has a blind spot: the interesting bugs are often compounds. A low-impact write becomes a zero-click takeover when it can reach a served file; an XSS in a low-value frame becomes an admin compromise when a postMessage bridge carries it into the main app; a missing re-authentication check turns an email swap into an account takeover.

Component matching alone struggles with this. It can surface each playbook that applies, but it has no language for "these two things together are a chain" — because the second step only becomes true after the first one succeeds.

Earned capabilities

The insight behind chain recognition is that some things become true about a target only when you achieve them. These are primitives: fundamental capabilities like arbitrary file write, or execution in a victim's browser, that you earn by successfully weaponizing a vulnerability.

So playbooks declare what they yield on success, and the engine treats those yields as new matching signals:

Zip Slip playbook            → success → yields: arbitrary file write
  └─ overwrite-a-served-file playbook
       (requires the earned primitive)
                             → success → yields: stored XSS
            └─ escalation meta-playbook
                 (requires the earned primitive)
                             → leads to account takeover

The engine doesn't need to know the whole chain upfront. It follows the primitive graph one step at a time — and each success unlocks the next suggestion automatically. See Yields and Primitives for the mechanics.

Why gating matters

Without yield-gating, a chain playbook that requires "stored XSS" would fire on any asset where a hunter manually noted stored XSS — even if the delivery path the chain assumes doesn't exist. That's noise.

Yield-gating fixes it: a gated requirement is satisfied only by a capability that was actually earned. The chain stays invisible until the foundation has been demonstrated on this target.

Meta-playbooks

Escalation knowledge doesn't care how the primitive was acquired. A stored-XSS escalation playbook applies whether the XSS came from an archive overwrite, a vulnerable username field, or an upload — any path that earns stored-xss feeds it.

This is the meta-playbook pattern: write the escalation once, and every route to that primitive inherits it. As more playbooks yield the same primitive, the escalation playbook gets more valuable without being touched.

What chains look like

Compound paths tend to hide in the same places — worth keeping in the back of your head while mapping:

• A write that reaches a served surface — archive extraction, file overwrite, template injection: the question is whether what you wrote is ever read or executed.
• A trust bridge between contexts — postMessage handlers, iframes, subdomain-to-subdomain flows: weak origin checks turn a low-value frame into a foothold in the main app.
• Identity flows without re-authentication — email change, password reset, invite flows: the pivot from "some execution" to "account takeover" is often a missing confirmation, not a missing exploit.
• Parser and semantic differences — duplicate parameters, normalization mismatches, type coercion: two components that disagree about what the same input means.

None of these are playbooks — they are shapes that recurring chains take. Recognizing the shape is how you know which primitives are worth pursuing on a target.

What's next

• Worked Chains — the shapes above, told as full narratives.
• Yields and Primitives — the mechanics behind everything on this page.
• Authoring Guide — writing the playbooks that gate and grant capabilities.