VulHunt Community Edition: a rule-driven scanner for binaries and firmware

The problem: a firmware image is a haystack, and the rules are the needle

Vulnerability hunting on a binary is not the same activity as reading source code. You have an image, a blob of machine code with no symbols, and a catalogue of known-bad patterns, and you want to know which of the catalogue appear in the blob. That is a pattern matching problem over an intermediate representation, and the hard parts are the lifting of code into something matchable and the definition of the patterns themselves.

VulHunt is a vulnerability hunting framework developed by Binarly's research team, and the project description says it is designed to help security researchers and practitioners identify vulnerabilities in software binaries and UEFI firmware. The topics are binary analysis, reverse engineering and vulnerability research, and the primary language is C++.

The audience is therefore security researchers rather than developers looking for a dependency scanner, and the distinction is worth keeping in view. This is a framework for people who write rules about vulnerable code patterns and apply them to code they cannot read.

The project is published as VulHunt Community Edition, which is described as a free and open-source version of the VulHunt engine within the Binarly Transparency Platform, designed to facilitate community-developed rulepacks and integrations. That sentence defines both the value and the boundary. The engine is open, so a community can write and share rules, and the platform, which is where large scale management, hunting and triage live, is not.

The licence is GPL-3.0, with the copyright held by Binarly Inc. and the VulHunt developers, and the homepage is vulhunt.re. The last push was on 2026-08-25, and there is a single release, v1.0.0 from 2026-03-07.

The layers under the command line

The workspace layout in the Cargo manifest describes the architecture more clearly than any prose could, because the crate names are annotated with what each one is for.

The command line itself is bias-vulhunt. The analysis framework is bias-core, with bias-core-derive beside it for the derive macros, and bias is the analysis orchestration and reporting layer above them. The VulHunt components are bias-vulhunt-engine and bias-vulhunt-mcp, the engine and the Model Context Protocol server. The lifter and type database utilities are bias-lutil and bias-tutil. The Binary Ninja loader is bias-loader-bndb, and the Binarly Transparency Platform client is bias-btp.

Then there are three compatibility layers, bias-compat-fwhunt, bias-compat-patfind and bias-compat-flirt. These are adapters, and their names tell you what they adapt: FLIRT is a signature format for matching library code in binaries, and fwhunt and patfind are the names of other tools whose analysis formats are being read.

The build profiles are also deliberate. The release profile uses thin link time optimisation, the production profile inherits it and turns on fat LTO with a single codegen unit, and there is a triage profile that inherits the dev profile but sets opt-level to 3. That third one is a nice touch for a security tool, where you often want a fast build with real optimisation while you are chasing a specific finding, and a slow optimised build for the release artefact.

The top-level entries add a Dockerfile, a Dockerfile.release, a Makefile.toml, patches, scripts and assets, plus a README.BIAS.md and a LICENSE.BIAS alongside the main licence, which is how a project that embeds a differently licensed upstream core documents that.

Scanning: loaders, rules, auxiliary data and three output shapes

The scanner has a stable shape, and the options describe the whole design.

The command is:

vulhunt-ce scan <INPUT> -o <OUTPUT> -d <BIAS_DATA> -r <RULES> [OPTIONS]

The input can be a binary, a BA2 archive or a BNDB file, and the loader option decides which: component for single binary files, ba2 for Binarly Archive 2 archives containing multiple components, and bndb for Binary Ninja databases, which requires the bndb feature at build time.

The two mandatory directories are the interesting part. The data directory holds auxiliary data such as processor specifications, and can also be set through the BIAS_DATA environment variable. The rules directory holds the VulHunt rules, and can be set through BIAS_VULHUNT_RULES. A third, optional, directory holds VulHunt modules and can be set through BIAS_VULHUNT_MODULES.

The output shape has three modes. The default is a JSON file. The --pretty flag formats the output for human consumption and renders issues to stdout, and the --stream flag formats the output as a stream of JSONL messages, which --compress then compresses with Zstandard. That is a sensible progression for a tool that is used both by a person reading a terminal and by a pipeline consuming results.

The examples show the same command in each of the three modes of input:

vulhunt-ce scan lib.so -o results.json -d /path/to/bias-data -r /path/to/rules --pretty

A scanner with a rules directory is a scanner whose intelligence is external, and that is the design point to hold on to. A scan with no rules and no auxiliary data is a valid command that will find nothing, and the community edition exists to make the rules grow.

The MCP server: letting an assistant drive the scanner

VulHunt can run as an MCP server for integration with AI assistants, and by default it starts a streaming HTTP server with SSE transport at http://127.0.0.1:8080:

vulhunt-ce mcp -d <BIAS_DATA> [OPTIONS]

The data directory is required here, and it can again come from the BIAS_DATA environment variable, while the optional modules directory can come from BIAS_VULHUNT_MODULES. The transport can be switched with --stdio, the bind address with --host and the port with --port, both of which default to 127.0.0.1 and 8080.

The default bind address is the right default for a tool that reads binaries and rules from your disk and can return findings, because it means the server is not reachable from the network unless you deliberately change it.

The design point here is worth making explicit. An assistant that can call the scanner can search a large binary corpus on your behalf, and the scanner returns structured findings rather than prose. That is a better fit for an agent than a general purpose shell, because the tool call has a defined shape, the output is JSON, and the rules that decide what counts as a finding are the same ones a human analyst would use.

There are also archive utilities in the same binary, which matter for firmware work. Listing the components in a BA2 archive is:

vulhunt-ce ba2 list-components <INPUT>

and extracting one is:

vulhunt-ce ba2 extract-component <INPUT> -o <OUTPUT> --component-id <UUID>

A firmware image is often a bundle of many components, and the ability to pull one out and scan it separately is the kind of operation that turns a monolith into a list of triageable pieces.

The build: cargo-make, a patched LuaJIT and static linking

The build is the part of this project that will cost you an afternoon, and the documentation is honest about it.

The supported path uses cargo-make, which you install with cargo install cargo-make, and then you build with cargo make --profile <development|release> build, install with cargo make --profile <development|release> install, and add --features=bndb for Binary Ninja support. Packaging is cargo make prepare-package --features=...

The manual path starts with git submodule update --init, and then it needs a LuaJIT with a specific patch applied. You clone LuaJIT at the v2.1 branch, change into the directory, and apply the patch with git apply, pointing at a path inside the checkout of this project. On macOS you also export MACOSX_DEPLOYMENT_TARGET, on macOS and Linux you build with make BUILDMODE='static' and export LUA_LIB, LUA_LIB_NAME and LUA_LINK, and on Windows you run msvcbuild.bat from the src directory with the same three variables set to their Windows equivalents.

The requirement for a patched LuaJIT is the part to understand rather than just obey. The engine is built on a Lua runtime that has been modified, so an unpatched LuaJIT will not build or will not behave correctly, and there is no package manager route that gives you the patched version. The Windows path even sets LUA_LIB_NAME to lua51 rather than luajit, which is a small detail that hints at how deep the modifications go.

The container route avoids the host toolchain entirely. The Dockerfile builds on a Chainguard glibc-dynamic image, installs the Rust and native build dependencies, runs cargo make --profile=release prepare-bundle, and then produces a runtime image that runs as a nonroot user with only the vulhunt-ce, bias-lutil, bias-tutil and sleighc binaries and a lib directory on the path. The presence of sleighc is a detail worth noticing, since that is the SLEIGH specification compiler, and a framework that ships a spec compiler is a framework that compiles specifications at runtime.

The platform half, the licence and the honest limits

The Binarly Transparency Platform integration is the commercial side, and it is available in the community edition as a client.

The commands are the usual product and scan management: push-rules to send rules to a repository, list-products, create-product, upload of a file with an optional scan, list-images, list-scans, create-scan, get-scan, get-findings and download-ba2. Every command requires authentication, which is passed as a username and password or through the BTP_USERNAME and BTP_PASSWORD environment variables, plus an instance slug such as your-org.prod through BTP_INSTANCE_SLUG or the -s option. The push-rules command takes a platform of posix or uefi, a tag, a name and a modules directory, and can deploy to a product or an organisation by ULID.

The licence is the GNU General Public License v3.0, and for a security tool that is the right choice, because a rulepack that someone else writes should stay available. The single release, v1.0.0 from 2026-03-07, and the last push on 2026-08-25, together say that this is a young project with a published first version and a recent commit behind it.

The limits are clear enough to state. The community edition is the engine, not the platform, so large scale management, hunting and triage are the commercial part, and the practical difference between the two is where the findings live and who else can see them. The build is heavy: a patched LuaJIT, a Rust toolchain, and either cargo-make or a careful sequence of environment variables, with the container image as the smooth path. And the results are only as good as the rules directory you point it at, which is exactly why the project exists in this form.

For a researcher the judgement is favourable. The engine, the loaders, the output formats and the MCP server are open, the rules are where the community contributes, and the licensing keeps a shared rulepack shareable.

Editorial conclusion

Adopt VulHunt Community Edition if you are doing binary or firmware security research and you want Binarly's analysis engine and rule format without the commercial platform. Do not adopt it if you expect a turnkey vulnerability scanner, because a scan with no rules and no auxiliary data finds nothing, and the rulepacks are what the community edition exists to grow. Before you build, check the LuaJIT patch requirement, because the build will not work without it, and decide whether you need the Binary Ninja loader, which is behind a compile time feature flag rather than a runtime switch.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. vulhunt-re/vulhunt on GitHub