Build Your Own Cache of Cyberweapons with Stockpiler
Stockpiler continuously collects public CVE proof-of-concept exploits from GitHub and exposes the resulting archive to both security researchers and AI agents.
There are a lot of public vulnerability Proof-of-Concepts floating around GitHub.
Finding what you need during an engagement is another story.
Stockpiler is a tool from Kaiju Security designed to build and maintain a local cache of public Proof-of-Concept exploits.
Rather than searching online every time you need an exploit for a particular CVE, Stockpiler maintains a local collection of exploits that you can search through to find what you need rapidly.
Even better, Stockpiler includes a read-only MCP server, allowing AI agents to search the collection and pull PoC source code directly into their context (Shout out to awgh for the PR!)
Public PoC exploit repositories should always be treated as untrusted code. Stockpiler downloads repositories; it does not determine whether the code inside them is safe.
How Stockpiler Works
Stockpiler uses Nomi-sec’s PoC-in-GitHub project as its upstream index.
PoC-in-GitHub continuously tracks public GitHub repositories associated with CVEs. Stockpiler takes that index and turns it into a locally maintained collection.
At a high level:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
PoC-in-GitHub
|
v
Stockpiler
|
+----> Local CVE/PoC Repository
|
+----> Local Search
|
+----> Collection Statistics
|
+----> MCP Server
|
v
AI Agents
The collector is intentionally simple.
Running:
1
./stockpiler.sh update
synchronizes the PoC-in-GitHub index and clones any repositories that aren’t already present locally.
The operation is idempotent, so running the update repeatedly doesn’t mean recloning your entire collection.
That makes Stockpiler suitable for running periodically as a scheduled task.
Installing Stockpiler
Clone the repository:
1
2
git clone https://github.com/KaijuSecurity/Stockpiler.git
cd Stockpiler
Choose where you want the collection stored:
1
export STOCKPILER_ROOT=/var/lib/stockpiler/data
Then start collecting:
1
./stockpiler.sh update
The full installation walkthrough is available in:
1
docs/INSTALL.md
Searching the Stockpile
Once you’ve collected the repositories, the archive can be searched locally.
For example:
1
./stockpiler.sh search CVE-2024
Or search for a particular CVE:
1
./stockpiler.sh search CVE-2024-XXXX
The search command queries the locally generated repos.txt index.
This means you don’t need to hit GitHub every time you’re trying to determine whether you’ve already collected a PoC.
Collection Statistics
Stockpiler can also report statistics about the archive:
1
./stockpiler.sh stat
This provides information about the collection and its disk usage.
And you’re going to want to keep an eye on that second number.
Stockpiler gets big.
At the time of writing, the collection is already over 312 GB and continues to grow.
We recommend allocating at least 1 TB of storage if you intend to maintain the complete archive.
If you’re building a dedicated Stockpiler host, giving it its own large volume isn’t a bad idea.
Keeping It Updated
PoC-in-GitHub changes frequently, so Stockpiler is intended to be updated periodically.
A simple cron job can take care of it:
0 */6 * * * STOCKPILER_ROOT=/var/lib/stockpiler/data /opt/Stockpiler/stockpiler.sh update
This checks for updates every six hours.
Because update only clones repositories that aren’t already present, subsequent runs are significantly different from rebuilding the collection from scratch.
Running updates frequently also means that you will capture exploits that eventually get removed from GitHub. ;)
MCP Support
This is where Stockpiler gets particularly interesting.
In addition to the Bash collector, Stockpiler includes a read-only Model Context Protocol (MCP) server.
The server allows remote MCP clients to interact with the PoC archive without giving them arbitrary filesystem access.
The MCP server currently exposes four tools:
1
2
3
4
search_cves
list_pocs
get_poc_context
read_poc_file
These allow an agent to:
- Search for CVEs.
- Enumerate available PoCs.
- Retrieve repository context.
- Read individual files from a PoC repository.
That turns Stockpiler from a simple archive into something closer to a local vulnerability research knowledge base.
Running the MCP Server
On the machine hosting the Stockpiler collection:
1
2
sudo ./scripts/install-mcp-server.sh \
--root /var/lib/stockpiler/data
The default development endpoint is:
1
http://<host>:1337/mcp
For example:
1
http://stockpiler.example:1337/mcp
The default development configuration uses HTTP with no authentication. Don’t expose it to untrusted networks.
For production deployments, Stockpiler supports TLS and API keys through:
1
/etc/stockpiler-mcp.env
Connecting an MCP Client
Stockpiler includes an installer for configuring a client machine:
1
2
./scripts/install-mcp-client.sh \
--url http://stockpiler.example:1337/mcp
Once connected, an MCP-capable agent can query the collection directly.
Instead of:
1
Search the Internet for a PoC for CVE-XXXX-YYYY.
the workflow becomes:
1
Search my Stockpiler archive for CVE-XXXX-YYYY.
If several PoCs exist, the agent can enumerate them, inspect their repositories, and read the relevant source files.
The entire workflow can happen within infrastructure you control.
Why MCP Matters
LLMs can be extremely useful when reading unfamiliar exploit code.
The problem is getting the right code into context.
Without something like Stockpiler, an agent may need to rely on web searches, manually supplied repositories, or whatever exploit information happens to exist in its existing context.
Stockpiler changes that relationship.
1
2
3
4
5
6
7
8
9
10
11
12
13
Researcher
|
v
AI Agent
|
| MCP
v
+-------------+
| Stockpiler |
+-------------+
|
v
CVE PoC Archive
The model doesn’t need unrestricted shell access to your exploit archive.
Instead, it receives a small set of read-only operations specifically designed for vulnerability research.
For example, an agent could:
- Search Stockpiler for a CVE.
- Determine how many public PoCs have been collected.
- Inspect the repository context for promising candidates.
- Read the source code.
- Explain how the PoC works.
- Identify prerequisites or dependencies.
- Help a researcher determine whether the technique is relevant to an engagement.
- Etc…
This keeps the actual archive local while making the information much easier to work with.
Treat the Archive as Hostile
There is an important security consideration when maintaining an archive like this:
You are downloading exploit code from strangers on the Internet.
PoC-in-GitHub itself warns that indexed repositories may include fake exploits, scams, or malware targeting security researchers / target systems.
Stockpiler does not magically make those repositories trustworthy.
Never blindly execute code from the Stockpiler archive.
Read the source first. Treat every repository as potentially malicious until you’ve reviewed it.
This is particularly important for repositories that instruct you to:
1
2
3
4
pip install ...
npm install ...
make
./install.sh
or otherwise execute code as part of their setup process.
If you’re going to test unknown PoCs, isolation is your friend.
Storage Architecture
For a dedicated collector, a simple architecture might look like:
1
2
3
4
5
6
7
8
9
10
11
12
/opt/Stockpiler/
|
+-- stockpiler.sh
+-- scripts/
+-- mcp/
+-- docs/
/var/lib/stockpiler/data/
|
+-- PoC-in-GitHub/
+-- CVE-*/
+-- repos.txt
Keeping the application and data separate makes it easier to place the archive on a dedicated filesystem or large storage volume.
For example:
1
export STOCKPILER_ROOT=/mnt/poc-storage/stockpiler
The collector doesn’t care where the data lives as long as STOCKPILER_ROOT points to it.
Dependencies
The collector has deliberately minimal dependencies:
1
2
3
4
jq
wc
du
git
The MCP server additionally requires:
1
Python 3.11+
along with the Python packages specified in:
1
mcp/requirements.txt
The MCP installation script handles the server-side setup.
The Goal
Stockpiler isn’t intended to replace vulnerability databases or exploit research.
It’s meant to solve a simpler problem:
Keep public PoC exploits you might need close at hand.
For penetration testers, red teamers, exploit developers, and vulnerability researchers, having a continuously updated local collection provides a useful starting point when investigating a CVE.
Adding MCP on top makes that same collection accessible to the next generation of security research workflows.
Humans can search it.
Agents can search it.
And the data stays under your control.
Get Stockpiler
Stockpiler is available on GitHub:
1
git clone https://github.com/KaijuSecurity/Stockpiler.git
Credit goes to Nomi-sec for the excellent PoC-in-GitHub project that provides the underlying CVE PoC index.
Stockpiler was created by M4x 5yn74x.
Stockpiler is intended for educational purposes and legitimate cybersecurity testing. Don’t expose the collection publicly, and don’t redistribute it as a public exploit mirror.
Research & Destroy