EIP STIX 2.1 / TAXII 2.1 Feed: Exploit Intelligence for Your Stack

EIP now exports vulnerability and exploit intelligence as STIX 2.1 and serves a native TAXII 2.1 feed at:

https://exploit-intel.com/taxii2/

A one-shot per-CVE STIX bundle is also available from every vulnerability page and from the REST API:

https://exploit-intel.com/api/v1/vulns/CVE-2024-3400/stix2

The website is good for humans. The REST API is good for direct integrations. The CLI and MCP server are good for terminals and AI assistants. None of those are the right shape for a Sentinel workspace, an OpenCTI instance, a Splunk ES rule, or an internal Python pipeline that already speaks STIX/TAXII for everything else it ingests. Threat-intel tooling has converged on this format for a reason - it's the lane that lets a feed flow into the systems where decisions already happen, without the consumer having to learn yet another bespoke API.

It sounds like plumbing because it is plumbing. Good plumbing is underrated.

Why STIX and TAXII?

STIX is the language. TAXII is the delivery truck.

OASIS describes STIX as a JSON language for exchanging cyber threat intelligence. The important part is not the acronym; the important part is that STIX lets a producer say: this is a vulnerability, this is a tool, this tool targets that vulnerability, here are the references, here is the organization that produced the object, here is how the objects relate.

That maps unusually well to exploit intelligence.

EIP's public feed uses standard STIX 2.1 objects:

vulnerability for the CVE or EIP record
tool for public exploit code, proof-of-concepts, modules, and scanners
relationship with relationship_type: targets to connect the exploit tool to the vulnerability
identity for EIP as the producer
extension-definition for EIP-specific enrichment fields

TAXII is the transport. OASIS describes TAXII as an HTTPS API for exchanging CTI, built around discovery endpoints, API roots, and collections. A TAXII collection is basically a logical feed of STIX objects that clients can poll.

That matters because a lot of security tooling already knows how to speak this language. Microsoft Sentinel has a TAXII connector for importing from TAXII 2.0 or 2.1 servers. OpenCTI treats TAXII collections as a native way to share filtered STIX knowledge with other systems. Splunk Enterprise Security supports STIX 2.1 intelligence documents. And for custom workflows, the OASIS-maintained taxii2-client library gives Python code a clean way to discover API roots, collections, objects, manifests, and object versions.

In old-school terms: this is the difference between publishing a useful website and publishing a feed other people can build on.

What Is in the EIP Feed?

The first public collection is:

API root:      https://exploit-intel.com/taxii2/eip/
Collection ID: eip-public-exploit-context
Media type:    application/stix+json;version=2.1

The collection is read-only. It contains public, non-test vulnerabilities that have at least one non-writeup public exploit. We intentionally exclude rejected and merged CVEs, and we do not turn writeup-only references into active exploit relationships.

That last bit is important. A STIX relationship can look authoritative to downstream tools. If we say a tool targets a vulnerability, we want that assertion to mean something. Rejected CVEs, duplicates, and loose writeups are exactly where feeds can accidentally create noisy or misleading intelligence. We would rather be conservative.

A vulnerability object carries the standard STIX shape plus EIP enrichment:

CVE/EIP identifiers and external references
CVSS v3/v4 scores and provenance
EPSS score and percentile
CISA KEV, VulnCheck KEV, in-the-wild, EUVD, and ransomware-use signals
CWE IDs, vulnerability type, attack vector, and SSVC fields when available
affected products and CPEs
Nuclei template metadata
total public exploit count and selected exploit count
whether an EIP/community lab exists

An exploit tool object carries the exploit side:

source and source URL
quality and quality tier
exploit type, platform, language, author, publication date
GitHub stars/forks where relevant
code availability and file count
EIP's exploit classification and analysis fields
backdoor or maliciousness verdicts when the exploit analysis pipeline has them
MITRE ATT&CK technique hints when extracted

Then STIX relationships connect the two:

{
  "type": "relationship",
  "relationship_type": "targets",
  "source_ref": "tool--...",
  "target_ref": "vulnerability--..."
}

That graph is the point. Not just "CVE exists." Not just "here is a GitHub URL." A consumer can answer: which public exploit tools target this vulnerability, what do we know about their quality, and what vulnerability context should influence triage?

The One-Off Export

For humans and small automations, the simplest path is the per-vulnerability STIX bundle.

On the website, open a CVE page and use the STIX export button. From a terminal:

curl -fsS \
  'https://exploit-intel.com/api/v1/vulns/CVE-2024-3400/stix2' \
  -o CVE-2024-3400_EIP_STIX2.json

That bundle is useful when you want to attach context to a ticket, drop a single CVE into a lab workflow, inspect the STIX structure locally, or hand a specific vulnerability to another tool without subscribing to the whole feed.

It is deliberately bounded. We include selected public exploits and enough surrounding context to be useful, not an unbounded dump of every reference ever seen for a CVE.

The TAXII Feed

For systems, use TAXII.

Discovery:

curl -sS https://exploit-intel.com/taxii2/ | jq

Collections:

curl -sS https://exploit-intel.com/taxii2/eip/collections/ | jq

Objects:

curl -sS \
  'https://exploit-intel.com/taxii2/eip/collections/eip-public-exploit-context/objects/?limit=10' \
  | jq

Manifest:

curl -sS \
  'https://exploit-intel.com/taxii2/eip/collections/eip-public-exploit-context/manifest/?limit=10' \
  | jq

The manifest is useful for sync logic because it tells you which object versions exist and when they were added to the collection. The object endpoint supports paging. TAXII clients can also poll with added_after so they do not have to fetch the world every time.

Example:

curl -sS \
  'https://exploit-intel.com/taxii2/eip/collections/eip-public-exploit-context/objects/?added_after=2026-04-29T00:00:00Z&limit=100' \
  | jq

In production, EIP precomputes the TAXII object store after the normal ingest pipeline. App servers only serve indexed read-only rows. That keeps polling fast and avoids making every TAXII client trigger fresh STIX generation.

Microsoft Sentinel

Sentinel is a familiar example of why this exists, with one practical caveat: many SIEM threat-intelligence workflows are still indicator-centric. EIP's feed is vulnerability and exploit-context intelligence, so treat a Sentinel connection as something to validate in your workspace rather than a promise that every STIX object and extension will appear exactly as-is.

Microsoft's TAXII connector asks for the same things EIP now publishes:

TAXII API root URL
Collection ID
optional credentials
polling frequency

For EIP:

API root URL:  https://exploit-intel.com/taxii2/eip/
Collection ID: eip-public-exploit-context
Username:      leave blank
Password:      leave blank

Sentinel's documentation says the connector imports threat intelligence from TAXII 2.0 or 2.1 servers. Microsoft also documents newer ThreatIntelObjects support for STIX objects beyond classic IoCs, but the exact object types and fields each tenant preserves can vary, especially around custom STIX extensions.

EIP becomes part of the existing SOC intake loop instead of a separate tab someone remembers to check.

Python and Internal Pipelines

For internal workflows, the OASIS TAXII client is enough to get started:

python -m pip install taxii2-client

from taxii2client.v21 import Server, as_pages

server = Server("https://exploit-intel.com/taxii2/")
api_root = server.api_roots[0]

collection = next(
    c for c in api_root.collections
    if c.id == "eip-public-exploit-context"
)

for page in as_pages(collection.get_objects, per_request=100):
    for obj in page.get("objects", []):
        if obj.get("type") == "vulnerability":
            print(obj["name"], obj["id"])

That is enough to build a local cache, enrich internal asset exposure results, prioritize patch queues, or feed a notebook that correlates EIP's exploit quality with your own telemetry.

A few examples we expect people to build:

Pull new vulnerability objects daily and alert only when x_exploit_intel_com_has_public_exploit is true.
Join affected product names against a CMDB or SBOM inventory.
Raise priority when a CVE has public exploit code, KEV status, high EPSS, and a Nuclei template.
Suppress noisy "PoC exists" alerts when EIP's exploit analysis flags the available code as suspicious or backdoored.
Use EIP's STIX bundle as the portable evidence object attached to a patch exception review.

The feed isn't a replacement for judgment. It's structured input for the systems where judgment already runs.

What downstream tools actually preserve

STIX is a standard. Standards don't guarantee uniform support.

Different consumers preserve different parts of a STIX object. Some tools love indicators and observables but treat vulnerability objects as second-class citizens. Some parse standard fields but drop custom extensions. Some want a TAXII feed but only use it to populate IOC tables. That isn't a failure of the feed; it's the current state of threat-intel interoperability.

So we designed EIP's export in layers.

The core assertion is standard STIX:

vulnerability
tool
relationship
external references

The EIP-specific context lives in a documented extension:

https://exploit-intel.com/static/schema/stix-eip-extension-v1.json

If a consumer only understands vanilla STIX, it still gets the vulnerability, the exploit tool, the source links, and the targets relationship. If a consumer preserves extensions, it gets the richer exploit intelligence that makes EIP useful.

That is the pragmatic path. Speak the standard. Keep the extra signal. Do not pretend every downstream tool behaves perfectly.

How it's built

The obvious way to ship this would have been to bolt on a separate TAXII server pointed at generated STIX files. Medallion, the OASIS reference implementation, is the standard choice for that. Medallion is fine as a reference, but adding a second service and a separate storage model wasn't the right fit for a platform that already had a mature ingest pipeline, read-only app servers, and a single source of truth.

So the TAXII route lives natively in the existing stack. The publisher precomputes versioned STIX objects after each ingest cycle. Clients polling with added_after see real changes, not regenerated noise. Objects that fall out of scope between refreshes get a revoked: true version rather than disappearing.

It is boring in the way production systems should be boring.

Where this fits

In the milw0rm / SearchSploit era, the workflow was human by default: search, download, read the code, run it if you trusted it. That workflow still matters. We're not trying to erase it.

But it's one of several. SIEMs correlate. TIPs curate. Patch tools prioritize. Exposure management asks "is anything we own affected by this." AI assistants need structured context instead of scraped HTML. Internal scripts shouldn't depend on whether some page's HTML changed last Tuesday. Each of those flows already speaks some dialect of threat-intel ingest, and most of them speak STIX/TAXII as a baseline.

The website, the REST API, the CLI, the MCP server, and the TAXII feed each pick up a different lane. The TAXII feed is the lane for systems that already ingest threat intel. Same data. Better pipes.

Try It

Start with discovery:

curl -sS https://exploit-intel.com/taxii2/ | jq

Then list collections:

curl -sS https://exploit-intel.com/taxii2/eip/collections/ | jq

Then pull a small page:

curl -sS \
  'https://exploit-intel.com/taxii2/eip/collections/eip-public-exploit-context/objects/?limit=5' \
  | jq

Or grab one CVE as a STIX bundle:

curl -fsS \
  'https://exploit-intel.com/api/v1/vulns/CVE-2024-3400/stix2' \
  -o CVE-2024-3400_EIP_STIX2.json

If you connect it to something interesting, tell us - we're especially curious about the workflows we didn't predict.