An agentic security scanner that reasons forward from attacker-accessible entry points, VulnHunter verifies exploitable defects with PoCs and drives test-based remediation in authorized code audits.

VulnHunter occupies an interesting niche in the current generation of security tooling: it is an open-source, agentic AI scanner that explicitly rejects the passive pattern-matching posture of traditional SAST engines. Developed originally inside Capital One and released under Apache-2.0, the project now lives on in this maintained fork by nealbridges, which carries 614 stars at time of writing and is implemented primarily in Python. What the fork changes is less about the hunting methodology and more about where and how reliably that methodology runs — harness portability, sandboxed exploit validation, and PoCs that measure impact rather than narrate it.

The core conceptual inversion is what the README calls attacker-first forward analysis. Conventional static analyzers work sink-first: they enumerate dangerous code patterns like tainted SQL string concatenation or unsafe deserialization, then reason backward toward a hypothetical attacker, which is where the false-positive flood originates. VulnHunter flips the direction. It starts at attacker-accessible entry points — APIs, network messages, file uploads — and reasons forward along the attacker's actual journey to determine whether a defense genuinely breaks. In one documented benchmark run, 315 attacker-controlled inputs were inventoried in a single scan, each one traced and each disposition written down, which signals a discipline of completeness rather than a scatterscan.

The second architectural pillar is the falsification engine. Once a candidate vulnerability is identified, a structured reasoning workflow attempts to disprove the finding itself: it hunts for flawed assumptions, logic gaps, or existing security controls that would block the attack path, and discards anything resting on unsupported premises. The README reports that 55% of candidate findings were eliminated or downgraded by this adversarial verification pass before reaching the operator. The roadmap goes further, adding an independent adversarial verifier — a separate agent whose sole purpose is attacking the finding, rather than letting the hunter grade its own homework. That framing reads as a candid acknowledgment of the self-evaluation bias inherent in single-agent LLM pipelines.

The fork distinguishes itself most sharply on harness neutrality. Upstream, the skills invoke Claude Code specifically, the installer targets ~/.claude/skills, and model gates hardcode particular Opus models. Here, every skill is a portable prompt file with an explicit environment contract: VULNHUNT_SKILLS_DIR, VULNHUNT_AGENTS_DIR, VULNHUNT_BIN_DIR, VULNHUNT_HOST_CMD, and VULNHUNT_MODEL. Model gates are rephrased to request your harness's most capable reasoning model instead of a named vendor product. The maintainer's argument is blunt — a security methodology that installs into only one agent harness stops being an audit capability and starts being a vendor feature. You supply your own model access, and the methodology is positioned as prompt procedure, not tool binding.

The installer itself received a no-guess redesign. Where upstream copied skills into ~/.claude/skills unconditionally, the fork either asks or reads the environment variables, writes a vh launcher to VULNHUNT_BIN_DIR or ~/.local/bin, installs the vulnhunter-run skill plus an agent definition, and updates Windows .cmd equivalents. On a machine running two harnesses, or one with a relocated home directory honored through GROK_HOME semantics, the old installer would silently write to the wrong location; the fork fails loudly with the exact missing instruction instead. It is a small thing, but silent misconfiguration is exactly the kind of defect a security tool should not ship.

The most technically consequential change is execution depth as a recorded decision. The fork maintainer discloses a striking measurement: six full scans of one commit of a production Go service, across five harness/model stacks, produced anywhere from 3 to 42 findings — a 14× spread — including opposite verdicts on the same sink depending on whether validation ran against a mock or a real containerized server. The fix is a runtime-provisioning procedure, Docker-first, with the chosen runtime recorded per finding, and a requirement that Medium-plus severity findings must actually execute. The PoC discipline extends to measured impact: rows exposed, requests amplified, key-hours stranded — numbers, not adjectives. Where a finding lacks a working PoC, it is labeled as such so the operator always knows the evidentiary weight of what they are reading.

Operationally, the tool ships as three composable agent skills forming a closed remediation loop. /vulnhunt is the hunt phase: it maps entry points to dangerous sinks and filters through a multi-stage pipeline labeled Recon → Parallel Hunt → Adversarial Disprove → Capability Filter, emitting only verified issues with an executable exploit and a proposed fix. /vulnhunter-fix is the remediation phase, and notably it is developer-led and test-driven in classic TDD style: write an exploit demo, create a failing security test (RED), implement the fix (GREEN), verify the exploit is blocked without regressions, and cut a reviewable PR. /vulnhunt-fix-verify is a deliberately separate, read-only agent that independently validates remediation and emits a per-finding verdict. The README even clarifies the naming asymmetry — the suite is VulnHunter but the scanner command is the shorter /vulnhunt, which is intentional and worth knowing before you file a confused bug report.

For running the loop unattended, the repository provides vulnhunter-agent/, a headless runtime wrapper, while harness/ drives batch scans across multiple repositories. The new vulnhunter-run operator skill encodes the full sequence — clone, hunt, locate results, write and validate the scan manifest — with explicit stop rules and no improvisation, which is the difference between a tool you demo and a tool you schedule nightly. Benchmark tooling gains model configuration via environment, retry and backoff knobs, and an analyze_misses pipeline for loss-point tracing on missed findings, giving maintainers visibility into where the methodology loses candidates rather than just what it eventually reports.

The dual-use posture deserves attention from any professional evaluating this for organizational deployment. The README is upfront that the underlying work is vulnerability discovery and exploitation, and that most commercially available models apply dual-use cyber safeguards that can rate-limit or flag aggressive exploitation behavior. The fork's development reportedly ran on open-weight, community-provided models it describes as de-risked, abliterated, and uncensored. Practitioners should read that candidly: the tool's effectiveness is coupled to the permissiveness of the model backing it, and running it against anything other than code you own or are contractually authorized to audit falls outside both its stated intent and responsible use. This article treats it strictly as documented, educational analysis for authorized assessment contexts.

From a defensive and observability standpoint, VulnHunter leaves a legible footprint. Running it produces sustained LLM API consumption, Docker container provisioning for sandboxed validation, repository clone activity, and a growing pile of scan artifacts — per-input disposition tables, adversarial verdict tables, PoCs, and executed exploit tests. In benchmark runs the maintainers report 42 out of 42 confirmed findings carried executable exploit tests, all passing, and 20 adversarial payloads executed against a live sandboxed server with measured outcomes. For a security engineering team, that artifact trail is a feature: findings are auditable, reproducible, and reviewable by humans before any fix merges. For blue teams monitoring their own pipelines, the same trail makes the tool's use visible and attributable, which is exactly how a dual-use capability inside an enterprise should behave.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Nettacker for automated recon and vulnerability scanning


• bughunters as a reference corpus for Googles vulnerability reward programs


• Inside vedas-signatures: AI-generated detection rules for 13,000+ CVEs, released for community validation