Your pinned MCP server may not be as pinned as you think
An MCP server configured to run one fixed release on an administrator’s workstation ran with 15 different sets of dependencies over five weeks, with its configuration untouched. James Lagermann, Director of Technical Alliances at Corelight, found the drift in his company’s lab. Twenty-three of the server’s 69 packages changed versions, including the cryptography library, the JSON Web Token library and the MCP software development kit itself.
MCP (Model Context Protocol) servers let AI coding assistants act on other tools for a user, so they often hold that user’s credentials. On this workstation, the servers made more than 1,600 connections in a week to 11 management systems, including the firewall, the SIEM and sensor management. Code that slips into any of their dependencies runs with that access.
The pin didn’t hold
The assistants started their servers with uvx, a launcher that downloads a Python package and runs it from one line of configuration. Each entry named an exact release tag, PyPI version or Git commit. For one community server, the launcher installed from the package’s declared dependencies and skipped the project’s hash-pinned lock file, so the roughly 60 packages underneath were resolved fresh from the Python Package Index whenever the environment was rebuilt. Pinning a package’s version doesn’t necessarily pin the packages it depends on.
The assistant started one server 162 times in a week. Most launches reused a cached environment, but the cache still held 19 builds of the same release and commit, about one every couple of days. That cadence matters because a hijacked release can be live for only minutes or hours. In June 2026, a Shai-Hulud worm variant on PyPI hit MCP-themed packages and went after AI coding assistant keys.
The same pattern in the field
Corelight reviewed 35 MCP servers from two vendor catalogs and its lab. Twenty-three had a recommended install that would pull dependencies from a public registry on every launch, or on each install or image build.
Lagermann told Help Net Security he sees the same thing in the field. “I have seen the same pattern in customer environments and in other real-world deployments. So far, 100% of administrators that I’ve talked to were using at least one MCP Server with this issue.”
Freezing works, and someone has to keep it current
Corelight froze five servers: pinned to a commit, installed once from a hash-pinned lock file, launched directly, update checks off. Over the next two weeks the five were started 457 times, and each one’s installed package list matched the list recorded on install day.
Frozen code ages. When the team froze one community server, 40 of its packages were older than what the launcher would have pulled that day, some of them security-sensitive. Asked how often to re-lock, Lagermann said: “I would recommend following the MCP maintainers’ recommendation for updates. The MCP Servers I maintain are reviewed nightly for vulnerabilities. If one is found, it’s updated the next morning, with a change log.”
“For the 23 public MCP servers that I found, I notified the maintainers and/or services that share them. As a result, one company that hosts an AI agent exchange has updated its security review processes to evaluate submissions for this issue. In another case, the vendor is completely repackaging their MCP server,” Lagermann said.
Any MCP entry started by a Python or npm package runner, or tagged “latest,” can resolve new code from a public registry the next time an assistant opens a session. On Corelight’s workstation, the server’s version number stayed the same through all 15 environments.
Download: The IT leader’s guide to AI code sprawl
