Join our Newsletter — 33% off our NHI Course

Unveiling the Context7 MCP Server Vulnerability: What You Missed

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 21735
Topic starter  

TL;DR: A critical flaw in Upstash’s Context7 MCP Server let poisoned “Custom Rules” flow through a trusted channel into AI coding assistants, enabling credential theft, exfiltration, and destructive file actions, according to Noma Security’s research. The case shows that MCP trust assumptions, not just model behavior, now shape the security of agentic development workflows.

Editorial analysis by NHI Mgmt Group, based on content published by Noma Security: “ContextCrush: The Context7 MCP Server Vulnerability Hiding in Plain Sight”.

Key questions

Q: What breaks when an MCP server delivers attacker-controlled instructions into an AI coding assistant?

A: The boundary between content and command breaks.

Q: Why does MCP poisoning create more risk than a normal documentation issue?

A: Because the content is not just read by a person.

Q: What are the signs that an MCP-integrated workflow is too trusting?

A: Warning signs include unrestricted user-generated content flowing into agent context, registry reputation being used as the main trust signal, and the assistant being able to reach secrets or file systems without a separate content review step.

Practitioner guidance

  • Audit MCP content boundaries Classify every MCP source as documentation, instruction, or mixed content, then decide whether the agent should ever see raw user-generated text from that source.
  • Sanitize agent-fed registry content Strip or isolate Custom Rules, prompts, and other instruction-bearing fields before they can reach an AI assistant that also has file or network tools.
  • Restrict downstream tool authority Limit the IDE agent’s ability to read secrets, write files, and make network calls when the upstream content source is not fully trusted.

Bottom line: MCP poisoning turns trusted content delivery into a security problem because AI assistants can act on malicious instructions as soon as they ingest them.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →


This topic was modified 4 days ago by NHI Mgmt Group

   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 21568
 

MCP trust has become an identity problem, not just a transport problem: This incident shows that the dangerous asset is no longer only the tool connection, but the trust state attached to content moving through it. A registry can be reachable, popular, and still hostile if the server serves attacker-controlled instructions into an agent’s context. For practitioners, the control question shifts from access to provenance.

A few things that frame the scale:

  • 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.

A question worth separating out:

Q: How should teams respond when AI coding tools can ingest untrusted registry content?

A: They should separate content ingestion from action authority. That means restricting what the assistant can see, limiting what it can do after ingesting external text, and reviewing every MCP source that can inject rules or prompts. The goal is to stop untrusted content from inheriting trusted execution rights.

👉 Read our full editorial: Context7 MCP server poisoning exposes trust gaps in AI coding workflows



   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.