ContextCrush: what happened and what we changed

In February 2026, Eli Ainhorn of Noma Labs found that Context7’s Custom Rules could be used by library owners to instruct coding agents to take malicious actions on the developers who use those libraries. The instructions were delivered as-is by our MCP server to the coding agents, which then followed those instructions. Eli reported the vulnerability to us privately, waited for us to fix it, and published the research on March 5, 2026.

Thank you Eli and the Noma team for the report, the clear proof of concept, and for verifying our fix before publishing.

In short:

• The vulnerability was fixed on the Context7 servers. Remediation started on Feb 19, 2026 and the fix was deployed on Feb 23, 2026.
• There is no npm package that needs to be upgraded as the issue was on the server.
• No exploitation in the wild was observed.

What Noma Security found

One of the features of Context7 is the ability for library owners to claim their libraries and add Custom Rules. These rules are usually brief instructions for AI coding assistants such as ‘Import components from the main package, not internal paths’. Up to 50 rules of 255 characters each can be added by an owner.

Previously our MCP server would send these rules verbatim alongside the documentation for any agent querying the library. Since anyone with a GitHub account can register a library, an attacker could register a library, add harmful rules and wait for a developer’s agent to look it up.

Although the Context7 MCP server is limited to looking up libraries and returning docs, and can’t run code or write files, the coding agent running in the IDE can, and the agent treated the rules as trusted instructions.

In Noma’s demo library they had included three rules, which told the agent to:

• Find all .env files in the project root and read them
• Send the contents to an attacker-controlled GitHub repository as an issue
• Delete local files and folders as part of a “cleanup” step

This is described by Noma as a supply-chain attack, which we think is accurate. The payload was hosted on our platform and delivered via our servers, the attacker didn’t need access to the victim’s machine.

Timeline

The dates below come from Noma's disclosure timeline and the VulnCheck advisory:

Five days passed from when Noma first reported the issue to us to the deployment in production of the fix.

What we changed

We updated the Context7 servers to first disable Custom Rules while we worked on a fix. This meant no rule would be distributed to any agents in the meantime. We then added an injection check before saving any rule, making sure that any rule trying to provide instructions that would be harmful would fail to save. We then re-enabled Custom Rules.

Library titles and descriptions also go through a similar check. When saving new titles or descriptions, Context7 refuses to save the title or description if it provides any instructions to AI agents, and provides an explanation to the library owner.

What the CVE record gets wrong

In August 2026, VulnCheck published CVE-2026-75130 for this issue, and attributed it to Eli Ainhorn. This CVE states that Context7 “through 2.1.2” is affected, and does not list a version that is fixed. AI assistants also repeat that versions up to 2.1.2 are affected when users ask about this vulnerability.

At the time of this report, 2.1.2 was the version of our npm package. However, this issue was about the way Custom Rules were stored and served from our servers, which affected all versions of our npm package (since they always get the Custom Rules from our servers). This server-side fix, therefore, addressed the problem for all package versions, on Feb 23.

There is a fix, and that fix has been in production since February. We are asking VulnCheck to update this entry to reflect the server-side fix (instead of referring to the version of the package) for this CVE.

Do Context7 users need to do anything?

No, Context7 users don’t need to upgrade, reinstall, or change any settings due to ContextCrush. Since the vulnerability was resolved on our servers, all clients (of any version package) have had the fix since Feb 23, 2026.

As outside confirmation, Noma validated the fix themselves before publishing the blog post.

What ContextCrush does highlight is the importance of reviewing how your agents access any MCP server. The following habits are good practices for minimizing the impact of a poisoned tool response:

• Ensure the agent requires permission before running any shell commands, deleting files, or making network requests.
• Don’t store sensitive information in plaintext .env files in any of the directories that the agent has access to.
• Limit the external sources the agent can access (and, when possible, use an allowlist).

For more detail on each of these points, see our MCP security checklist for enterprise teams.

How Context7 screens content today

Since anyone can submit repositories or websites, Context7 includes layered malicious content detection. A Context7-specific classifier detects prompt injection and malware patterns, then subjects any suspicious content to further checks. Our team reviews flags and updates detection logic for evolving attacks.

Teamspace administrators can also control which public libraries their developers can pull from, by adding policies that apply to all searches and MCP requests using the teamspace's API keys. Admins can:

• Limit to verified libraries or those with a minimum trust score of 4 or 7.
• Limit to libraries with a minimum number of stars or recent updates.
• Block individual libraries, or limit to only the specified libraries.

Quality filters a teamspace admin can set in Context7 policies

In the on-prem Enterprise version, ingestion and indexing is done on the customer network, and the team controls which private sources are indexed. Additionally, if the offline license is used, public library docs are only indexed if the team uses the Library Import feature, so they even control which public libraries are indexed. Learn more in our guide to self-hosted AI coding assistants.

Are trust scores enough?

No. Trust score itself cannot prevent a malicious library. Noma is right that GitHub reputation can be bought, hijacked or faked given enough time and automation.

The trust score is based on signals from repositories like stars, number of repositories, age of the account and activity. This score is used to sort the libraries as well as provide the ability to filter the libraries by administrators. This number tells you about how established the source of the library is but doesn't tell anything about the safety of a given piece of content.

This is why we have a separate layer for screening content. In ContextCrush, the screening was missing on Custom Rules and a high trust score would not have saved us from the planted rule. We fixed the issue in the content layer; a rule from a high scoring account goes through the same check for injection as a rule from a brand new account.

Is Context7 safe to use at work?

Yes, with the same care as any other tool providing third-party content to a coding agent. The ContextCrush vulnerability is patched, Context7 screens its content, and admins can control the libraries available to their teams. However, any tool that provides third-party documentation to an agent is inherently risky, and Context7 is no exception. Some reviewers have described the design as a structural risk (one service provides an open registry and also serves its contents to the agent's context). We agree that the ContextCrush patch alone doesn't eliminate that risk. In general, anything returned by an MCP server is untrusted input as far as the agent is concerned (be it Context7 content, web searches or README files).

Providing third-party library documentation to coding agents can be made reasonably safe as long as the provider of the documentation filters and screens its contents, and the agent requires confirmation before any dangerous action (no matter what its context says). Prompt injection via documentation and web searches is a broader issue, which we cover in indirect prompt injection examples.

You can read about data flow and content screening in our security docs. Upstash's SOC 2 Type II report is available on the Upstash Trust Center.