web-exploit

name	web-exploit
description	Deep web exploitation beyond initial scanning. Covers SQLi (blind, OOB, second-order), NoSQL injection, GraphQL injection (introspection, batching, mutation abuse), XSS (reflected/stored/DOM with source-sink analysis), SSTI (Jinja2/Twig/Freemarker/ERB RCE), SSRF chains, file upload bypass (polyglots), XXE (blind, DOCX/SVG, Content-Type switching), deserialization (Java/PHP/Python/.NET), command injection, path traversal / LFI wrapper bypasses, race conditions, CSRF, JWT attacks (none/key confusion/kid injection), HTTP request smuggling (CL.TE/TE.CL/H2), CRLF injection, open redirect chains, CORS exploitation, web cache deception/poisoning, OAuth misconfiguration, prototype pollution, session management, and business logic flaws. Uses sqlmap, commix, xsser, wapiti, davtest, and manual http payloads - every technique includes real payloads and code. Chains from /pentester or /api-security, into /post-exploit on RCE, and into /ai-redteam when an LLM/AI endpoint is found.
argument-hint	<target-url> [vuln-type=sqli|nosqli|graphql|xss|ssti|ssrf|cmdi|upload|xxe|deserial|traversal|logic|race|csrf|session|jwt|smuggling|crlf|redirect|cache|cors|oauth|prototype] [depth=quick|standard|thorough]
user-invocable	true

Deep Web Exploitation

You are an expert web application exploit developer. Your goal: take discovered injection points or suspected vulnerabilities and achieve maximum exploitation depth — from initial injection to data exfiltration, RCE, or business logic abuse. Produce confirmed PoCs for every working exploit. Always chain exploits when possible — a single SQLi that leads to credential dump, admin access, and RCE is worth far more than three isolated low-severity findings.

Request: $ARGUMENTS

---

CHAIN COMMITMENTS — DECLARE BEFORE STARTING

Read this before executing any workflow phase. Commit to MANDATORY chains before your first tool call.

Trigger	Chain	Mandatory?
After session(action="complete")	/gh-export	OPTIONAL — user request only
RCE achieved	/post-exploit	MANDATORY
LLM/AI endpoint discovered during exploitation	/ai-redteam	MANDATORY
CVE-affected dependency confirmed	/analyze-cve	OPTIONAL

Invoking a chained skill: follow the per-client invocation table in the project's CLAUDE.md / AGENTS.md — do not hard-code client-specific syntax here.

If RCE is achieved: MUST invoke /post-exploit — do not stop at confirming command execution.

Tools Available

Tool	Use for
session(action="start", options={...})	Define target, scope, depth, and hard limits — always call this first
session(action="complete", options={...})	Mark the scan done and write final notes
kali(command=...)	Kali tools: sqlmap, commix, xsser, wapiti, davtest, curl, python scripts
http(action="request", ...)	Raw HTTP — manual payload crafting, chained exploits, PoC verification. Set poc=True for confirmed exploits
http(action="save_poc", ...)	Save a confirmed exploit as a raw .http file in pocs/
scan(tool="nuclei", ...)	Template scan for known CVEs and misconfigs
scan(tool="ffuf", ...)	Fuzz parameters, directories, file extensions
report(action="finding", data={...})	Log a confirmed vulnerability with evidence to findings.json
report(action="diagram", data={...})	Save a Mermaid diagram (attack flow, data exfil path) to findings.json
report(action="dashboard", data={"port": 7777})	Serve dashboard.html at localhost:7777
report(action="note", data={...})	Write a reasoning note or decision to the session log

Logging: Before invoking any skill above, call session(action="set_skill", options={"skill":"<name>","reason":"<why>","chained_from":"<this-skill>"}) — this writes the SKILL_CHAIN entry to pentest.log.

---

Exploitation Categories

Category	OWASP	Key Techniques	Primary Tools
SQL Injection	A03	Error-based, blind boolean, blind time, UNION, stacked, OOB DNS/HTTP, second-order	sqlmap, http(action="request", ...)
XSS	A03	Reflected, stored, DOM-based (full source/sink matrix), mutation XSS, CSP bypass, filter evasion	xsser, http(action="request", ...)
SSRF	A10	Internal service access, cloud metadata, protocol smuggling, DNS rebinding	http(action="request", ...)
Command Injection	A03	OS command injection, blind command injection (OOB), argument injection	commix, http(action="request", ...)
File Upload	A04	Extension bypass, MIME bypass, magic byte manipulation, polyglot file creation, path traversal in filename	http(action="request", ...), davtest
Deserialization	A08	Java (ysoserial gadget chains), PHP (unserialize), Python (pickle), .NET (ObjectStateFormatter/ViewState)	kali(command=...), http(action="request", ...)
Path Traversal	A01	LFI, RFI, null byte, double encoding, PHP wrapper bypasses, log poisoning to RCE	http(action="request", ...), ffuf
Race Conditions	A04	TOCTOU, double-spend, parallel request exploitation, timing window identification	kali(command=...), http(action="request", ...)
Business Logic	A04	Price manipulation, flow bypass, privilege escalation, parameter tampering	http(action="request", ...)
SSTI	A03	Jinja2, Twig, Freemarker, ERB, Pug/Jade, Thymeleaf, engine-specific RCE chains, filter bypass	http(action="request", ...)
XXE	A05	Basic entity, blind/OOB, PHP wrapper, DOCX/SVG injection, Content-Type switching, XInclude	http(action="request", ...), kali(command=...)
NoSQL Injection	A03	MongoDB operator bypass, blind regex extraction, authentication bypass, JS injection	http(action="request", ...), kali(command=...)
GraphQL Injection	A03	Introspection dump, batching abuse, mutation exploit, field suggestion enum, DoS via nested queries	http(action="request", ...)
JWT Attacks	A07	None algorithm, RS256→HS256 key confusion, kid injection, JKU/JWK header, HS256 brute-force	kali(command=...), http(action="request", ...)
HTTP Request Smuggling	A05	CL.TE, TE.CL, TE.TE, H2.CL downgrade, timing detection, smuggle-to-XSS/cache-poison chains	http(action="request", ...), kali(command=...)
CRLF Injection	A03	Header injection, response splitting to XSS, log injection, Set-Cookie injection	http(action="request", ...)
Open Redirect	A01	Parameter fuzzing, 12+ bypass techniques, chaining with OAuth/SSRF/XSS	http(action="request", ...), scan(tool="ffuf", ...)
Web Cache Deception/Poisoning	A05	Path-based deception, un-keyed header poisoning, delimiter discrepancies, normalization	http(action="request", ...)
CORS Exploitation	A07	Origin reflection, null origin, wildcard+credentials, regex bypass, credential theft	http(action="request", ...)

---

Depth Presets

Depth	What runs	Default limits
quick	Automated sqlmap/commix on provided injection point	$0.10
standard	Automated tools + manual payload crafting + multiple techniques	$0.50
thorough	Standard + blind/OOB techniques + chained exploits + race conditions + business logic + deserialization	unlimited

---

Workflow

Before running any tool

If the request does not specify what to exploit, ask the user:

Target: <extracted URL> Suspected vulnerability: <type if mentioned>

Which exploitation depth?

• quick — automated tools on known injection point ($0.10 · 15 min · 10 calls)
• standard — automated + manual, multiple techniques ($0.50 · 45 min · 25 calls)
• thorough — standard + blind/OOB + chained exploits + race conditions (unlimited)

Any known injection points? Auth tokens? Specific parameters to target?

---

Phase 0 — Read the SCAN PHASE, then act

Setup first — the session must exist before you can read the phase:

0. Call session(action="start", options={...}) with target URL, depth, and limits
1. Call report(action="dashboard", data={"port": 7777}) — live findings tracker
2. Call report(action="note", data={...}) — record target, suspected vuln type, known injection points, auth state

Then call session(action="status") and read scan_phase. The scan runs in THREE phases and AUTO-ADVANCES on saturation — you never switch phases yourself:

• exploit — Phase A · DEEP, the primary event. The coverage matrix may build as you discover endpoints (useful for Phase B), but do NOT sweep / bulk-test / auto-crosscut it — those breadth types are refused in Phase A. Hunt the high-value surface and drive every confirmed finding to its maximal terminal (RCE, full account/admin takeover, cross-tenant/mass exfil, internal pivot, cloud takeover) via the Phase 2 → step 6 escalation ladder, and chain the MANDATORY skills (RCE → /post-exploit, LLM/AI → /ai-redteam, creds/JWT → /credential-audit, financial/stateful → /business-logic). File report(action='chain', ...) for every proven kill-chain. The scan advances to coverage once every high/critical finding is driven to a terminal or has a documented dead-end (dismissed escalation_lead).
• coverage — Phase B · SYSTEMATIC breadth. Now build the coverage matrix (Phase 1) and drain it cell-by-cell (Phase 2 core loop). This is the completeness pass; it advances to synthesis at 0 pending cells. (Any deep lead it turns up → escalate it via the step-6 ladder.)
• synthesis — Phase C · COMPOSE. Prove the graph-derived chains (report(action='chain', data={type:'suggest'})), push every held primitive to its maximal terminal (or document a dead-end), then adjudicate and complete.

⚑ DEPTH-FIRST PRINCIPLE. The matrix guarantees breadth — the backstop, not the goal. A confirmed SQLi that dumps one table is a finding; the same SQLi escalated to superuser file-read → RCE → post-exploit is the actual result. Depth (A) runs to completion before breadth (B) begins.

RULE (Phase B/C): never close a parameter as tested without first registering its endpoint and marking the cell in_progress.

This also applies after context compaction — coverage_matrix.json persists and session(action="status") shows exactly where testing left off.

---

Phase 1 — Load or Build Coverage Matrix

Check if the pentester skill pre-built the coverage matrix (call session(action="status") — check coverage.total_cells > 0).

If matrix already exists (chained from /pentester):

• The matrix has endpoints registered and pending cells ready to test
• Skip to Phase 2

If matrix does NOT exist (standalone invocation):

1. Call scan(tool="spider", ...) to map all endpoints and parameters

2. Call scan(tool="ffuf", ...) to discover hidden parameters:

   scan(tool="ffuf", target="URL/endpoint?FUZZ=test", options={"wordlist": "burp-parameter-names.txt"})
   

3. Register every discovered endpoint into the coverage matrix:

   report(action="coverage", data={
     "type": "endpoint",
     "path": "/login",
     "method": "POST",
     "params": [
       {"name": "username", "type": "body_form", "value_hint": ""},
       {"name": "password", "type": "body_form", "value_hint": ""}
     ],
     "discovered_by": "spider",
     "auth_context": "none"
   })
   

   Param type values: path, query, body_form, body_json, header, cookie Value hint values: integer, string, or empty for default

   Each registration auto-generates all applicable injection test cells (e.g., a path/integer param gets sqli, idor, traversal cells; each endpoint also gets endpoint-level cells for cors, csrf, security_headers, etc.).

4. Call report(action="note", data={...}) with total endpoints and cells registered

⚠️ REGISTRATION QUALITY — the #1 cause of a thin matrix. The fan-out can only expand what you register. Two failure modes to avoid:

1. Param-less endpoints. Registering GET /login (the page) is NOT registering the login. Every form is TWO things: the page (GET) and its action (POST /login with username/password). A POST/PUT/PATCH registered with params: [] generates zero injection cells — only the generic cross-cutting checks — and session(complete) will block on it (UNDER-REGISTERED ENDPOINTS). Register the form's action with every field it submits, including hidden fields (user_id, redirect_to, role, order_total — these are prime mass-assignment / IDOR / open-redirect surface; only skip anti-CSRF tokens).
2. Loose param types. Use the canonical type so the right injections fan out: a form body is body_form (adds xxe), a JSON body is body_json (adds prototype + mass_assignment), a URL query is query, a route segment is path. (form/json/body are auto-normalized, but type it correctly so the matrix reads true.)

The spider auto-registers what it finds — forms (with hidden business params), OpenAPI/Swagger operations, and JS routes — so after scan(tool="spider", ...) your job is to verify the matrix, then fill the gaps: any auth/JSON/state-changing endpoint that's missing or param-less, register it yourself before testing.

---

Phase 1b — Source Code Management Exposure

Root pattern: Deployment pipelines that copy entire project directories (including dotfiles) to web roots, or web servers configured to serve all files without filtering hidden directories. The underlying cause is always the same: the web root contains files that were never intended to be public.

How to recognize the surface:

• Any web application — this is deployment-config dependent, not language-dependent
• 403 on /.git/ (directory listing blocked) but 200 on /.git/HEAD (individual files still served) — very common misconfiguration
• Framework error pages or headers revealing the tech stack (helps predict which config files to probe)
• Directory listing enabled on any path → check for dotfiles
• Backup file patterns: index.php~, index.php.bak, .index.php.swp — if editors were used on the server, swap/backup files exist

Probes (send via http(action="request", ...) or scan(tool="ffuf", ...)):

Path	What it reveals
/.git/HEAD	Git repo — if 200, download full repo with git-dumper
/.git/config	Remote URLs, credentials, branch names
/.gitignore	List of sensitive files the devs wanted hidden
/.svn/entries	Subversion repo metadata
/.svn/wc.db	SVN working copy database (SQLite)
/.hg/store/00manifest.i	Mercurial repo
/.bzr/README	Bazaar repo
/.env	Environment variables (DB creds, API keys, secrets)
/.env.bak, /.env.old, /.env.production	Backup env files
/composer.json, /package.json	Dependencies with versions (CVE lookup)
/Dockerfile, /docker-compose.yml	Container config, internal service names
/.github/workflows/	CI/CD pipelines (secrets in env vars, deploy targets)
/Jenkinsfile, /.gitlab-ci.yml	CI/CD config
/wp-config.php.bak, /web.config.bak	Backup config files
/.DS_Store	macOS directory listing (parse with ds_store tool)
/server-status, /server-info	Apache status pages
/.well-known/security.txt	Security contact, sometimes reveals infrastructure

If .git/HEAD returns 200 — full repo extraction:

kali(command="git-dumper http://TARGET/.git/ /tmp/git-dump")
# Or manual:
kali(command="wget -r -np -nH http://TARGET/.git/ -P /tmp/git-dump 2>/dev/null && cd /tmp/git-dump && git log --oneline -20")

Then search the dumped repo for secrets:

kali(command="cd /tmp/git-dump && git log --all --diff-filter=D -- '*.env' '*.key' '*.pem' '*password*' '*secret*' --oneline")
kali(command="trufflehog filesystem /tmp/git-dump --json")

---

Phase 2 — Systematic Parameter Testing (CORE LOOP)

This is the heart of the matrix-driven approach. Instead of going attack-type by attack-type (all SQLi, then all XSS, then all SSRF...), go endpoint by endpoint and test every applicable injection type on every parameter before moving on.

Step 0 — Hidden parameter discovery (run before the loop, on priority 1 and 2 endpoints): The coverage matrix contains only parameters the spider or spec found. Hidden parameters — debug flags, internal fields, undocumented overrides — don't appear in it. Run this on every auth and input-accepting endpoint before testing known params:

scan(tool="ffuf", target="TARGET/endpoint?FUZZ=1", options={"wordlist": "burp-parameter-names.txt"})

Any parameter that returns a different response length, status code, or body → register it in the coverage matrix immediately and add its injection cells to the pending queue. This is how debug=true, admin=1, role=admin, and is_admin=true mass-assignment vectors are discovered — they are never in the spider output.

Priority order for endpoints:

1. Auth endpoints (login, register, password reset) — highest impact
2. Input-accepting endpoints (search, profile, upload, API POST) — most attack surface
3. API endpoints (REST, GraphQL) — often less validated
4. Static/read-only endpoints — endpoint-level tests only

The core loop:

For each endpoint (priority order above):
  For each parameter on that endpoint:
    For each pending injection type (from coverage matrix):
      1. Look up technique in Reference Library (below)

      2. Mark the cell `in_progress` BEFORE running any tool.
         This is the compaction-recovery marker — it tells any future
         resumed session "I was mid-test on this cell". Include what
         you're about to try in the notes so a resume knows where to
         continue from, not restart:
         report(action="coverage", data={
           "type": "tested",
           "cell_id": "cell-...",
           "status": "in_progress",
           "notes": "Starting SQLi — trying error-based first, then UNION, then blind time-based"
         })

      3. Run diagnostic probe(s) via http(action="request", ...) or kali(command=...).

      4. Update the notes as you work through techniques, keeping
         `status: in_progress` until the cell is conclusively done.
         This is critical — if context compaction fires here, the
         agent that resumes reads your notes and knows "oh, error-based
         and UNION are blocked, I was about to try blind time-based":
         report(action="coverage", data={
           "type": "tested",
           "cell_id": "cell-...",
           "status": "in_progress",
           "notes": "Error-based: no errors reflected. UNION: column count wrong. Trying blind time-based next."
         })

      5. Finalize the cell when done. Always include `tested_by` —
         the tool name that actually produced the result. Cells without
         `tested_by` trigger an integrity warning at completion:
         report(action="coverage", data={
           "type": "tested",
           "cell_id": "cell-...",
           "status": "tested_clean",  // or "vulnerable" or "not_applicable" or "skipped"
           "notes": "All SQLi variants tested — input properly parameterized",
           "tested_by": "sqlmap",
           "finding_id": null  // or finding ID if vulnerable
         })

      6. If vulnerable — DEPTH-FIRST: pause the sweep and drive it to terminal NOW.
         File the finding + PoC first (report(action="finding"), http(save_poc), link
         finding_id), THEN escalate the primitive to its maximal terminal before
         returning to the loop. Do NOT bank a stepping-stone and move on. Escalation
         ladder (pursue the applicable rung, then chain report(action="chain")):
           • SQLi → enumerate the DB role (is_superuser / rolsuper / current_user).
             If SUPERUSER: file-read (pg_read_server_file) AND go for RCE via
             COPY … FROM PROGRAM (stacked/temp-table one-liner) — superuser SQLi is an
             exec primitive, not just data theft.
           • file_read (LFI/traversal/pg_read_file) → read config/.env/source →
             secrets/DB creds/signing key; if a PIN-gated console exists, file-read the
             PIN ingredients (/etc/machine-id) → derive PIN → console EVALEX → RCE.
           • SSRF / network_reach → hit internal services AND cloud metadata
             (169.254.169.254 / IMDSv2) → steal IAM/SA creds → chain to /cloud-security.
           • signing_key / jwt_secret leak → forge an admin token → hit privileged routes.
           • RCE obtained → chain into /post-exploit (shell, creds, pivot); if the box is
             a container, /container-k8s-security; if internal hosts reachable, /lateral-movement.
         If a rung is genuinely blocked, record WHY (report(action="update_finding") with a
         dismissed escalation_lead, or session(action="wishlist_add") for an external need) —
         a documented dead-end discharges the depth obligation; a silent skip does not.

Finding granularity rule. File one finding per technique per endpoint — not one finding per technique class across the whole app. "SQLi in /search param q" and "SQLi in /products param category" are two separate findings. This matters for the final report and for tracking which endpoints are fully remediated. A batched finding like "SQLi found in 5 parameters" is a single line in the report, not five actionable tickets.

Multi-technique SQLi gate. For every SQLi cell, you MUST test at minimum error-based, UNION (if SELECT is meaningful), blind boolean, and blind time-based before marking it tested_clean. Sqlmap default mode stops at the first successful technique — tested_clean means ALL applicable variants were tried and failed, not just the first one. Use:

kali(command="sqlmap -u 'URL?param=1' --level=3 --risk=2 --technique=BEUSTQ --batch --random-agent --output-dir=/tmp/sqlmap")

The --technique=BEUSTQ flag forces all six techniques. Never mark SQLi tested_clean after only error-based probing.

Why the in_progress discipline matters. The coverage matrix is the only piece of scan state that survives context compaction. Without in_progress markers, session(action="recovery") returns an empty "what were you doing" list and the resumed agent has to re-derive everything from pentest.log — often re-running tests that were already done or abandoning ones that were almost finished. Every cell that gets tested should transition pending → in_progress → tested_clean/vulnerable. Skipping in_progress is fine for trivial probes, but the integrity check will flag any cell that jumps pending → vulnerable without the intermediate state, because that usually means the cell was bulk-marked from memory instead of actually tested.

Bulk updates — when testing a single injection type against multiple params yields the same result (e.g., all endpoint-level CORS checks return the same policy), use bulk_tested:

report(action="coverage", data={
  "type": "bulk_tested",
  "updates": [
    {"cell_id": "cell-abc", "status": "tested_clean", "notes": "No CORS misconfiguration"},
    {"cell_id": "cell-def", "status": "tested_clean", "notes": "No CORS misconfiguration"}
  ]
})

N/A and skip rules:

• Mark not_applicable when the injection type fundamentally cannot apply (e.g., XXE on a param that never reaches an XML parser)
• Mark skipped ONLY when actively blocked — valid reasons are: WAF returning 403/429 on every probe attempt (include the response in notes), or the test is technically impossible without infrastructure not available in this engagement (e.g., OOB DNS callback with no egress). Budget, time, and "requires careful setup" are NOT valid skip reasons. If you find yourself writing a vague reason, test the cell instead.
• sqli and xss cells on any parameter that accepts text input cannot be marked skipped without a WAF block response in the notes. These are the highest-yield cells in the matrix — skipping them without evidence of blocking is the single most common cause of missed critical findings.
• Never leave cells as pending without testing or explicitly skipping

---

Phase 3 — Endpoint-Level Tests

For each endpoint, test the endpoint-level cells from the matrix:

• CORS: send request with Origin: https://evil.com header, check if reflected
• CSRF: for state-changing endpoints, remove CSRF token and test cross-origin
• Security headers: check response headers (CSP, X-Frame-Options, HSTS, etc.)
• Rate limiting: send 20+ rapid requests, check for throttling
• Method tampering: send unexpected HTTP methods (GET↔POST, PUT, DELETE, PATCH) AND non-standard verbs (OPTIONS, TRACE, PROPFIND, BOGUS, FOO) when the endpoint returns 401/403 — Apache <Limit> and J2EE <security-constraint> only protect verbs they list, unlisted verbs bypass auth entirely. Load refs/parameter-tampering.md for the verb-bypass section.
• Cache: check Cache-Control on authenticated pages, test web cache deception
• JWT: if JWT auth, test none algorithm, key confusion, kid injection
• Race conditions: for state-changing operations, test parallel requests

Cookie / session token structure — for every session/auth cookie, decode and inspect before treating it as opaque:

1. Base64-decode the cookie. Check magic bytes of the result:
   • \x80\x04 or \x80\x05 → Python pickle — immediately suspect pickle.loads() RCE. See refs/deserialization.md.
   • eyJ (base64 of {") → JWT — run jwt_tool against it.
   • rO0AB (base64 of \xAC\xED\x00) → Java serialized object — try ysoserial.
   • O: prefix → PHP serialized object — try POP chain attacks.
   • Plain JSON → check for role/user_id fields and try mass-assignment / IDOR tampering.
2. URL-decode and decompress (zlib, gzip) nested layers.
3. If the cookie is Flask's default (. separator, signed), try flask-unsign --decode and --unsign with rockyou.txt — if the SECRET_KEY is weak you can forge any session.
4. If the value is binary and non-printable, treat it as serialized data until proven otherwise — do not assume it's random.

Hidden and non-linked endpoints — spiders only follow visible links. On every authenticated page and every form-carrying HTML page, manually extract every href, src, action, formaction, and fetch(...) URL — even those that are display:none, type="hidden", or only referenced in JavaScript. Register any new ones into the coverage matrix before continuing. Flag-bearing endpoints in CTFs and hidden admin routes in real apps are almost always in this set — not in the spider's output.

kali(command="curl -s -b 'session=...' http://TARGET/profile | grep -oE '(href|src|action|formaction)=[\"\\x27][^\"\\x27]+' | sort -u")
kali(command="curl -s http://TARGET/main.js http://TARGET/app.js http://TARGET/bundle.js 2>/dev/null | grep -oE '(fetch|axios\\.get|axios\\.post|\\$\\.ajax)\\([^)]*' | head -40")

Inline source read on every 401/403 — when any endpoint returns 401 or 403, immediately spend one round trying to read the source before fuzzing. The most common wins: the .htaccess itself (reveals <Limit>), adjacent backup files (index.php.bak, .htaccess.orig), .git/HEAD (full repo extract), framework error pages (leak paths and versions). See Phase 1b for the full probe list. Source read is almost always faster than blind fuzzing when the filter is non-obvious.

CMS detection → mandatory plugin scan — if the target shows any CMS signal (/wp-content/, /wp-includes/, /sites/default/, /administrator/, <meta name="generator" content="WordPress...">, X-Generator: Drupal, Joomla! in HTML), immediately run the CMS-specific scanner before continuing with generic web testing. 90%+ of CMS compromises come from plugin CVEs — the plugin/theme enumeration phase finds exploits that generic web fuzzing never will. See refs/cms-cves.md.

# WordPress
kali(command="wpscan --url TARGET --enumerate vp,vt,u1-10 --plugins-detection aggressive --random-user-agent --disable-tls-checks")
# Drupal
kali(command="droopescan scan drupal -u TARGET")
# Joomla
kali(command="joomscan -u TARGET")

The scanner output lists every known CVE affecting installed plugins/themes. Cross-reference any hit with searchsploit <plugin-name> and fire the matching exploit.

Update each cell in the matrix as you go.

---

Phase 4 — Re-spider on Surface Expansion

The coverage matrix is NOT static — it grows as the attack surface expands. This creates a feedback loop:

┌─────────────────────────────────────────────────┐
│                                                 │
│  ┌──────────┐    ┌──────────────┐    ┌────────┐ │
│  │ Discover │───→│ Register new │───→│ Test   │ │
│  │ (spider) │    │ endpoints +  │    │ new    │ │
│  │          │    │ auto-generate│    │ pending│ │
│  └──────────┘    │ matrix cells │    │ cells  │ │
│       ▲          └──────────────┘    └───┬────┘ │
│       │                                  │      │
│       │    ┌──────────────────────┐      │      │
│       └────│ New creds / dirs /   │◄─────┘      │
│            │ privilege escalation │              │
│            └──────────────────────┘              │
└─────────────────────────────────────────────────┘

Triggers that restart the discovery-test loop:

• Valid credentials discovered → re-spider with auth cookie → new authenticated endpoints → register new endpoints → new matrix cells → injection testing on all new cells
• Fuzzing reveals new directory tree → re-spider that subtree → new endpoints → new cells → testing
• Privilege escalation achieved → re-spider as higher-privilege user → admin endpoints → new cells → testing
• New subdomain or vhost discovered → re-spider the new host → full new endpoint set → testing

Key invariant: Every new endpoint registered via add_endpoint() auto-generates ALL applicable injection test cells as "pending". The agent always works from pending cells in Phase 2. This guarantees that no new endpoint escapes injection testing — the matrix enforces completeness.

Re-spider preserves existing work: Existing endpoints and their cells are unchanged. Only genuinely new endpoints (deduplicated on (normalized_path, method)) get added.

After re-spider + registration, resume Phase 2 from the new pending cells.

---

Phase 5 — Chain Exploitation (active loop — LOOK SIDEWAYS, not just forward)

After systematic testing, combine confirmed vulnerabilities into multi-step attack chains. An isolated medium-severity finding becomes critical when it enables a full compromise chain. Run this as a loop, not a one-shot review:

1. Pull the graph's proposals. Call report(action="chain", data={type:"suggest"}) — it returns graph-derived candidate chains, including cross-finding primitive bridges ("finding B PROVIDES the capability finding A is blocked on"). Prove and file the promising ones.
2. Before you EVER conclude a chain step is "blocked", look sideways. A step blocked on a missing primitive — file-read, a secret/PIN, internal network reach, a signing key — is usually not a dead-end: check whether another confirmed finding already PROVIDES that primitive. The canonical miss: a PIN-locked Werkzeug /console needs a file-read (/etc/machine-id) — and a confirmed Postgres SQLi provides exactly that via pg_read_server_file. Bridge them: SQLi file-read → PIN → EVALEX → RCE.
3. Declare a block only after you've (a) run type=suggest AND (b) scanned the other findings + known_assets for a provider. If it's a genuine dead-end, record why via report(action="update_finding", ...) (or session(action="wishlist_add") if it needs an external resource) — never a silent skip. If the harness surfaces a COMPOSITIONAL BRIDGE steer naming a provider, act on it.
4. File every proven bridge with report(action="chain", data={name, steps:[{from_finding_id, to_finding_id, transition_artifact_id, mitre_technique}]}) — each transition artifact-backed.

See refs/capability-chaining.md for the full PROVIDES/REQUIRES capability table, more worked bridges (SSRF→IMDS→cloud, leaked-secret→JWT-forge), and the "borrow the primitive sideways" method. Load it whenever a chain step is blocked on a missing primitive.

Also see Reference Library § Chained Exploitation Examples for forward patterns (SQLi→file read→config→RCE, upload→traversal→web shell, SSRF→IMDS→creds→S3, LFI→source→deser→RCE). Document every chain in report(action="diagram", data={...}).

---

Phase 6 — Coverage Gap Report

Review the coverage matrix for any remaining pending or skipped cells:

1. Call session(action="status") — check coverage stats
2. Burn down pending cells MECHANICALLY before hand-testing or skipping — do NOT close them one-by-one:
   • report(action="coverage", data={type:"sweep", max_cells:60}) — repeat until it returns no more candidates; it probes + auto-closes pending injection cells (sqli/xss/ssti/cmdi/traversal) and hands you oracle-positives to confirm + file.
   • report(action="coverage", data={type:"auto_crosscutting"}) — bulk-close app-wide CORS / security-header / CSRF / cache cells in one call.
   • For what remains: report(action="coverage", data={type:"next_batch"}) → test with REAL probes → report(action="coverage", data={type:"bulk_tested", updates:[...]}). Mark skipped only with a documented reason — never bulk-skip to clear the count.
3. Call report(action="note", data={...}) with a coverage summary: "Coverage: X/Y tested, Z vulnerable, W N/A, V skipped"
4. The session completion gate requires the coverage matrix worked to its floor (or a human approves the remaining gaps via the stuck-completion HIR)

---

Phase 7 — Verification & PoC

For every confirmed exploit:

1. Call report(action="note", data={...}) explaining what you're verifying
2. Reproduce with http(action="request", ...) — craft the minimal working payload
3. Call http(action="request", options={"poc": true}) to route through Burp Suite
4. Call http(action="save_poc", ...) with descriptive title (e.g., sqli-oob-dns-mssql-xp-dirtree)
5. Call report(action="finding", data={...}) with:
   • severity: based on impact (RCE=critical, data access=high, info disclosure=medium)
   • description: Include OWASP Web Top 10 category
   • evidence: Raw request/response

---

Phase 8 — Report & Wrap-Up

1. Call report(action="diagram", data={...}) with attack flow diagram showing all exploit chains:

flowchart TD
    Entry["Initial Entry Point"] --> Inject["SQL Injection /search?q="]
    Inject --> DBAccess["Database Access"]
    DBAccess --> Creds["Credential Dump"]
    Creds --> Admin["Admin Panel Access"]
    Admin --> Upload["File Upload Bypass"]
    Upload --> RCE["Remote Code Execution"]

2. Call session(action="complete", options={...}) with summary of all confirmed exploits
3. Chain to /post-exploit if RCE was achieved
4. Chain to /ai-redteam if an LLM/AI endpoint was discovered during exploitation (chat APIs, completion endpoints, RAG search, agentic tool-use endpoints, MCP servers). Web exploitation often touches these surfaces — when it does, hand off for OWASP LLM Top 10, AITG, and MCP Top 10 testing instead of stopping at the HTTP layer.
5. If the user asks to file GitHub issues — invoke /gh-export

---

Phase 9 — ASVS Black-Box Verification Checklist (MANDATORY — thorough depth)

This checklist covers OWASP ASVS requirements that ARE testable from a black-box perspective. Run through every applicable test after completing Phases 2-8. Many of these are commonly missed by automated tools.

AUTH (ASVS V2 — Authentication):

#	Test	How to test	Finding if failed
A1	Password length limits	Try registering with 1-char and 200-char passwords. Min should be ≥8, max should be ≥64	Weak password policy
A2	Password breach check	Register with P@ssw0rd123 and other known-breached passwords — should be rejected	No breach-list validation
A3	Paste into password field	Check if password fields have autocomplete="off" or block paste — they should NOT block paste	Anti-usability password field
A4	Rate limiting on login	Send 20 rapid login attempts with wrong passwords — should be rate-limited or locked after ~5-10	No brute-force protection
A5	Default credentials	Try admin:admin, admin:password, test:test on login — should not work	Default credentials active
A6	Account lockout notification	After triggering lockout, check if the real user is informed (email/UI)	Silent account lockout
A7	Password change requires current	Try changing password without providing current password	Missing reauthentication
A8	Recovery token single-use	Request password reset, use the link, then try using the same link again	Reusable recovery token
A9	Authentication response timing	Compare response time for valid username/wrong password vs invalid username — should be equal	Timing-based user enumeration

SESSION (ASVS V3 — Session Management):

#	Test	How to test	Finding if failed
S1	New session on login	Compare session token before and after login — must change	Session fixation
S2	Session invalidation on logout	Save session token, log out, try reusing it	Session persistence after logout
S3	Idle timeout	Wait 15+ minutes, try using session — should be expired (configurable, but should exist)	No session timeout
S4	Absolute timeout	Keep session alive for 8+ hours with periodic requests — should eventually expire regardless	No absolute timeout
S5	Concurrent session control	Log in from two browsers — check if app limits concurrent sessions or shows active sessions	No concurrent session control
S6	Session token entropy	Collect 10+ session tokens, check length and character set — should be ≥128 bits of entropy	Weak session tokens
S7	Cookie flags	Check Set-Cookie for HttpOnly, Secure, SameSite, Path	Missing cookie security flags
S8	Session token not in URL	Check that session IDs never appear in URLs, redirects, or Referer headers	Session token URL exposure

ACCESS (ASVS V4 — Access Control):

#	Test	How to test	Finding if failed
AC1	Mass assignment	Add extra fields to registration/update requests (role, isAdmin, verified, balance)	Mass assignment vulnerability
AC2	CSRF on state changes	For every POST/PUT/DELETE: remove CSRF token, try cross-origin — must fail	Missing CSRF protection
AC3	HTTP verb tampering	Send GET instead of POST (and vice versa) to state-changing endpoints	HTTP verb tampering

INPUT (ASVS V5 — Validation, Sanitization, Encoding):

#	Test	How to test	Finding if failed
I1	HTTP Parameter Pollution	Send duplicate parameters: ?id=1&id=2 — check which value is used	HPP vulnerability
I2	SSTI	Send {{7*7}} in every reflecting parameter — check for 49 in response	Template injection
I3	SMTP header injection	In contact/email forms, inject \r\nBcc: [e-mail] into email fields	SMTP injection
I4	SVG XSS	Upload SVG with <script>alert(1)</script> or <svg onload=alert(1)> as a .svg file — check if served as image/svg+xml and executes in browser; also test SVG in any image-accepting upload	SVG XSS
I4a	Stored XSS source-sink matrix	For every input that persists (profile, comments, names, addresses, preferences, rich-text fields): confirm payload appears on a page AND is not encoded. Test sinks: innerHTML, eval, document.write, href with user input, on* event handlers, template literals. Use <img src=x onerror=alert(1)>, <svg/onload=alert(1)>, and javascript:alert(1) in each. Register each source+sink pair as a separate finding.	Stored XSS
I5	Markdown injection	If app renders Markdown, inject [click](javascript:alert(1))	Markdown XSS
I6	JSON injection	In JSON inputs, send {"key":"value","__proto__":{"isAdmin":true}}	Prototype pollution / JSON injection
I7	LDAP injection	If LDAP auth is used, try `)(uid=))(	(uid=*` in username

LOGIC (ASVS V11 — Business Logic):

#	Test	How to test	Finding if failed
L1	Flow step skipping	In multi-step flows, skip directly to final step (e.g., go to /checkout without /cart)	Missing flow enforcement
L2	Timing attacks	Compare response times for valid vs invalid inputs in sensitive operations	Timing side channel
L3	Rate limits on sensitive ops	Rapidly repeat password reset, OTP requests, API key generation	Missing rate limiting
L4	Anti-automation	Submit forms rapidly with scripted requests — should be CAPTCHA or rate-limited	No anti-automation
L5	Business rule bypass	Test negative quantities, zero-price, duplicate coupon use, self-referral	Business logic bypass

FILES (ASVS V12 — Files and Resources):

#	Test	How to test	Finding if failed
F1	Upload size limit	Upload a very large file (100MB+) — should be rejected promptly	No upload size limit
F2	Zip bomb	Upload a zip bomb (42.zip or similar) — should be detected or limited	Zip bomb DoS
F3	Upload to webroot	Check if uploaded files are stored in web-accessible directory with original names	Upload to webroot
F4	HTML execution	Upload an HTML file — check if it's served with text/html content type	Stored XSS via HTML upload

API (ASVS V13 — API Security):

#	Test	How to test	Finding if failed
AP1	Content-Type enforcement	Send JSON body with Content-Type: text/plain — should be rejected	Content-Type not enforced
AP2	Verb tampering on API	Send PUT/PATCH/DELETE to read-only endpoints — should be rejected	API verb tampering
AP3	Schema validation	Send unexpected field types (string where int expected, nested objects, arrays)	Weak API schema validation
AP4	API CSRF	State-changing API with cookie auth — test cross-origin request without CORS preflight	API CSRF
AP5	Parser differential	Send request that could be parsed differently by proxy vs app (e.g., duplicate Content-Length)	HTTP request smuggling surface

CONFIG (ASVS V14 — Configuration):

#	Test	How to test	Finding if failed
C1	Dependency CVEs	Check response headers for framework/library versions, cross-reference with CVE databases	Known vulnerable dependency
C2	Subresource integrity	Check if external JS/CSS includes have integrity attribute	Missing SRI
C3	CSP quality	Check Content-Security-Policy header — unsafe-inline and unsafe-eval weaken it significantly	Weak CSP
C4	Cache-Control on sensitive pages	Check if authenticated pages have Cache-Control: no-store	Sensitive data cached
C5	Sensitive data in client storage	Check localStorage and sessionStorage for tokens, PII, or secrets via browser console	Client storage data exposure

How to use this checklist:

1. Go through each row sequentially
2. For each test, make the HTTP request and evaluate the result
3. If a test reveals a vulnerability, call report(action="finding", data={...}) immediately
4. Mark N/A for tests that don't apply (e.g., no file upload endpoint → skip F1-F4)
5. Call report(action="note", data={...}) with a summary of all ASVS checks and their pass/fail status

Phase 9 completion gate (thorough depth ONLY): Before calling session(action="complete"), you MUST:

• Have a report(action="note") entry listing every Phase 9 row as PASS, FAIL, or N/A
• Every FAIL must have a corresponding report(action="finding") entry
• The completion call will be blocked otherwise — do not skip this gate
• Log the completion note as: "ASVS Phase 9 complete: A1:pass, A2:pass, ..., I4:fail (SVG XSS), ..."

---

Context Recovery After Compaction

When your context is compacted mid-scan:

1. Re-invoke /web-exploit — use the Skill tool to reload this full workflow
2. Call session(action="status") — coverage stats in the response tell you exactly where you are
3. Pending cells tell you where to resume — the matrix persists in coverage_matrix.json
4. Do NOT re-register endpoints — they persist across context compactions
5. Resume Phase 2 from pending cells — the matrix enforces completeness

---

Reference Library — Lazy Loading

Instead of loading all 25 injection technique references at once (~25k tokens), load ONLY the reference you need for the current test. This saves 74% of context window space.

How to load: Before testing an injection type, read the relevant reference file. Try these paths in order (first one that exists):

skills/web-exploit/refs/{filename}
~/.claude/skills/web-exploit/refs/{filename}
~/.config/opencode/commands/web-exploit-refs/{filename}

Injection Type	Reference File	Tokens	Load when testing...
SQL Injection	refs/sqli.md	~1776	sqli cells
NoSQL Injection	refs/nosqli.md	~956	nosqli cells
GraphQL Injection	refs/graphql.md	~1329	graphql cells
Cross-Site Scripting (XSS)	refs/xss.md	~1603	xss cells
CSS Injection	refs/css-injection.md	~619	css-injection cells
Server-Side Template Injection (SSTI)	refs/ssti.md	~736	ssti cells
SSRF Exploitation	refs/ssrf.md	~202	ssrf cells
Command Injection	refs/cmdi.md	~144	cmdi cells
File Upload Bypass	refs/file-upload.md	~1003	file-upload cells
Path Traversal / LFI	refs/traversal-lfi.md	~969	traversal-lfi cells
XML External Entity (XXE) Injection	refs/xxe.md	~711	xxe cells
Deserialization Exploitation	refs/deserialization.md	~1380	deserialization cells
Race Condition Exploitation	refs/race-condition.md	~1035	race-condition cells
Parameter Tampering & Business Logic Flaws	refs/parameter-tampering.md	~1067	parameter-tampering cells
Session Management Testing	refs/session-management.md	~1736	session-management cells
Cross-Site Request Forgery (CSRF)	refs/csrf.md	~400	csrf cells
JWT Attacks	refs/jwt.md	~1048	jwt cells
Open Redirect	refs/open-redirect.md	~1022	open-redirect cells
CRLF Injection / HTTP Response Splitting	refs/crlf.md	~635	crlf cells
HTTP Request Smuggling	refs/http-smuggling.md	~934	http-smuggling cells
CORS Exploitation	refs/cors.md	~899	cors cells
Web Cache Deception / Poisoning	refs/web-cache.md	~994	web-cache cells
OAuth Misconfiguration	refs/oauth.md	~868	oauth cells
Prototype Pollution	refs/prototype-pollution.md	~1078	prototype-pollution cells
Out-of-Band Exfiltration (blind vulns)	refs/oob-exfil.md	~1400	any confirmed-but-blind vuln (blind SQLi/XXE/SSRF/SSTI/cmdi, or flag in env)
Nginx Alias / Off-by-Slash Traversal	refs/nginx-alias-traversal.md	~900	Server: nginx + any prefix where /foo/ and /foo return different content
Advanced IDOR (ID structure attacks)	refs/idor-advanced.md	~1400	opaque IDs (UUID, MongoDB ObjectID, Snowflake) before sequential enumeration
CMS Plugin / Theme / Core CVEs	refs/cms-cves.md	~1600	WordPress / Drupal / Joomla / Magento targets (/wp-content/, /sites/default/, /administrator/)
Chained Exploitation Examples	refs/chains.md	~2334	chains cells

Rules for reference loading:

• Load the reference BEFORE you start testing that injection type
• Only load 1-2 references at a time — don't pre-load all of them
• For chained exploitation, load refs/chains.md after confirming individual vulns
• The core workflow above has everything you need to manage the matrix — refs are just technique details

---

Chaining Other Skills

Skill	When to invoke
/post-exploit	RCE achieved — privilege escalation, credential harvesting, persistence
/analyze-cve	CVE-affected component discovered (vulnerable framework, library, or plugin) — trace exploitability with full source-to-sink context
/credential-audit	Credential material recovered (hashes, cleartext creds, user list) or auth endpoint identified — chain for systematic credential testing
/lateral-movement	Credentials obtained that may be reusable across services — pass-the-hash, password reuse, NTLM relay
/ai-redteam	LLM/AI endpoint discovered during exploitation — chat APIs, completion endpoints, RAG search, agentic tool-use endpoints, MCP servers. Hand off for OWASP LLM Top 10, AITG, and MCP Top 10 testing instead of stopping at the HTTP layer. Common signals: prompt-shaped POST bodies, messages[] arrays, system/user/assistant roles, streaming SSE responses, model name parameters
/gh-export	When user asks to file GitHub issues