An MCP Server Bug Scores 9.0. No Fix Is Documented

CVE-2026-75130 is a prompt-injection vulnerability in Context7, Upstash's widely installed MCP documentation server — published to the National Vulnerability Database on August 18, 2026. It scores 9.0 critical under CVSS 3.1 and 6.4 medium under CVSS 4.0 — the same bug, opposite verdicts — and, as of publication on August 18, 2026, no public fix is documented for the affected range, Context7 2.1.2 and earlier.

The mechanism is uncomfortable in its simplicity. Context7's Custom AI Instructions feature can place unsanitised instructions into any connected coding agent's context when the agent makes a routine library-documentation request. Per the advisory, that path can reach credentials in environment files and trigger destructive file deletion — not because the MCP server can do any of that itself, but because the agent it feeds can.

This piece covers what the advisory actually says, why two scoring frameworks land two severity bands apart on identical facts, the evidence that this is likely a regression of a bug class patched in February, the honest state of the patch question, and how to check your own exposure — without exploit detail, and without inventing a vendor response that does not exist on the record.

The official advisory text is one sentence: "Context7 through 2.1.2 contains a prompt injection vulnerability that allows attackers to execute malicious instructions in connected AI coding agents by injecting unsanitized content through the Custom AI Instructions feature served via the MCP server." NVD published the entry on August 18, 2026; VulnCheck's advisory corroborates the same facts and adds the weakness classification — CWE-1427, "Improper Neutralization of Input Used for LLM Prompting" — and the researcher credit: Eli Ainhorn, Senior AI Vulnerability Researcher at Noma Security.

Why this particular server matters is a question of installed base. Context7 serves up-to-date, version-specific library documentation to AI coding assistants — Cursor, Claude Code, and Windsurf among them — installed as an MCP server inside the developer's IDE. The first two figures below are our own pulls rather than figures from an earlier snapshot taken in a different month; the third sets up the version question section 05 takes apart.

One structural detail from the original research deserves early billing, because it reframes everything that follows: the Context7 MCP server itself is minimal. It exposes two read-only tools — resolve-library-id and query-docs — and cannot execute code, write files, or make network requests on its own. Every documented impact in this advisory is achieved by getting the connected coding agent, which does have file, shell, and network access, to act on injected text. The server is the courier, not the weapon.

Most CVE coverage quotes one number. This advisory makes that actively misleading, because the two current scoring standards disagree by two severity bands on identical facts. CVSS 3.1 reads the vector AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H and returns 9.0, critical. CVSS 4.0 reads AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H and returns 6.4, medium.

The divergence is not a clerical error — it is the two frameworks modelling chained damage differently. CVSS 3.1 has a binary Scope flag: because the injection jumps from the MCP server to the developer's machine and downstream systems, Scope is Changed, and the full confidentiality, integrity, and availability impact of the agent's capabilities gets counted against the score. That is what drives 9.0. CVSS 4.0, released in late 2023, replaced the Scope flag with separate Vulnerable System and Subsequent System impact metrics. Under 4.0's reading, the vulnerable system — the documentation server — suffers no confidentiality, integrity, or availability impact of its own (VC:N/VI:N/VA:N). All the harm lands on the subsequent system (SC:H/SI:H/SA:H), and 4.0's formula does not reward subsequent-system damage as heavily. Verdict: 6.4, medium.

Which verdict is right? Both, within their own models — which is precisely why quoting either alone tells half the story. Our reading: for a security team triaging by dashboard, the 6.4 will under-page you; for a developer whose machine holds production credentials, the 9.0 is the number that matches the blast radius you personally face. The durable takeaway is to read the vector, not the score, whenever a CVE involves an agent acting on injected content — this scoring split will recur across the entire CWE-1427 class, because the vulnerable component and the damaged component are structurally different machines.

We are deliberately describing the attack class here, not a recipe. The advisory's own summary is sufficient: "Attackers can poison the custom instructions to exfiltrate credentials from environment files to an attacker-controlled service and perform destructive file deletion on the victim's machine when the agent makes a routine library documentation request." No unusual developer action is required. Asking your coding agent for help with a library is enough to pull the poisoned instructions into its context.

The chain has three conceptual steps, all executed by the agent rather than the server: injected instructions direct the agent to read local environment files; further instructions direct it to send the contents to an attacker-controlled endpoint; and a final set can direct destructive deletion of local files under an innocuous pretense. Noma's February research documented an almost move-for-move version of the same chain against the feature's earlier incarnation — which is why the regression question in the next section matters so much.

This is not the first disclosure against this feature area. In February 2026, the same research firm — Noma Security, same researcher lineage — documented a closely related injection bug in Context7's "Custom Rules" feature, which Noma's own writeup glosses as "AI Instructions (Custom Rules)" — the same terminology family as the August CVE's "Custom AI Instructions." That bug was discovered and reported to Upstash on February 18, 2026, a fix reached production on February 23, and Noma published its "ContextCrush" writeup on March 5. By Noma's account, Upstash responded quickly to the February report — that characterisation is the only vendor-adjacent statement on record, and it concerns the February bug, not this one.

Here is the detail that turns a resemblance into evidence: the npm registry shows @upstash/context7-mcp@2.1.2 was published on February 23, 2026 — the exact date Noma's timeline says the February fix reached production. And the August advisory lists "Context7 ≤ 2.1.2" as affected. The very version that shipped the February fix sits inside the new CVE's affected range. That is a date match, not an inference — though no source states outright that the same code path regressed, so "likely" and "apparent" are the honest adverbs, and they are the ones we use.

Neither advisory connects the two incidents in its own text — only NVD's reference list, which cites Noma's "ContextCrush" post, ties them together as one continuing body of research into this exact feature area. Laying the timelines side by side, with the npm cross-check as connecting evidence, is the synthesis the primary sources do not do — and it is why coverage that assumes this bug was already fixed by the February patch gets the story backwards. The February patch is the version now listed as vulnerable.

Here is where the reporting discipline matters most, because the circulating framings — "still unpatched" on one side, "surely fixed by now" on the other — are both unsupported. The facts: the advisory's affected range, Context7 2.1.2 and earlier, is anchored to a February-era build. The live @upstash/context7-mcp package had already moved through 2.2.x and 3.x into the 4.0.x line before this CVE published on August 18 — several major-version strings separate the affected range from what a developer installing that day actually got.

What the advisory itself does not carry is a fix reference. It names no patched version and points to no vendor advisory. But the inverse is equally true: no source states that the 4.x builds are still vulnerable. Whether the flaw was independently fixed somewhere in that long release run, or whether "≤ 2.1.2" simply reflects the version the researcher tested, is not answerable from the public record.

One more absence worth stating narrowly: we found no on-the-record Upstash statement about the August CVE, and no secondary press coverage of it was retrievable in our research pass. Silence in the sources we checked is not refusal, and it is not negligence — responsible-disclosure conversations routinely happen in private. It simply means the public record does not answer the question. That is the situation your risk decision has to be made in.

If anyone on your team runs Context7 — or any MCP documentation server — inside a coding agent, this is the short audit we would run today.

First, inventory the installed version. Check which version of @upstash/context7-mcp your MCP configuration actually resolves — a pinned 2.x is inside the advisory's affected range outright, and a floating latest tells you only that you are on a version whose status is undocumented. Either way, you now know which side of the open question you are on.

Second, audit what the connected agent can reach. The blast radius of this bug class is the agent's permissions, not the server's. If the agent can read .env files, run shell commands, or make outbound requests without approval, injected instructions inherit all three. Deny-listing environment files from agent file access, requiring approval for shell and network actions, and keeping production credentials out of plaintext env files on developer machines each independently shrink the damage an injection can do.

Third, treat the missing advisory as information. As of publication there is no GitHub Security Advisory to subscribe to for this CVE, so do not gate your response on one appearing. Decide now — based on your credential exposure and agent permissions — whether the server stays enabled, runs in a sandboxed profile, or comes out of the loop until the record clarifies. Noma's research also cautions against outsourcing this call to reputation signals: in their words, "A high trust score does not equate to a secure supply chain; it simply means the account has a history, real or manufactured, that can be weaponized."

Strip away the CVE number and the version arithmetic, and what remains is the structural finding — the one that applies to every MCP server in the wider MCP server ecosystem, not just this one. An agent's context window is a single undifferentiated channel. Documentation, tool results, and attacker-planted instructions all arrive as text, and the model has no protocol-level way to know which is which.

The protocol's own guidance has not caught up with this class. As of our August 22, 2026 read, the MCP security-best-practices document on modelcontextprotocol.io — the spec's official security guidance — contains no dedicated section on untrusted content injected through a trusted channel. Its seven named attack classes are all authorization- or transport-layer: confused-deputy OAuth proxying, token passthrough, SSRF during OAuth discovery, state-handle hijacking, local-server compromise through malicious startup commands, OAuth-URL scheme injection, and stdio-proxy privilege escalation. All real, all worth defending — and none of them is what happened here. That absence claim is narrow — this document, this date — but it means the content-trust layer is currently the operator's problem, not the protocol's. (For spec-level background, see our walkthrough of the MCP spec's stateless migration.)

Looking forward, we expect CWE-1427 — "Improper Neutralization of Input Used for LLM Prompting," the classification this CVE carries — to become one of the highest-volume weakness classes in the agentic stack, for a simple structural reason: every capability added to coding agents widens what injected text can do, while the number of text sources feeding agent context grows with every MCP server, skill pack, and plugin installed. The same trust-chain problem already shows up in agent skill packs, in AI-hallucinated package names, and in compromised AI infrastructure tooling. Context7 is not the outlier; it is the example that happened to get a CVE number this week.

There is no single right response, because the risk is a function of what your agents can reach. These are the four postures we see, with our recommendation for each situation.

If your organisation is rolling out coding agents and needs the governance side built properly — permission models, MCP server review, credential isolation — that is exactly the kind of engagement our AI transformation practice runs, and this advisory is a good forcing function to start with.