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.
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.
If one is found, it’s updated the next morning, with a change log, and for the 23 public MCP servers that I found, I notified the maintainers and/or services that share them.
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; that cadence matters because a hijacked release can be live for only minutes or hours.
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.
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.
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.
Corelight froze five servers: pinned to a commit, installed once from a hash-pinned lock file, launched directly, update checks off.
What happened
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.
What changed
If one is found, it’s updated the next morning, with a change log, and for the 23 public MCP servers that I found, I notified the maintainers and/or services that share them.
Who is affected
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.
Why it matters
Code that slips into any of their dependencies runs with that access; that cadence matters because a hijacked release can be live for only minutes or hours.
Technical details
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.
Response
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.
Corelight reviewed 35 MCP servers from two vendor catalogs and its lab.
What security teams should do
Twenty-three had a recommended install that would pull dependencies from a public registry on every launch, or on each install or image build.
What to watch next
Watch for revised vendor guidance, fixed versions and mitigation updates.