- Corelight found that an MCP server pinned to one release ran with 15 different sets of dependencies over five weeks, with no change to its configuration.
- The servers hold the credentials of the person who set them up, so any changed dependency runs with that access. Corelight reviewed 35 servers; 23 had such an install path.
- Freezing the environment stopped the drift in Corelight's lab, but someone must then own updates and scope each server's credentials down.
A version number names the package, not what sits beneath it
A pinned version feels like a sealed box. You know what is inside, and it stays that way. Corelight, a network security company, found that the seal can cover only the top layer.
Its researcher, working with an AI agent, noticed AI coding assistants running on an administrator's workstation in the company's lab. The assistants launched Model Context Protocol (MCP) servers, which let an assistant act on other tools for a user. Those servers held credentials for security tools and other administrative systems.
One server was set to run a specific release built from a specific commit. Across five weeks, Corelight counted 15 distinct sets of dependencies behind it. Twenty-three of its 69 packages changed versions. Nobody had edited the configuration.
How a pinned release drifted
The assistants launched each server through uvx. This tool fetches a Python package and runs it, all from a single line of setup. Corelight reports that it installed from the package's declared dependencies. It ignored the project's hash-pinned lock file, a list that fixes each package to an exact version and fingerprint.
As a result, about 60 packages beneath the server were looked up again on the Python Package Index (PyPI) each time the environment was rebuilt. The author had pinned seven direct dependencies exactly. The rest floated within allowed version ranges.
The assistant started this server 162 times in one week. Most launches reused a saved environment. Still, the saved builds numbered 19 for the same release and commit, spread over five weeks. That is a new one every couple of days. They produced 15 distinct environments. The changes touched the cryptography library, the JSON Web Token library and even the toolkit the MCP server itself is built on.
Corelight says the pattern was not limited to one server. Every server launched this way on that workstation showed it, whether the setup named a release tag, an exact PyPI version or a Git commit. Some vendors' setup instructions also start a proxy through npm with a "latest" tag, which asks the registry for the newest version at every start.
Why this matters more for AI agents
Corelight is clear that this is not a flaw in MCP. The cause lay in how each server's setup or configuration was written. The company reviewed 35 MCP servers, drawn from two vendor catalogs and its own lab. For 23 of them, the recommended install would fetch dependencies from a public registry rather than from a fixed list.
The stakes come from what the servers hold. Every dependency loads into the server's process and inherits its access. In one week, the endpoint data showed that workstation's servers opening over 1,600 connections to 11 management systems. These included the firewall and the SIEM, the system that collects security logs.
The servers also start without anyone running an install command. The assistant launches them each session, so the rebuild check runs more often than anyone notices.
Corelight lists past package hijackings. The Ultralytics PyPI releases of December 2024 carried a cryptominer and were live for about 12 hours. The Nx releases of August 2025 ran AI coding assistant tools on the victim's machine to hunt for secrets. A malicious release can be available for only minutes or hours. Corelight's point is that a setup which rebuilds every couple of days, with no human involved, has more chances to catch one.
The lesson here is that an AI agent is an administrator account whose parts nobody inventories. We audit people who hold such access. We rarely ask where their tools' code comes from.
What froze the drift, and what it costs
Corelight froze five servers. It locked each to one commit, installed it a single time from a hash-pinned lock file, and ran the installed program directly with update checks switched off. Over the next two weeks the servers started 457 times. At the end, every server's list of installed packages matched the list taken on install day. Startup also got faster, at about 2 seconds against a previous range of 4 to 11.
Freezing has a price. When Corelight froze one community server, 40 of its packages turned out to be older than the versions the launcher would have pulled that day. Some of those were security-sensitive. Pinning swaps silent drift for deliberate updates. Someone has to own them.
Corelight's James Lagermann, Director of Technical Alliances, says the pattern is not confined to the lab. He told Help Net Security: "100% of administrators that I've talked to were using at least one MCP Server with this issue." That is his own sample, not a measured rate.
Questions to put to your team
Ask which MCP servers run on administrator workstations and servers. Ask how each one is launched, and whether any entry uses uvx, npx or a "latest" tag.
Ask whether an installed package list is recorded for each server, and who compares it over time. Ask who owns re-locking on a schedule and reviewing what changed.
Ask whether each server has its own account with the least access its tools need. Corelight found some still using full-administrator gateway accounts.
A pinned label is a promise about one layer. Check the layers below it before you hand over the keys.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Corelight.
