VulnHunter: How to Run Capital One’s Vulnerability Hunter on Your Own Repo
By Devy · Category: Cybersecurity for devs + AI coding tools · With strategic note from Grego
There’s a huge difference between a scanner that throws 300 alerts at you and wishes you luck, and an agent that starts where the attacker comes in, reasons forward to the dangerous code, and before showing you anything tries to prove itself wrong. VulnHunter—the tool Capital One was using internally across thousands of repos and just released as open source—is the latter. And the best part: it’s not a closed product or a SaaS with a sales demo. It’s three Claude Code skills that you install on your machine and point at your own repository.
In this article we’ll install it, run it on a real repo, and close the complete loop hunt → fix → verify. And as always, I’ll tell you straight up what you actually need for it to work, because there’s a requirement that the headlines aren’t mentioning.
What is VulnHunter, in a nutshell
VulnHunter is an agentic, open source (Apache 2.0) security tool published by Capital One on July 18, 2026 under the tag v0.1.0 “Initial Launch”. Its official GitHub description sums it up like this: “Agentic AI security tool that applies proactive, attacker-first analysis directly to source code.”
Three ideas set it apart from classical SAST:
Attacker-first, forward-reasoning analysis. A traditional scanner is “sink-first”: it hunts for suspicious patterns in code (an eval, a concatenated query) and tries to reason backward if they’re reachable. VulnHunter flips the flow: it starts at the entry points that the attacker actually touches—APIs, file uploads, network messages—and reasons forward through the application logic, like a penetration tester would. It finds the path, not the pattern.
Falsification engine. This is the detail I love most. Before showing you a finding, VulnHunter tries to refute its own argument: it hunts for unfounded assumptions, logical leaps, and conditions that would block the attack. Only what survives that internal scrutiny reaches your eyes. It’s an explicit mechanism against security tools’ number one plague: the false positive that wastes your morning.
Remediation with evidence. It doesn’t just say “something weird here”. It maps the complete exploitation path, explains what capability the attacker needs, and generates concrete code changes for you to review.
Capital One says it validated it internally across thousands of repositories spanning dozens of business areas before open-sourcing it. This isn’t a lab experiment: it’s the tool that was already running in production at a bank.
The requirement nobody’s saying out loud
Before you open the terminal with enthusiasm: VulnHunter isn’t a standalone binary or self-hosted in the strict sense. It’s built as three Claude Code skills and requires access to the Claude Opus model to run. Specifically, the requirements are:
- Claude Code CLI, authenticated with access to Claude Opus.
- Python 3.12+ (only for the runtime agent and the benchmarking harness).
- Authorization to analyze the target codebase (obvious, but it’s in the docs).
- For the fix part: Git and the GitHub CLI authenticated, because the fixer opens pull requests.
So: the “installable and free” thing has an asterisk. VulnHunter’s code is Apache 2.0 and you don’t pay a license for it, but the engine that makes it think is Claude Opus, and that’s on you. If you’re already working with Claude Code, nothing changes in your setup. If not, that’s the real cost of entry, and I’d rather you know that upfront before investing ten minutes instead of after investing two hours.
Installation in 10 minutes (assuming you already have Claude Code)
1. Clone the repo.
git clone https://github.com/capitalone/vulnhunter.git
cd vulnhunter
2. Run the installer.
./install.sh
The script copies the skills to ~/.claude/skills/ (uses direct file copying instead of symlinks on purpose, so they keep working inside subagents). When it finishes you’ll have three skills available:
/vulnhunt— the hunt phase: identifies exploitable vulnerabilities./vulnhunter-fix— the remediation phase: writes tests, implements the fix, and opens a PR./vulnhunt-fix-verify— an independent verification agent that validates the fix actually worked, without trusting the previous findings.
3. Verify they were installed.
ls ~/.claude/skills/ | grep vulnhunt
If you see the skill folders, you’re good to go.
Running the hunt on your repo
Go to the root of the project you want to analyze and open a Claude Code session with Opus, giving it access to the skill folders:
cd /path/to/your/project
claude --model opus \
--add-dir ~/.claude/skills/vulnhunt \
--add-dir ~/.claude/skills/vulnhunt/phases
Inside the session, invoke the hunt:
/vulnhunt
VulnHunter will map your application’s entry points, reason forward to the dangerous sinks, and—crucially—pass each candidate through the falsification engine before reporting it. What you get isn’t a list of suspicions: it’s a set of findings that already survived an attempt at refutation, each one with its exploitation path explained.
Closing the loop: fix and verify
Here’s the part that turns VulnHunter into something more than a nice report. With a confirmed finding, you move to remediation:
/vulnhunter-fix
This skill first writes a test that reproduces the issue, implements the fix, and opens a pull request (that’s why you need Git and the GitHub CLI). It doesn’t leave the fix hanging: it leaves it ready for review with evidence that it attacks the real problem.
And the honest closure of the cycle:
/vulnhunt-fix-verify
An independent agent validates that the fix actually closed the vulnerability. The key word is “independent”: it doesn’t reuse the reasoning from the hunt phase and doesn’t assume the fixer did their job right. It verifies from scratch. It’s the same falsification engine philosophy applied to the end of the loop: don’t trust your own agent, make it prove it’s right.
The result is a complete cycle—hunt → fix → verify—that you can run on your repo without writing a single line of glue code.
A concrete use case: AI-generated code
If your team is shipping AI-assisted code at 2026 speed, this is your scenario. Generated code tends to be syntactically flawless and semantically confident, which is exactly the combination where broken authorization, input validation that was assumed and never written, and path traversal in the upload that “surely the framework handles it” sneak in. An attacker-first analysis that starts at the entry point is precisely what catches that class of bug, because it doesn’t care how polished the code looks: it cares whether there’s a path from the outside to something dangerous.
Strategic note from Grego: why a bank publishes offensive capability
It’s worth pausing on the weird part of this story. Capital One is a bank. Banks aren’t famous for handing over their defenses. That one releases—under Apache 2.0, friction-free—a tool that reasons like an attacker on source code is a move worth reading carefully.
Capital One’s argument is that modern software security is a communal problem, not a proprietary one. Supply chains are so entangled that a vulnerability in one dependency cascades across thousands of companies at once. In that world, keeping your best defense under lock and key doesn’t make you safer: it leaves you standing on the same fragile ecosystem as everyone else. Opening it invites the global security community to strengthen the common ground—and, as a bonus, to improve the tool for the bank itself via contributions. It’s open source as a collective defense strategy, not as a gesture of generosity.For us in Ibero-America, there’s an even more practical reading. Most teams in the region don’t have a dedicated AppSec engineer, and hiring recurring penetration testing is out of budget for nearly everyone. An offensive reasoning tool, matured inside a bank across thousands of repos, available for free and running on AI infrastructure that many teams already pay for—Claude Code with Opus—lowers a barrier that historically separated those who could afford serious security from those who couldn’t. The cost is no longer a six-figure contract: it’s the model you probably already have in your stack.
The honest flip side: that Opus dependency also means VulnHunter isn’t “free” in the way a linter is. It runs on a premium model, and a hunt across a large repo consumes real tokens. My recommendation is to treat it for what it is—a deep security audit, not a check on every commit—and run it at the moments that matter: before a release, on code newly generated by AI, on the service that exposes your public API. Used with judgment, it’s one of the most useful things a bank has given the dev community in a long time.
The takeaway
VulnHunter isn’t just another scanner: it’s an agent that hunts like an attacker, doubts itself before talking to you, and closes the loop all the way to verified fixes. If you already live in Claude Code, putting it to work on your repo is a matter of ten minutes and three commands. If not yet, the Opus requirement is the toll you need to evaluate. Either way, that a bank opened up this capability says something about where software security is headed: toward the agentic, toward the communal, and toward the side of the defender finally having to think like the attacker.
Sources: