EIP v3: The Exploit Database We Meant to Build

What happened to EIP v2, you ask?

We'll never tell.

Let's just say it eventually found its calling as a very expensive requirements document.

EIP v3 is what happened when we finally read it.

This is not a cosmetic release, a database migration with a new logo, or three microservices standing on each other's shoulders in a trenchcoat. We rebuilt the Exploit Intelligence Platform around one useful idea: you should be able to move from a vulnerability record to the actual exploit artifacts, search their source, and hand the same evidence to an AI assistant without confusing any of it for a verdict.

Most importantly, the name is finally literal.

EIP is an exploit database where you can search the code.

Give Your Agent the Exploit Database

The MCP server is not a footnote or a thin wrapper around a CVE lookup. It gives an AI assistant bounded, source-attributed access to the useful parts of EIP: CVEs and GHSAs, exploit artifacts, readable PoC source, Docker labs, vendors, packages, official CWEs, contributors, statistics, and STIX.

The hosted endpoint is:

https://exploit-intel.com/mcp

There is no EIP account, API key, or local package required. In an MCP-capable application, add that URL as a remote Streamable HTTP server named EIP, then ask the agent to call get_corpus_readiness to verify the connection.

From there, you can ask questions like:

• "What exploit material and Docker labs are linked to this CVE?"
• "Search readable PoC source for subprocess.run( and show me the nearby code."
• "Find command-injection vulnerabilities with public exploit artifacts, then keep the source claims separate from model analysis."
• "Give me the STIX bundle for this vulnerability."

The assistant can search broadly, inspect one artifact, and open one bounded, API-verified UTF-8 source file at a time. It also gets focused prompts for CVE triage, technique hunting, exploit-safety review, and corpus reporting. Every tool returns a concise Markdown brief and a structured result so the agent does not have to reverse-engineer its own prose.

What it cannot do is just as important. There is no corpus download tool. It does not execute acquired code. PoC access tokens never enter results or retained MCP state. Returned source and repository prose remain untrusted data, not surprise instructions from a stranger's README.

We wanted agents to use exploit intelligence, not turn an MCP connection into curl | sudo bash with better prose.

If your client requires a local stdio command, pipx install eip-mcp remains available. The hosted service is the recommended path. The current connection instructions are on the EIP Tools page.

The Exploits Are the Database

Traditional vulnerability databases are good at answering questions about a record: identifier, severity, affected versions, references, maybe an EPSS score if everyone is feeling adventurous.

Exploit databases usually add a title and a download link. Sometimes the link still works. Sometimes the code still runs. Sometimes the "proof of concept" is a credential stealer wearing a fake moustache.

EIP v3 treats exploit material as first-class data. ExploitDB entries, Metasploit modules, public repository PoCs, unassigned but eligible files from curated repositories, and deterministic Docker lab units enter a retained corpus with source identity, revision identity, hashes, paths, associations, and provenance.

Then we index the readable source.

From the WebUI, the CLI, or an agent, you can search for the thing the code actually does:

eip-search code 'subprocess.run(' --limit 10
eip-search code 'jndi ldap' --vulnerability CVE-2021-44228
eip-search code 'requests.post' --source repository-inventory

Search can be corpus-wide, source-scoped, limited to a vulnerability, or bound to one public exploit identity. Results identify the matching artifact and path, show bounded nearby context, distinguish path matches from content matches, and carry linked vulnerability identifiers without inventing relationships.

Before EIP returns a snippet, it checks that the code index belongs to the current database projection and reads the excerpt from the expected SHA-256-verified corpus bytes. The result is private, non-cacheable, and non-indexable. The code is available for inspection, not donated to every crawler with a User-Agent and a dream.

This needs one loud caveat: searchable does not mean verified. An indexed PoC is not automatically working, reliable, effective, safe, or even particularly good. Text relevance is not exploit quality. Model interpretation is not source authority. EIP v3 keeps those meanings separate because security tools become dangerous when their confidence exceeds their evidence.

Humans Still Get Tools

The public WebUI is the quickest way to explore the corpus. eip-search brings vulnerability, exploit, code, lab, discovery, statistics, and STIX queries to a terminal, with JSON output for scripts. It is deliberately read-only and does not decide that an exploit is trustworthy because its README contains several shields.io badges.

The API also serves deterministic STIX 2.1 graphs and read-only TAXII 2.1 collections. The WebUI, CLI, MCP, STIX, and TAXII surfaces share the same current data and semantics; the clients simply choose the presentation.

The Boring Part Is Why the Interesting Part Works

EIP v1 grew the way many useful security projects grow: one source, then another, then a cron job, then a second database, then a comment saying "temporary" that survived several birthdays.

V3 replaces that growth ring with explicit boundaries. Source evidence is durable; the application database is rebuildable; model enrichment is optional and attributed; the public clients all read the same projection. A model can fail at 03:17 without changing whether an exploit is retained or taking search down with it.

The important rule is simple: source facts, EIP decisions, and model interpretations are different things. Missing analysis never means "reviewed and safe," and a confident model answer never quietly becomes source authority. We have acquired a surprising fondness for boring invariants.

The Forge Tools Grew Up

Readers of this blog will remember CVEForge, StackForge, FuzzForge, and the old Hermes setup. They were experiments, but productive ones. They proved that an agent could research a vulnerability, read the patch, build a lab, produce a PoC, test the vulnerable and fixed paths, and sometimes discover that a vendor's fix had addressed the symptom with great confidence.

They also taught us what a demonstration does not need but a reliable service does: durable state, resumable handoffs, independent review, publication gates, and a UI that answers more questions than "is the terminal still scrolling?"

The new eip-cve-* system replaces those separate Forge and Hermes workflows. It scouts candidates, routes one accepted target through research and PoC/lab work, sends the result down an independent QA track, and stages a publication pull request. The scout cannot promote its own ideas, the research agent cannot merge its own work, and the pipeline never pushes directly to main.

That is still automation. It is automation with brakes, receipts, and someone occasionally asking why a Joomla extension requires quite so much PHP.

Kimi and Ollama Did the Work

We should talk plainly about the models, because they are not a footnote to this story.

Kimi is the agent runtime driving the research sessions. Ollama is a major part of the model layer. We can select different models for scouting, full research runs, independent QA, and package verification instead of pretending one model is equally good at every kind of work.

That flexibility became important because the best model for finding candidates is not necessarily the best model for spending hours inside a compiler, a Docker build, and a vendor patch.

And, yes: open-model ecosystems and Chinese-built models are doing serious security work here.

In our own long, tool-heavy runs, models reached through Kimi and Ollama have completed research and lab tasks where more famous flagship systems sometimes stalled, lost the thread, or returned exceptionally polished explanations of work they had not actually done. This is not a universal leaderboard, and we are not asking the scheduler to issue passports. We give models tasks, tools, limits, and exit contracts. Then we inspect the artifacts.

The interesting result is not that one logo beat another logo. It is that capable security automation is no longer confined to one closed model vendor. Open tooling, interchangeable providers, Chinese model families, and explicit verification can now produce useful, repeatable work in a domain where a confident hallucination is more than an aesthetic defect.

The model is allowed to be clever. The pipeline is not allowed to take its word for it.

The Repository Started Moving Again

There is a convenient public receipt for all of this: exploitintel/eip-pocs-and-cves.

After activity stopped on May 20, 2026, the repository was quiet for 78 days. Publishing resumed on August 6. Between August 6 and August 12, 33 distinct CVE packages landed. As of August 13, the repository contains 117 CVE package directories.

Recent pull requests show the new path directly. The containerd CVE-2026-53488 publication and the Joomla CVE-2026-67285 publication were both staged by the pipeline, passed the publication audit, pushed to add/<cve> branches, and operator-merged as ordinary pull requests.

No launch video is as persuasive as a commit history that starts moving while nobody is presenting it on a slide.

The publication repository is also an approved first-party EIP source. Once a package is reviewed and merged, it returns through normal acquisition and its eligible files become searchable as code. The system contributes to the corpus it uses without letting a research agent write to the production database. We are fond of this arrangement. Production databases are less fond of surprises.

What We Refused to Automate Away

Models can perform substantial research, code analysis, lab construction, and validation. They can also be wrong. EIP v3 keeps both facts in view: source evidence survives, research and QA stay separate, incomplete packages are rejected, and publication happens through reviewable Git branches.

The public platform never executes acquired exploit code or builds third-party labs. Model output stays attributed interpretation, code-search relevance does not become an exploit ranking, and publication is never a side effect of asking an agent an interesting question.

The goal is not to remove the operator. It is to make the operator's attention land on decisions instead of plumbing.

Start Here

Browse the platform at exploit-intel.com. Search vulnerabilities, exploit artifacts, Docker labs, or the code itself. The Tools page has the current CLI and MCP setup.

Or skip the ceremony and give your agent this sentence:

Add https://exploit-intel.com/mcp as a remote Streamable HTTP MCP server named EIP, then call get_corpus_readiness to verify the connection.

It took longer than expected. There were at least two architectures, several perfectly reasonable ideas that became less reasonable when implemented, and one version number we have agreed not to discuss.

But the result is the system we originally wanted: not merely a place to look up a CVE, and not merely a pile of exploit links.

An exploit intelligence platform that retains the evidence, searches the code, speaks to agents, publishes reproducible research, and knows the difference between a model's opinion and a fact.

EIP v3 is the exploit database we meant to build.