Param Discover

Param Discover finds hidden / undocumented parameters on a target endpoint by fuzzing parameter names against a wordlist and looking at how the response changes. Different from Nerve (which classifies params you’ve already seen) — Param Discover surfaces params you haven’t seen.

The classic use case: an API endpoint accepts ?id=123 openly, but actually also honours ?debug=true, ?role=admin, or ?internal=1 — Hugin batch-fuzzes 1000s of names per request and uses response diffing to flag promising candidates.

🔗How It Works

  1. Send a baseline request to the target.
  2. Send batches of N parameters per request (configurable batch_size), each with a unique value, injected into the chosen location (query / body form / body JSON / header / cookie).
  3. Compare each batch’s response against the baseline.
  4. When a batch differs, promote all members of that batch to “candidates” and verify each individually with an isolated single-param request.
  5. Report confirmed params with the diff signal that flagged them.

🔗Configuration

  • Target URL — base endpoint to test
  • Method — GET, POST, or auto-detect from a captured flow
  • Insertion location — query, body (form-urlencoded), body (JSON), header, or cookie
  • Wordlist — built-in or custom (see Wordlists)
  • Concurrency — parallel batches (default 10)
  • Per-host delay (ms)
  • Detection sensitivity — Strict (any change) / Normal (significant diff) / Loose (only major changes)

🔗Built-in Wordlists

The shared wordlists module ships several curated lists. The two most relevant for parameter discovery:

  • params (PARAMS_BUILTIN) — common parameter names worth fuzzing
  • header_params (HEADER_PARAMS_BUILTIN) — when the insertion location is Header

Reference them by their built-in identifier, or supply your own via the wordlist, wordlist_file, or wordlist_command source. See Wordlists for details.

🔗Diff Signals

Each candidate is classified by what changed:

  • Status diff — response status code differs from baseline
  • Length diff — body length differs by more than the configured threshold
  • Content diff — body hash differs (caught new content)
  • Time diff — response time meaningfully different (potential server-side processing)
  • Header diff — response headers differ
  • Reflection — the parameter name or value reflects in the response

Confirmed params are listed with their signal. Click any to see the side-by-side diff view.

🔗Workflow Integration

  • From Sitemap — right-click a path → Run Param Discover to fuzz that exact endpoint with project-default settings
  • From Logger — right-click a flow → Send to Param Discover uses the captured request as baseline
  • From Findings — discovered params can be sent straight to Intruder for value fuzzing

🔗Two-Phase Detection

Param Discover uses a two-phase approach to keep request volume down:

  1. Batch phase — N params per request (configurable, default low double digits). Catches divergence but doesn’t pinpoint the exact param.
  2. Verification phase — for each batch that differed from baseline, every member is verified individually to filter coincidences and identify the actual offending parameter.

A 5000-word wordlist with batch_size: 10 runs ~500 batched requests in phase 1, then up to ~10 × (number of differing batches) verifications in phase 2 — far cheaper than 5000 isolated requests.

🔗MCP

The param_discover MCP tool exposes:

  • run — full fuzzing run with config
  • check — quick check of a single parameter

🔗Tips

  • Always test with the Strict sensitivity first if the target seems quiet — endpoints with caching or random response variance need stricter thresholds.
  • Run against authenticated and unauthenticated states separately. Some params only show effect when authenticated.
  • The admin-params wordlist is high signal-to-noise; great for first-pass discovery.
  • Combine with Nerve — once Param Discover finds a param, Nerve will tell you what bug class it likely targets.