ContextCrush: Docs MCP Serves Poisoned Custom Rules Into Coding Agents

In plain language

Imagine a trusted encyclopedia that lets any author paste a sticky note on a page—and your intern treats that sticky note as orders from the boss. Context7’s Custom Rules (AI Instructions) were meant to help coding agents use a library correctly. For a window of time they were delivered verbatim through Context7’s MCP docs tools, with no wall between “helpful tip” and “read `.env` and mail it out.” The attacker never needed to reach your laptop: they poisoned a library once; your assistant asked for docs; the agent did the rest with tools it already had. Treat MCP-served text as untrusted data, pin what you install, and gate secret reads and destructive actions.

The Incident

A developer installs Context7—the popular “up-to-date library docs” MCP—opens Cursor or Claude Code, and asks how to configure a familiar package. The assistant pulls documentation. Somewhere in that same trusted channel sit Custom Rules registered for the library. The model does not see them as a stranger’s paste into chat. It sees them as part of what Context7 returned. Minutes later: environment secrets sit in an attacker-controlled GitHub Issue, and a “cleanup” rule has deleted local folders.

Here is why the comfort story failed.

Why existing thinking failed

The comfort story: MCP servers that only expose `resolve-library-id` and `query-docs` are “read-only,” so they cannot hurt you; popularity and GitHub trust scores mean the supply chain was vetted; prompt injection is something users type or pages they browse—not something a docs CDN delivers.

That fails when delivery trust and content trust are confused. The MCP server does not need Bash, file write, or network tools. It only needs to place attacker-controlled natural language into the same context window as legitimate documentation. The coding agent—which does have Bash, file, and network tools—executes what it now believes are instructions. Allowlisting the Context7 server does not inspect every library’s Custom Rules. A high GitHub “trust score” for a library owner is not a content sanitizer.

Research proves it

Confirmed in Noma Security’s ContextCrush disclosure (Eli Ainhorn, 5 March 2026) and the CVE record CVE-2026-75130 (published 18 August 2026, CNA VulnCheck). Context7 through 2.1.2 could serve unsanitized Custom AI Instructions via the MCP path. Documented research impacts: credential theft from `.env`, exfiltration to an attacker GitHub Issue, and destructive local deletion framed as cleanup. CWE-1427 (Improper Neutralization of Input Used for LLM Prompting). CVSS 3.1 9.0 / CVSS 4.0 6.4—same bug, different scope framing (agent-side impact vs. classical product CIA).

Confirmed disclosure timeline (Noma): discovered/probed 18 Feb 2026; Upstash accepted 19 Feb; production fix with rule sanitization and guardrails 23 Feb 2026; public write-up 5 March. Noma reports no evidence of in-the-wild exploitation and credits Upstash’s collaboration. Confirmed product role: Context7 is both registry (anyone can manage library docs/rules) and delivery channel into IDEs—stars/downloads cited by Noma as ~50k / 8M+ at disclosure (adoption has grown since).

Reported: secondary explainers around the August CVE listing (e.g. advisory aggregators) repeating the same mechanism; some note confusion when public npm range language and “fix documented” narratives diverge from Noma’s February production fix. Prefer Noma + CVE.org as primary. Unknown: whether any specific enterprise was hit before the February fix. Speculated: how thoroughly any one IDE still treats MCP tool results as executable policy after sanitization landed upstream.

Engineering takeaway

Read-only MCP is not a safety boundary. Anything that can write into the model context is an instruction channel unless the host enforces otherwise. Custom Rules are a first-class injection surface. Host controls—not “the docs server can’t run code”—are what stop `.env` exfil and `rm`-shaped cleanup. That is the APRF Core map below.

Why this matters

Stake: any team that points a coding agent at a shared docs MCP inherits every library owner’s ability to publish natural-language instructions into that agent’s context—unless host and registry treat that text as hostile by default.

Affected, as far as facts allow: Noma’s research demonstration; not a named customer breach. Class: Agents + MCP + Tools. Pure API chatbots without tool-using agents are a weaker fit.

Can a startup ignore it? No if developers use Context7 (or any aggregator MCP) with agents that can read secrets or mutate disks. Maybe if MCP is off. Inventory quarterly: “temporary” docs MCP is how this class arrives.

Timeline

Root Cause

Three properties coincide: aggregator trust (Context7 is the channel everyone already approved); verbatim Custom Rules mixed with documentation in the same tool results; confused deputy (the IDE agent already holds FS/network capabilities the MCP server lacks).

Root cause class: indirect prompt injection via MCP-delivered third-party instructions (supply-chain flavored)—not host RCE by the MCP binary, and not a model-weight jailbreak.

APRF Lens

Failure class (APRF / threat-map vocabulary): Prompt Injection into agent context via MCP, enabling Tool Abuse / Excessive Agency and Data Exfiltration (AML.T0086), with Supply Chain Compromise flavor (AML.T0010.005 / AML.T0110) because the payload lives in a shared registry. Also AML.T0051 / AML.T0053. Informative only—not certification. Soft link: /aprf/threats/.

Profile: Core only (this week’s scope). MCP/agents appear as affected systems, not as an extra CLI lens on the auditor run.

Check families in play (APRF 0.11.0; threat-map grounded):

Good evidence: server-side policy that treats MCP tool results as data; deny tests when Custom Rules text tries to authorize `.env` read or folder delete; HITL shows resolved paths and destinations; MCP server pin + library provenance review; linked traces on a canary; a release gate that fails if poisoned-rules cases regress.

Standing caveat: APRF assessments can miss evidence. A repository is not the only source of truth. Runtime config, cloud IAM, secrets stores, vendor consoles, CI variables, production prompts, deployed model/tool versions, and human processes often never appear in source control. Absence of a finding is not proof of readiness. Scoring the open Context7 monorepo is not a score of Upstash production sanitization or of your IDE. Threat-map rows are not certification.

APRF mapping confidence: High. Auditor confidence: Medium — public monorepo + offline Core; Custom Rules fix lives largely on private backend.

Abuse Path Analysis

- Attacker → Registry → MCP: One poisoned library becomes many victims because the aggregator delivers it — cut with SCI-M2 (know what MCP and libraries you consume) plus registry-side sanitization (vendor fix).

- MCP → Model: Docs and rules share a trusted channel — SEC-M1 (untrusted MCP text cannot authorize privileged effects); SEC-M3 so evals include Custom Rules / docs-channel cases, not only chatbox jailbreaks.

- Model → Read / Exfil / Delete: The deputy already has capabilities — TOL-M1 (platform disposes), TOL-M2 (tools don’t appear because instructions asked), TOL-M3 / HUM-M1 on secret-class and destructive actions.

- Observability: Without OBS-M1 linkage, “assistant helped with docs” and “secrets left the laptop” never meet in one timeline.

Abuse path confidence: High — Noma’s documented sequence matches the CVE description end-to-end. Speculative only for post-fix bypasses and any one vendor’s unpublished IDE mitigations.

Standing caveat (brief): APRF assessments can miss evidence; a repository is not the only source of truth. This graph is the research chain, not your production IAM or IDE policy.

Relevant Controls

Patterns from the Context7 public repo (not a CVE re-test)

Assessment evidence: `npx @stackrail-io/aprf@0.1.3 audit --profile core` against upstash/context7 @ `9a384f099011d6299df530fd8d7a22510b2004d5` (offline, 2026-08-26). Artifacts: `drafts/2026-08-26-context7-custom-rules-mcp-prompt-injection-aprf-auditor/`.

This tree is the open MCP/CLI monorepo, not Upstash’s private registry service where Noma’s February sanitization landed. Offline Core returns gate FAIL with many Not Demonstrated host Checks—expected for a docs package that is not an agent host. Do not read overall grade F as “Context7 failed the CVE” or “the February fix is absent.”

On failure-class IDs: TOL-M1 / TOL-M2 / TOL-M3 / SEC-M3 / HUM-M1 Not Demonstrated (no IDE host gates in-repo). SEC-M1, SCI-M2, OBS-M1 Partial (signals without production deny/inventory/trace proof).

Useful pattern evidence in-repo (manual): MCP surface is intentionally thin (`resolve-library-id`, `query-docs`); changelog notes moving auth nudges from in-result text to elicitation so agents stop treating injected prose as instructions—the same class of mistake Custom Rules exploited at registry scale.

Limits: no live IDE; no registry admin API; no claim we re-poisoned production Custom Rules after 2026-02-23.

How to Prevent It

Next 24 hours

1. Inventory coding agents with Context7 (or any docs aggregator MCP) enabled.

2. Confirm you are past the affected window (vendor fix 2026-02-23; CVE lists through 2.1.2—verify your installed MCP package and that you are on current Context7 service behavior).

3. Disable or HITL-gate agent tools that can read `.env`/SSH and that can post to arbitrary remotes or delete trees while docs MCP is connected.

4. Treat unexpected “cleanup” or “send diagnostics” suggestions during routine docs asks as incidents.

Next 30 days

1. Encode SEC-M1: MCP tool results are data; they cannot authorize privileged tools.

2. Add SEC-M3 cases: poisoned Custom Rules / docs-channel instructions in release gates.

3. Enforce TOL-M2 / TOL-M3 / HUM-M1 on secret-class and destructive tools.

4. Complete SCI-M2 for every MCP server: pin, owner, last review, why installed.

Longer term

1. Prefer architectures that separate documentation retrieval from agent tool authority (viewer vs executor).

2. Demand registry-side content policy from every aggregator you depend on—and still assume bypass.

3. Keep OBS-M1 journeys so docs fetches and secret-touching tools share one timeline.

4. Revisit GitHub “trust scores” as non-controls (Noma’s point on purchased/faked reputation).

Engineering Lessons

1. Read-only MCP ≠ safe MCP. Instruction delivery is the capability that matters.

2. Channel trust ≠ content trust. Approving Context7 does not approve every library’s Custom Rules.

3. Popularity is not a control. Stars and downloads accelerate blast radius.

4. CVSS disagreement teaches scope. 9.0 vs 6.4 reflects whose CIA you measure—the agent side is where the laptop burns.

5. Vendor fix ≠ host fix. Upstream sanitization does not replace TOL/HUM gates in the IDE.

6. Elicitations beat in-band prose. Don’t stuff user prompts into tool results the model will obey.

Could this happen to you?

If three or more rows match, treat this as an open production risk even after upstream patches.

Continues in the APRF Incident Corpus

GhostSplice splits one theft across MCP description/result surfaces. ContextCrush plants the instruction in a shared docs registry and rides a trusted MCP. Confused-deputy allowlist failures and encrypted context injection are siblings: the model is not the perimeter—the host and the supply chain are.

Soft CTA: self-attest against Core (questionnaire—not certification) at /aprf/assess/. For evidence-backed runs against your agent host, use the open APRF Auditor skill.

FAQ

Did StackRail detect this incident in the wild? No. This piece maps public research (Noma) and CVE-2026-75130 to APRF Checks. We do not claim detection or prevention of a named customer event.

Is Context7 still vulnerable? Noma reports a production fix with sanitization/guardrails on 23 February 2026, before public disclosure. CVE-2026-75130 still documents the affected range through 2.1.2. Verify your installed client package and current service behavior; do not rely on this article as a live version oracle.

Why audit the public repo if the bug was in Custom Rules? To ground host-side Controls (TOL/SEC/HUM/SCI/OBS) against a real MCP monorepo and to avoid inventing evidence. Registry sanitization is vendor-side; agent hosts still need gates.

Is this the same as GhostSplice? Same family (MCP → agent context → tool abuse), different mechanism: split instructions vs. registry Custom Rules delivered as docs.

References

1. Eli Ainhorn / Noma Security — ContextCrush: The Context7 MCP Server Vulnerability (2026-03-05)

2. CVE-2026-75130 (CVE.org / VulnCheck CNA, 2026-08-18)

3. GitHub Advisory GHSA-97r6-3rgm-v39r

4. upstash/context7 (public MCP/CLI monorepo)

5. StackRail — /aprf/threats/ (informative threat map)

6. Related corpus: GhostSplice split-instruction exfil, MCP tool allowlists / confused deputy, Grok encrypted context injection