mcpField
H
hunt-exceptional-conditions

hunt-exceptional-conditions

github.com/elementalsoulsSecurity5.3k195 installsUpdated today
Repository

About hunt-exceptional-conditions

A security skill for finding verbose error disclosures and fail-open behavior in applications. It guides testers to vary input assumptions and confirm leaks from response bodies, rather than treating status codes alone as evidence.

Key features

  1. 01Probe unexpected input types and formats
  2. 02Inspect response bodies for error details
  3. 03Recognize framework-specific disclosure signatures
  4. 04Capture leaked paths, versions, and stack frames

Use cases

  1. 01Testing typed JSON API fields
  2. 02Checking numeric and search parameters
  3. 03Reviewing malformed upload requests
  4. 04Validating suspicious server errors

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/elementalsouls/claude-bughunter --skill hunt-exceptional-conditions

After installing, type/hunt-exceptional-conditionsin Claude Code to confirm it loaded.

Details

From the project README

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).

Comments

Markdown supported