VulnHunter tries to prove a vulnerability instead of flagging it
Agentic AI security scanner that hunts exploitable vulnerabilities like an adversary, proves them with executable PoCs, and fixes them test-first. A maintained fork of Capital One's VulnHunter, rebuilt for any agent harness.
At a glance
- What is it?
- VulnHunter is an agentic security scanner that argues its way to an exploit and then tries to run it, and this fork of Capital One's original moves the methodology out of Claude Code into any agent harness with a skills directory. The parts that are shipped are harness portability and a no-guess installer; the parts still in progress are containerised exploit validation and PoCs that report measured impact.
- Who is it for?
- Adopt VulnHunter if you want a security review that argues a finding to the point of an executable proof rather than a pattern match, and you run your agents in a harness other than Claude Code, since the fork's main contribution is that portability.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The claim is provability rather than pattern matching
VulnHunter is an open-source, agentic AI security tool that applies proactive, attacker-first analysis directly to source code.
The positioning against conventional scanning is stated in the first paragraph of the documentation. Unlike traditional, passive SAST scanners that flag suspicious patterns and often cause false positives, VulnHunter reasons like an adversary. It identifies which defects are actually exploitable, maps prospective attack paths, and proposes targeted, evidence-backed fixes.
That difference is a difference in what the tool is trying to produce. A pattern matcher produces a list of locations that look suspicious, and the human decides. An agent that reasons about attack paths produces a smaller list of defects with a claim about reachability, and then has to back the claim. The cost of the stronger claim is that it needs evidence, which is where the sandboxed validation comes in later.
The motivation given for the whole approach is supply chain exposure. Modern software supply chains are deeply interconnected, and a single vulnerability in a widely-used open-source component can ripple across thousands of enterprises simultaneously.
The tool was developed internally at Capital One and open-sourced for the community. This fork carries that work forward with the same methodology, reworked to run on any agent harness, with sandboxed, containerised exploit validation and measured-impact PoCs on the roadmap.
It is Apache-2.0 licensed, Python, the last push was on 2026-10-14, and there are no GitHub releases, so the installation route is the installer script in the repository rather than a release artefact.
Harness portability is the change the fork is actually about
The fork's stated focus is three things: harness portability, sandboxed containerised exploit validation, and measured-impact PoCs.
The comparison table sets out what upstream does against what the fork does, and the first row is the sharpest. Upstream, skills invoke Claude Code specifically, the installer targets `~/.claude/skills`, model gates hardcode Opus, and the harness pins `claude-opus-4-8`. In the fork, skills are harness-portable prompt files for any harness with a skills directory and subagents, and there is an environment contract:
VULNHUNT_SKILLS_DIR
VULNHUNT_AGENTS_DIR
VULNHUNT_BIN_DIR
VULNHUNT_HOST_CMD
VULNHUNT_MODELThe model gates are rephrased to ask for your harness's most capable reasoning model rather than a specific product.
The reasoning behind it is stated plainly. The methodology is host-agnostic by nature because it is prompt procedure, not tool binding. The upstream project grew up inside Claude Code, described as a coherent choice and the right first home, but the range of agent harnesses has broadened, and a security methodology that installs into only one of them stops being an audit capability and starts being a vendor feature.
That is the argument for the fork, and it is a good one. A methodology you can only run in one agent environment is tied to that vendor's pricing, model lineup and release cadence, which is a poor property for a security tool that an organisation wants to run consistently over years.
One practical detail follows from it: because the same methodology installs into whatever harness the team already runs, it becomes comparable across harnesses in benchmark runs, which is how the fork says it is developed.
The installer fails loudly instead of guessing
The second shipped change is about where files go, and it is a small thing that matters in practice.
The upstream installer copied skills into `~/.claude/skills` unconditionally. The reasoning given is that on a machine running two harnesses, or a harness with a relocated home, that guess installs into the wrong place, silently. The fork's installer asks, or takes environment variables, and fails loudly with the exact instruction when the answer is missing.
The outcome is described as safe on multi-harness machines, correct under relocated homes, and loud instead of silent when misconfigured. The installer also honours `GROK_HOME` semantics, writes the `vh` launcher to `VULNHUNT_BIN_DIR` or `~/.local/bin`, and installs the `vulnhunter-run` skill along with the agent definition. Windows `.cmd` equivalents were updated alongside the shell script, and the repository ships matching `uninstall.sh` and `uninstall.cmd` files.
That is the shape of the whole fork, honestly. There is no new scanning algorithm here. The changes are about making the same procedure runnable in more places, and about making a misconfiguration visible instead of quiet.
The operator side gets the same treatment. A new `vulnhunter-run` operator is an unattended operator that clones, hunts, locates results, and writes and validates the scan manifest, with explicit stop rules and no improvisation. The reasoning is that a remediation loop compounds when it runs nightly, which is a claim about scheduled use rather than interactive review.
Execution depth is the open problem, and it has a number attached
The third change is the one still in progress, and it is the most interesting because the documentation attaches a number to the problem.
The original design already demands falsification and exploit tests. What it left open was how hard to work to actually execute them: a static trace, a mocked test, or a real containerised server. The fork reports that in one six-run benchmark against a single commit, that discretion produced anywhere from 3 to 42 findings, and opposite verdicts on the same sink, one proven against a mock and one closed by a test against a real server.
A six-run spread of 3 to 42 findings on a single commit is the kind of number that makes the point better than an argument would. The variance is not noise in the model, it is the model choosing different depths of proof, and the verdicts on the same sink going opposite ways means the outcome depended on that choice rather than on the code.
The fork's answer is a runtime-provisioning procedure, Docker-first, with the runtime recorded per finding, and a PoC discipline where impact is measured, as rows leaked, times amplification, and key-hours stranded, rather than narrated. The table marks both of these as in progress, and the build plan is said to be on the public roadmap, with the note that you can ask in issues or watch the repository's Discussions.
The status distinction matters for an adopter. The shipped items are portability, the installer, the operator skill, benchmark and judge hardening, and harness-neutral report language, where Claude-specific prose is replaced with harness-neutral tool language, Agent becoming subagent and Claude CLI becoming harness session. The sandbox and measured-impact items are the ones to wait for.
The dual-use warning and the model requirement are both explicit
Two of the documentation's callouts are worth reading in full, because they set the conditions under which the tool is meant to be used.
The first is a dual-use caution. VulnHunter performs dual-use cybersecurity work, vulnerability discovery and exploitation. The documentation says to expect guardrails, because most commercially available models apply dual-use cyber safeguards, and aggressive exploitation behaviour can trip rate limits or usage flags.
That is a practical warning rather than a legal one. If the agent tries hard to prove an exploit against a live target, a hosted model provider may refuse the request or flag the account. The tool's usefulness therefore depends on which model you point it at.
Which is exactly the second callout, on prerequisites and model requirements. The methodology is built to run on open-weight, community-provided models, the de-risked, abliterated, uncensored ones organisations can actually deploy. A capable reasoning model is required, and the strongest model your harness offers gives the best results, but the methodology does not depend on a specific vendor's frontier model. You supply your own model access.
The development and testing ran on models of that kind, and the documentation frames them as the models likely to matter for organizational use going forward.
The scope limit is stated alongside: audit only code you own or are otherwise authorized to audit. The tool is a scanner for your own codebase and for systems you have permission to test, and the sandboxed validation path in particular should be pointed at something you are allowed to break.
The repository layout shows a prompt-first project, not a Python package
The top-level entries describe what the project actually is, and the surprise for anyone expecting a scanner package is that most of the tree is prompts, agents and documentation rather than Python source.
There are skills/, agents/, harness/ and product_docs/ directories, plus a vh/ directory and several top-level Python packages: vulnhunt/, vulnhunter/, vulnhunter-agent/, vulnhunter-run/, vulnhunter-fix/, vulnhunter-fix-verify/ and vulnhunter_common/.
The naming tells you the pipeline. vulnhunter is the analysis, vulnhunter-agent is the agent definition, vulnhunter-run is the unattended operator, vulnhunter-fix is the remediation side, and vulnhunter-fix-verify is the verification of a fix, which is the test-first part of the description. vulnhunt and vulnhunter_common hold the shared code.
The harness/ directory is the fork's central addition in practical terms, since it is where the portability lives.
The project configuration files are worth noting too. There is a mypy.ini and a ruff.toml, so the Python parts are typed and linted, and there is a CODEOWNERS file, a CONTRIBUTING.md, a SECURITY.md and a NOTICE file. The .oss-sync.json is a marker of how the fork tracks the upstream, and the LICENSE is Apache-2.0.
The install.sh and install.cmd pair is the entry point, with uninstall.sh and uninstall.cmd to reverse it, and the skills, agents, harness and vh directories are what the installer wires together. This is a project where the interesting engineering is in how the model is instructed, and the directory names are the best guide to how the pieces fit.
Editorial conclusion
Adopt VulnHunter if you want a security review that argues a finding to the point of an executable proof rather than a pattern match, and you run your agents in a harness other than Claude Code, since the fork's main contribution is that portability. Skip it if you need a static analyser with predictable output and no model in the loop, or if you are evaluating the fork's headline features, because sandboxed exploit validation and measured-impact PoCs are listed as in progress. Verify first that you can supply a capable reasoning model, that your harness has a skills directory and subagents, and that you have a container runtime available for the validation path you intend to rely on.
Frequently asked questions
What is VulnHunter and how does it differ from ordinary SAST?
It is an agentic AI security tool that applies attacker-first analysis to source code. Unlike passive SAST scanners that flag suspicious patterns and often cause false positives, it identifies which defects are actually exploitable, maps prospective attack paths and proposes evidence-backed fixes.
What does this fork of VulnHunter change?
The shipped changes are harness portability, where skills become portable prompt files with an environment contract of VULNHUNT_SKILLS_DIR, VULNHUNT_AGENTS_DIR, VULNHUNT_BIN_DIR, VULNHUNT_HOST_CMD and VULNHUNT_MODEL, a no-guess installer that fails loudly, the vulnhunter-run unattended operator, benchmark and judge hardening, and harness-neutral report language. Sandbox-first exploit validation and measured-impact PoCs are still in progress.
What model access does VulnHunter need?
A capable reasoning model is required, and the strongest model your harness offers gives the best results, but the methodology does not depend on a specific vendor's frontier model. The documentation says you supply your own model access, and that development and testing ran on open-weight, community-provided models.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/nealbridges-vulnhunter)Was this useful?