cd /news/ai-safety/an-mcp-server-bug-scores-9-0-no-fix-… Β· home β€Ί topics β€Ί ai-safety β€Ί article
[ARTICLE Β· art-106808] src=digitalapplied.com β†— pub= topic=ai-safety verified=true sentiment=↓ negative

An MCP Server Bug Scores 9.0. No Fix Is Documented

CVE-2026-75130, a prompt-injection vulnerability in Context7, Upstash's MCP documentation server, scores 9.0 critical under CVSS 3.1 and 6.4 medium under CVSS 4.0, with no public fix documented for affected versions 2.1.2 and earlier as of August 18, 2026. The advisory, published by the National Vulnerability Database and corroborated by VulnCheck, states that unsanitized Custom AI Instructions can be injected into connected AI coding agents, potentially leading to credential exfiltration and destructive file deletion. Researcher Eli Ainhorn of Noma Security is credited with the discovery.

read18 min views1 publishedAug 18, 2026
An MCP Server Bug Scores 9.0. No Fix Is Documented
Image: Digitalapplied (auto-discovered)

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.

  • 01One CVE, two severity verdicts.CVE-2026-75130 scores 9.0 critical under CVSS 3.1 and 6.4 medium under CVSS 4.0. Neither number alone tells the story β€” the frameworks disagree about how to count damage that lands on a system other than the vulnerable one.
  • 02A routine documentation request is the trigger.The advisory describes unsanitised Custom AI Instructions injected into a connected coding agent's context on an ordinary library-docs lookup. Documented impact: credential exfiltration from environment files and destructive file deletion.
  • 03The patch status is genuinely unresolved.The affected range is Context7 2.1.2 and earlier β€” a February-era build β€” yet the live npm package had already moved through 2.2.x and 3.x into the 4.0.x line before this CVE published. No public advisory or release note documents a fix, and no source says the later builds are still vulnerable either. Undocumented, not resolved in either direction.
  • 04It is likely β€” not confirmed β€” a regression.npm shows version 2.1.2 was published February 23, 2026, the exact date Noma Security says a fix for a closely related February bug reached production. The version that carried that fix sits inside the new CVE's affected range.
  • 05The lesson generalises past Context7.Any MCP server that delivers content into an agent's context is an instruction source. Today's agents have no native way to distinguish tool output from adversarial instructions β€” a class the MCP spec's own security-best-practices document does not name among its listed attack classes. That absence claim covers one document on the date we read it, and nothing wider.

01 β€” The AdvisoryWhat NVD and VulnCheck actually published. #

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.

upstash/context7

Live GitHub API pull against the upstash/context7 repository β€” the retrieval date is in the August 22 update in section 05. Noma's March writeup cited roughly 50,000 stars at its own publication date β€” a different snapshot; the two should not be blended.

30-day window

4,064,176 downloads of @upstash/context7-mcp over a rolling 30-day window around the disclosure β€” a monthly count, not a cumulative total. The retrieval date is in the August 22 update in section 05.

Already shipped at disclosure

The advisory's affected range β€” 2.1.2 and earlier β€” is anchored to a February-era build, but @upstash/context7-mcp had already moved through 2.2.x and 3.x into the 4.0.x line by the time this CVE published. Section 05 unpacks what that does and does not tell you.

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.

02 β€” SeveritySame bug, two verdicts: 9.0 critical vs 6.4 medium. #

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.

CVE-2026-75130 Β· one advisory, two scoring standards

Source: NVD CVE-2026-75130; VulnCheck advisory (both dated Aug 18, 2026)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.

Metric CVSS 3.1 reads CVSS 4.0 reads Why it matters
The headline split
Base score / band 9.0 Β· Critical 6.4 Β· Medium Two severity bands apart on the same facts β€” the aggregate the rows below explain.
Where the two frameworks agree
| Attack vector | Network (AV:N) | Network (AV:N) | Both agree the poisoned content arrives over the network. |
| Attack complexity | Low (AC:L) | Low (AC:L) Β· AT:N | No special conditions needed; 4.0's separate Attack Requirements metric is also None. |
| Privileges required | Low (PR:L) | Low (PR:L) | An attacker needs only low-privilege access to plant the instructions. |

| Where the models diverge β€” and the verdict flips | ||| | User interaction | Required (UI:R) | Passive (UI:P) | 4.0 distinguishes passive interaction β€” a routine docs request β€” from active participation. 3.1 has one bucket. | | Scope / system split | Scope: Changed (S:C) | VC:N / VI:N / VA:N | 3.1's binary flag counts the jump to the developer's machine at full weight. 4.0 scores the vulnerable system itself as unharmed. | | Impact accounting | C:H / I:H / A:H | SC:H / SI:H / SA:H | Identical harms β€” but 4.0 books them against the subsequent system, which its formula weights less heavily. |

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.

03 β€” MechanismA routine docs request is the whole trigger. #

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.

ownpermissions are irrelevant β€” the agent's permissions are the attack surface.

04 β€” HistoryFebruary's fix, August's CVE β€” a likely regression. #

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.

Dimension February 2026 incident August 2026 Β· CVE-2026-75130
Feature named "Custom Rules" β€” glossed by Noma as "AI Instructions (Custom Rules)" "Custom AI Instructions"
Key dates Reported 2026-02-18 Β· fix live 2026-02-23 Β· disclosed 2026-03-05 Published 2026-08-18
Severity on record None published in the sources we retrieved CVSS 3.1: 9.0 Β· CVSS 4.0: 6.4
Documented impact Env-file reads, exfiltration via an attacker-controlled channel, destructive deletion under a cleanup pretense (PoC) Credential exfiltration from environment files; destructive file deletion
Version link Fix shipped as 2.1.2, published to npm 2026-02-23 Affected range "≀ 2.1.2" β€” includes the version that carried the February fix
Resolution status Patched, per Noma's timeline No public fix documented at publication β€” see the next section and its August 22 update

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.

05 β€” Patch StatusIs it fixed? The only defensible answer is: undocumented. #

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.

no public fix is documentedfor Context7 2.1.2 and earlier, as of publication on August 18, 2026. Do not read this as "current versions are vulnerable," and do not read the 4.0.x line's existence as "it must be fixed." Treat the absence of documentation as the operative fact β€” and act on it, rather than waiting for an advisory that may not come.

@upstash/context7-mcpnow shows 4.0.3 as latest, released August 21, 2026 β€” three days after the CVE published β€” and its release note describes an OAuth authorization-validation patch, a different concern. The

upstash/context7 security-advisories pagestill shows zero published advisories, so no GHSA cross-references CVE-2026-75130, and no release note through 4.0.3 mentions the CVE, prompt injection, or Custom AI Instructions sanitisation. The

NVD entrywas last modified on August 19 and carries no fix reference. The standing claim holds, with its date moved forward: no public fix is documented as of August 22, 2026 β€” and still no source states that the 4.x builds are vulnerable. The scale figures in section 01 come from the same retrieval: 61,060 GitHub stars and 2,938 forks pulled from the GitHub API on August 22, 2026, and 4,064,176 npm downloads across the 30-day window from July 22 to August 20, 2026.

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.

06 β€” Exposure CheckThree checks before your next agent session. #

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."

07 β€” The Bigger LessonEvery context feed is an instruction source. #

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.

"By design, any MCP server that delivers content into an agent's context is effectively an instruction source, and today's AI agents have no native mechanism to distinguish between legitimate tool output and adversarial threats."β€” Noma Labs threat research team, 'ContextCrush' disclosure, March 2026

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.

08 β€” Team PlaybookFour postures, matched to your exposure. #

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.

Production secrets in .env files

Highest exposure to this exact bug class. Rotate anything a developer-machine env file holds, move secrets to a manager the agent cannot read directly, and disable unaudited MCP text sources until the record clarifies.

Approval-gated, scoped agents

If your agent requires approval for shell and network actions and cannot read env files, the documented impact chain has no unattended path. Keep the gates on and version-pin your MCP servers deliberately.

Teams that rely on live library docs

Weigh the productivity of live documentation against an undocumented patch status. A reasonable middle path: run the docs server in a profile with no file-write or shell reach, so injected text can at most mislead, not act.

Engineering leads & security owners

Add MCP servers to the same supply-chain review you apply to dependencies: version inventory, permission audit per agent, and a standing rule that context feeds are untrusted input. This CVE is the citable precedent.

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.

09 β€” ConclusionRead the vector, audit the agent, distrust the channel. #

The score you quote matters less than the permissions your agent holds.

CVE-2026-75130 is three stories in one. A severity story: 9.0 and 6.4 are both correct, and the gap between them is a lesson in how CVSS 3.1 and 4.0 count chained damage differently. A process story: a likely β€” not confirmed β€” regression, where the npm version that carried February's fix sits inside August's affected range, and where the honest patch status is undocumented rather than resolved in either direction.

And a structural story, which is the one that outlives this CVE: any MCP server that feeds text into an agent's context is an instruction source, the agent's permissions β€” not the server's β€” define the blast radius, and neither the protocol spec nor the advisory ecosystem has fully caught up with that class yet. The absence of a GitHub advisory at publication is not reassurance; it is a reminder that for this bug class, the formal signals lag the risk.

The practical response fits in an afternoon: inventory your MCP server versions, audit what each connected agent can read and execute, get production credentials out of plaintext env files on developer machines, and write down β€” as policy β€” that content arriving through an agent's context is untrusted input. Do that, and the next CVE in this class becomes a version check instead of an incident.

── more in #ai-safety 4 stories Β· sorted by recency
── more on @context7 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain β€” perfect for shipping the agent you just read about.

$git push zahid main
β†’ Live at https://your-agent.zahid.host βœ“
Get free account β†’ Pricing
from €0/mo Β· no card required
LIVE [news/an-mcp-server-bug-sc…] indexed:0 read:18min 2026-08-18 Β· β€”