Security teams using AI code assistants may unintentionally reveal their highest-level credentials, thanks to a weak link in some Model Context Protocol (MCP) server setups. A new study has uncovered how MCP servers can dynamically update their underlying dependencies, allowing attackers who compromise a single package to gain access to administrator credentials and API tokens without needing direct access to the server itself.
How Supply Chains for MCP Servers Break Down
MCP servers enable AI assistants to interact with tools such as firewalls, SIEM systems, and cloud consoles, often carrying the same permissions as the users who install them. A recent incident involving a malicious MCP server in the wild confirms how dangerous these setups can become when dependency updates aren’t strictly managed.
Corelight’s research, published on November 10, 2026, examined dozens of MCP server environments and found a pattern: administrators frequently use a tool called uvx to launch servers using pinned main packages. However, while the top-level package might reference an exact release or Git commit, its dependency chain isn’t locked down, allowing hundreds of secondary packages to be fetched freshly from public registries like PyPI or npm during environment rebuilds. One example saw over 60 dependencies reset during routine rebuilds, including core libraries like cryptography. Even though there was a hash-locked file, the launcher ignored it, resulting in 15 distinct dependency combinations over 19 rebuilds.
Why This Drift Matters
If any dependency shares the same execution environment as the MCP server, it gains access to everything the server can access—including sensitive credentials and internal files. Attackers can exploit weak points such as compromised maintainer accounts or supply chain events to insert malicious updates masquerading as legitimate ones. Previous incidents involving tools like Ultralytics, xz Utils, and a worm dubbed Shai-Hulud illustrate how stolen tokens and hijacked packages can lead to credential and API key exfiltration. In one wave monitored in June 2026, six versions of malicious releases were live for less than half an hour each.
Fixes and Detection Strategies
The good news: organizations can take concrete steps to protect themselves. Freezing the build environment by pinning every dependency—including indirect ones—is essential. That means installing directly from a hash-locked lock file, running MCP servers manually rather than via auto-rebuilding launchers, and disabling any automatic update checks.
Corelight tested these recommendations by locking down five MCP servers over two weeks. After 457 restarts, none of those servers had any package drift. Other precautions include giving each server its own least-privileged account, assigning a named owner to updates, and conducting regular reviews. Indicators of compromise (IoCs) include domains common in supply chain malware—such as GitHub, raw.githubusercontent.com, PyPI, npmjs.org—and unusual build behavior whenever these are contacted.
These vulnerabilities stem not from MCP itself, but from how it’s often deployed today. Out of 35 MCP servers audited, 23 used install methods that pulled dependencies freshly from public sources without locking down downstream packages.
Analytical Takeaway: The rise of AI assistants and MCP servers promises increased automation and efficiency—but with that comes elevated risk when supply chain hygiene is ignored. What this study shows is that even one overlooked package in the chain can create a breach opportunity. Enterprises should treat dependency drift like any other threat vector: review build pipelines, enforce strict version pinning, prepare to audit every indirect dependency. What to watch: open-source projects and dev tooling that assume safe dependency trees—the next supply chain attack might start deep in the chain, not at the surface.
