exploit-chaining-engine

name	exploit-chaining-engine
description	Offensive chain builder. Use when you have one or more weak findings and want to score, prioritize, and compose them into a critical or high-impact exploit path.
sources	field_recon, hackerone_public
report_count	50

Exploit Chaining Engine

Two scores for every finding

Every finding gets:

• severity_score
• chainability_score

A medium finding with high chainability is often worth more than an isolated high.

High-chainability primitives

Prioritize these:

• leaked token / cookie / secret
• reset / invite / verify abuse
• secondary-object IDOR
• export / attachment leakage
• GraphQL helper mutation drift
• import or parser confusion
• observer/support/helper role drift
• admin/control-plane exposure
• AI cross-tenant object reference
• full-response SSRF

Composition patterns

Look for:

• disclosure -> credential or object ID -> destructive or privileged action
• export leak -> secret -> repo/CI/control-plane access
• helper-object IDOR -> workflow bypass -> account or privilege takeover
• import parser bug -> local file read -> secret reuse -> RCE or admin access
• SSRF -> metadata -> cloud creds -> control-plane access
• XSS on auth-sensitive surface -> token/session theft -> ATO

Chain-building workflow

For every primitive, force it through this sequence:

1. Name the primitive. Examples: read another user's attachment, generate invite for wrong target, fetch internal URL, mutate helper object, leak token, poison renderer, trigger duplicate value.
2. Name the trust boundary. Actor, tenant, state, parser, renderer, background worker, integration, AI retrieval, or control plane.
3. Find the carrier object. Token, export, signed URL, job ID, GraphQL GID, webhook event, invite, recovery link, attachment, AI source, support ticket, or generated preview.
4. Find the authority upgrade. Can the carrier create a session, change role, read secrets, invoke admin action, reach internal systems, or mint durable access?
5. Prove the minimal high-impact path. Demonstrate one clean account takeover, privilege change, cross-tenant disclosure, cloud/control-plane access, or financial loss with synthetic data.

Never score a primitive only by the endpoint where it was found. Score it by the strongest authority it can reach after one or two realistic pivots.

Primitive-to-impact ladders

Object ID / GID disclosure

Try:

• feed the ID into helper mutations, exports, previews, comments, attachments, audit logs, AI citations, and mobile endpoints
• pair attacker-owned parent with victim child, and victim parent with attacker child
• replay after archive, restore, move, clone, and tenant transfer

Impact targets:

• private data disclosure
• destructive mutation
• unauthorized export
• role or membership change

Invite / reset / verification primitive

Try:

• stale redemption after email, phone, tenant, role, or invite target changes
• scalar-to-array/object destination mutation
• resend/cancel/preview/accept endpoint mismatch
• token reuse across web, mobile, and API paths

Impact targets:

• account takeover
• unauthorized workspace membership
• employee/partner verification bypass
• MFA or recovery downgrade

Export / attachment / generated artifact

Try:

• direct child-object access
• signed URL reuse after access removal
• export requested by one actor and downloaded by another
• import -> export symmetry to launder ACLs
• background job completion after object permission changes

Impact targets:

• confidential data leakage
• token/secret disclosure
• durable external access
• cross-tenant data exposure

Import / parser / integration fetch

Try:

• symlink/hardlink/nested archive/duplicate name inputs
• local path or unexpected URI source resolution
• redirect chains and full-response reflection
• payloads in metadata, filenames, markdown, diagrams, CSV formulas, and generated previews

Impact targets:

• file read
• SSRF
• server-side execution
• private object copy or tenant breakout

Rendering / cache / support sink

Try:

• sink-specific payload grammar
• admin/support/login/recovery render contexts
• cache key confusion through host, scheme, port, path, query, method, and content negotiation variants
• clean-client validation after poisoning

Impact targets:

• privileged session action
• credential/session capture path
• stored cross-context execution
• fix-bypass persistence

Billing / quota / financial state

Try:

• race redemption/finalization/refund/cancel
• negative, zero, huge, archived, or stale values
• webhook replay/type swap
• entitlement use after downgrade/refund/removal

Impact targets:

• monetary loss
• free premium entitlement
• persistent unauthorized access
• business logic criticality

Chainability scoring rubric

Score chainability_score from 0 to 5:

• 0: isolated informational signal with no reachable object or authority.
• 1: needs unrealistic victim action or unsupported assumptions.
• 2: reaches non-sensitive data or low-value state only.
• 3: reaches sensitive object, token-adjacent state, or privileged workflow precondition.
• 4: reaches session, role, export, secret, internal service, or financial state.
• 5: directly composes into ATO, privilege escalation, cross-tenant data access, cloud/control-plane access, RCE, or material financial loss.

When two paths compete, choose the one with the higher chainability score even if the initial severity looks lower.

Chain card

Record serious candidates using .offsec/templates/exploit-chain-card.md

Decision rule

When choosing between two next actions:

• prefer the action that proves composition
• prefer the action that converts disclosure into control
• prefer the action that upgrades a primitive into business impact
• prefer the action that tests a different boundary (actor, object, state, parser, renderer, worker) over repeating the same boundary
• prefer the path that can be proven with clean synthetic data and minimal collateral