Hunt exceptional conditions
Skill elementalsouls/Claude-BugHunter/skills/hunt-exceptional-conditions
Hunt mishandling of exceptional conditions — feed an endpoint malformed/unexpected input (wrong type, broken JSON, oversized field, null byte) and make it fail OPEN or leak internals: a verbose stack-trace / framework error page that discloses ORM internals, server file paths, library versions, or a language traceback. Use on any input-accepting endpoint (JSON APIs, forms, query params). Medium-High when the leak exposes internal structure that arms a deeper attack.From its SKILL.md
npx -y skills add elementalsouls/Claude-BugHunter --skill hunt-exceptional-conditionsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
3.1 KB, 653 tokens by cl100k_base, as published. Nobody here has run it
HUNT-EXCEPTIONAL-CONDITIONS — Verbose Errors / Fail-Open (A10:2025)
What actually pays
Well-built apps catch errors and return a clean, generic message. A broken app, when handed input it didn't expect, throws an unhandled exception and renders a developer error page straight to the client — leaking the stack trace, the ORM/query internals, server-side file paths, and framework/library versions. That disclosure is the finding (and it arms SQLi/RCE/path attacks next).
Recon
Any endpoint that parses input is a candidate; the richest are:
JSON APIs that expect typed fields: POST /api/* with {numbers, ids, enums}
Endpoints with numeric/id path or query params: /item/{id}, ?page=, ?quantity=
Search / filter / sort params
File or content-type sensitive uploads
Attack — send what the code didn't anticipate
Take a known-good request and break ONE assumption at a time:
- Wrong type: a field the app expects to be a number/string is sent as an
array or object —
{"rating":"x","comment":[1,2,3]},{"quantity":{}}. - Malformed body: truncated/!invalid JSON, an unterminated string, a stray brace, a wrong/missing Content-Type.
- Boundary/oversized: a very long string, a huge/negative/overflow number.
- Null byte / control chars embedded in a value.
POST /api/Feedbacks {"rating":"notanumber","comment":[1,2,3]}
GET /item/' OR /item/%00 (also exercises the error path)
Watch the RESPONSE BODY, not just the status: a 500 (or even a 200/400) whose body contains a stack trace or framework error page is the signal.
What counts as a leak (the success signal)
A finding is confirmed when the response body contains a cross-framework error-disclosure signature:
- Node/Express + Sequelize:
SequelizeDatabaseError,node_modules/sequelize, a JS stack with internal paths. - PHP:
<b>Warning</b> ... /var/www/.../file.php on line N. - Python:
Traceback (most recent call last),werkzeug.exceptions. - Java:
at com.app.Foo(Foo.java:42)stack frames. - .NET:
Server Error in '/' Application, a[System.XxxException: ...]YSOD.
A clean JSON error ({"error":"Invalid input"}) with no internals is NOT a
finding — that's correct handling. Disclosure of internal structure is.
Validation discipline
- Capture the exact leaked artifact (path, ORM class, version, stack frame) — that's the evidence. "It returned 500" alone is not disclosure.
- Note what the leak enables next (e.g. a disclosed SQL error → hunt-sqli; a disclosed absolute path → hunt-lfi).
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most error diagnosis skills give in 653 tokens
Counted across 135 of the 162 authors here whose files we hold, read 2026-09-06
- Handle, re-throw, or log in every catch blockin 12 of 135, across 7 files
- Use typed error classes over string messagesin 11 of 135, across 6 files
- Log full error context server-sidein 10 of 135, across 5 files
- Document every error code clients may receivein 9 of 135, across 4 files
- Surface errors at the boundary where they occurin 9 of 135, across 4 files
- Wrap React components in an ErrorBoundaryin 9 of 135, across 4 files
- Wrap errors with context, never lose the originalin 9 of 135, across 4 files
- Use the standard error envelope for API responsesin 9 of 135, across 4 files
- Retry only retriable errors, never 4xx client errorsin 8 of 135, across 3 files
- Retry transient failures with exponential backoff and jitterin 8 of 135
- Show users friendly messages without technical detailsin 7 of 135, across 3 files
- Use the Result pattern for expected failuresin 7 of 135, across 5 files
Said here and by no other author read
- feed endpoints input they don't expect
- break one request assumption at a time
- send fields as wrong types like arrays or objects
- send truncated or invalid JSON and wrong content-type
- send oversized, negative, or overflow values
- embed null bytes or control characters in values
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.