The MCP Security Incident Ledger: 27 Dated Entries

MCP security incidents now have a sixteen-month public record — and nobody had put it in one table. From Invariant Labs naming “tool poisoning” in April 2025 to a Context7 CVE disclosed six days before this post’s dateline, this ledger collects 27 dated entries: 25 incidents and the two protocol revisions that answered them, each pinned to the dated record it came from.

The stakes are not abstract. The Model Context Protocol has crossed into mainstream infrastructure — we tracked MCP’s mainstream adoption numbers earlier this year — which means every incident below happened, or can happen, inside toolchains that agencies, startups, and enterprises already run. When the next MCP incident lands, the first question any journalist, security lead, or buyer asks is: what’s the track record? This page is that record.

What follows: the counting rules, the full 27-row ledger, a frequency breakdown of what actually dominates the disclosed record, a patch-latency table that separates “patched” from “remediated in the field”, the Context7 regression date-match nobody else appears to have published, and the rows no patch can ever close.

A ledger is only as citable as its counting rules, so here they are. A row requires a date from a primary record — a CVE or GHSA publication date, a vendor advisory, or a named researcher’s dated disclosure. An incident that cannot be dated from a primary record gets no row. One row — entry 22, CVE-2026-0755 — is dated to the month rather than the day, and it is shown that way rather than given a precision the record does not support. Where a second identifier for the same product circulated only in secondary coverage, it gets no row either — related identifiers are never merged into one entry on a secondary source’s say-so.

One event equals one entry, even when it spans multiple CVE numbers: Anthropic’s Filesystem MCP Server sandbox escapes (two CVEs, one Cymulate disclosure, one patch release) are one row, and OX Security’s April 2026 advisory — 16 CVEs across 14+ platforms, all the same defect pattern — is one row. Other trackers count every CVE separately and reach 40+; both tallies are defensible, but they measure different things. The 27 here are this ledger’s 27 verified entries, not an industry census.

Two entries are not incidents at all: the November 2025 authorization spec revision and the July 2026 stateless revision. They earn rows because a security ledger that omits the protocol’s own dated responses tells half the story. And the patch column obeys one discipline throughout: status is reported as of August 24, 2026. “No fixed version documented at capture” is a fact about the record; “still unpatched” would be a claim about the present that a dated page cannot honestly make. This is the same pin-every-row-to-a-source discipline that shaped our agent-framework SSRF validation census, applied to a timeline instead of a feature matrix. For the catalog of what’s running in the ecosystem rather than what broke, see the 50-server ecosystem tracker.

Read the table in four phases. April–June 2025 is the vocabulary phase — researchers naming attack classes before CVE numbers existed for them. June–August 2025 is the CVE wave hitting individual servers and host apps. September–December 2025 brings the first confirmed-malicious package, mass exploitation, and the spec’s first hardening response. And 2026 escalates to platform-level CVEs, a 16-CVE coordinated advisory, and the ledger’s newest open entry.

Classify the 25 incident rows and the distribution is lopsided. Prompt injection gets the headlines — it is the MCP-native attack, the one that makes agents special. But the disclosed-CVE record is dominated by something far older: command and code injection through unsanitised exec, stdio, and config input, at 11 of 25 rows — more than double the prompt-injection count.

The trend reading matters more than the counts. Command injection dominates the CVE record partly because it is mechanically easy to find — static analysis catches an unsanitised exec() call in a way no scanner catches a poisoned tool description. So the disclosed record likely understates prompt-injection risk relative to its real-world weight: the injection rows are the ones a linter could have prevented, while the poisoning rows are the ones only architecture can address. A team that reads this table as “prompt injection is rare” has read it backwards — it is rare in CVE databases because CVE databases were never built to hold it.

The supply-chain rows deserve their own sentence, because one of them crossed a line no earlier entry had: postmark-mcp was not vulnerable, it was hostile — fifteen legitimate releases building trust before v1.0.16 added a single line that BCC’d every outbound email to an attacker’s domain. Postmark’s own statement was blunt: “Postmark had absolutely nothing to do with this package or the malicious activity. This is not an official Postmark tool.” The impostor-package pattern needs no vulnerability at all — only a plausible name and patience.

Where the record documents both a report date and a fix date, you can compute latency — original arithmetic no single source in this research published as a distribution. The spread runs from two days to never. And two rows prove that the patch date is only half the story: the field keeps running the vulnerable version long after the fix ships.

Tally the fix column across all 25 incident rows and the honest summary is: 14 rows name a fixed version or a dated production fix, two more (Asana, Smithery) were hosted remediations with no version to name, three have no fix documented at capture, four are architectural and cannot be version-fixed, one was malicious by design, and one — the OX advisory — is a mixed bag across 14+ platforms. That is 16 of 27 entries with a confirmed fix, counting the two hosted remediations. A ledger that printed a flat “Patched: Yes” checkmark column would flatten all six of those categories into false confidence.

Two ledger entries share one component, and the dates line up in a way worth recording. Entry 23: Noma Security reports ContextCrush in Context7’s Custom Rules on February 18, 2026, and Upstash ships a production fix five days later. Entry 27: CVE-2026-75130, disclosed August 18, 2026, is a prompt injection in the same product’s custom-instruction surface, with an affected range of ≤2.1.2.

Here is the connective fact: npm shows @upstash/context7-mcp@2.1.2 published on February 23, 2026 — the exact date the ContextCrush fix reached production. The version that shipped the February fix sits inside the August CVE’s affected range. Roughly six months separate the fix and the new CVE against the same attack surface — which makes the August entry read as a likely regression or an incompletely closed class, not a novel bug family. We are not aware of anyone else having published this date-match. For the full story of the August CVE itself — mechanism and what to do about it — see our full writeup of CVE-2026-75130; this ledger only records its dates.

Two record-keeping notes on that entry. First, its severity is genuinely double-valued — 9.0 on CVSS 3.1, 6.4 on CVSS 4.0 — and quoting either number alone tells half the story, so this ledger carries both. Second, its patch cell is the strictest in the table: the affected range (≤2.1.2) sits below the npm latest at research time (4.0.3, released August 21), yet no GHSA and no release note through 4.0.3 documents a fix for this specific CVE. “No public fix documented as of the date checked” is the only defensible framing — not “fixed”, and not “still unpatched” either.

Four incident rows have no version number in their status cell and never will: Invariant’s tool-poisoning class disclosure, its WhatsApp exfiltration demo, the GitHub MCP toxic agent flow, and the Supabase lethal trifecta. Invariant was explicit about the GitHub case: this is not a bug in the server’s code. It is a confused-deputy pattern — an agent granted real privileges, reading attacker-controlled content, with a channel to leak through. You cannot patch a server out of an architecture.

The vendors involved responded the only way the class allows: by narrowing blast radius. Supabase’s September 2025 write-up — which noted no customer data leak had been reported — shipped read-only mode, project-scoped mode, and tool feature groups, while cautioning that “guardrails alone aren’t enough.” That phrasing is the right epitaph for the whole category: these four rows stay open on every future edition of this ledger, managed rather than closed. For how to actually defend against the techniques behind them, see the attack-technique and defense playbook — this page deliberately stays a record, not a manual.

For teams running MCP in production, the operational translation is scope, not patching: least-privilege connections, read-only defaults where the workload allows, and treating every external data source an agent reads as attacker-controlled. Auditing an agent stack against exactly this class of exposure is part of what our AI transformation engagements cover — the ledger above is, in practice, the checklist of what has already gone wrong for someone else.

The two non-incident entries are the protocol reading its own incident record. The November 25, 2025 authorization revision made MCP servers formal OAuth 2.1 resource servers — RFC 9728 Protected Resource Metadata so clients discover the correct auth server, RFC 8707 Resource Indicators so a token cannot be replayed against the wrong MCP server. Those are direct answers to the token-theft and confused-deputy classes that fill the 2025 rows. The July 28, 2026 stateless revision then removed the handshake and session header entirely and required RFC 9207 issuer verification, closing a session-hijacking-adjacent gap in multi-server deployments — we cover the mechanics in the July spec’s stateless migration guide, so this ledger records it purely as a dated hardening event.

Looking forward, the honest projection from sixteen months of record is that the ledger grows at both ends. The command-injection rows should thin as the OX advisory’s lesson — never spawn subprocesses from unsanitised config — hardens into SDK defaults and CI linting; that class is mechanically findable and mechanically preventable. The prompt-injection and confused-deputy rows should thicken, because each spec revision that closes one theft target tends to mint the next one — security commentary around the stateless revision has already flagged opaque state handles as the successor to session-ID theft. And the Context7 date-match suggests a third growth lane nobody budgets for: regressions of fixes already shipped. Expect future editions of this page to add rows faster than they retire them.