Corelight: a pinned MCP server ran 15 different dependency sets
Pinning an MCP server's version does not pin the packages it depends on, Corelight reports after watching one server rebuild for five weeks.
· Corelight · Research by James Lagermann
Corelight reports that MCP servers started with one-step runners such as uvx and npx resolve their dependencies again on every rebuild, so one server pinned to a single release and commit ran 15 distinct dependency sets in five weeks.
01What happened
Corelight published the study on 10 November 2026, written by James Lagermann, its Director of Technical Alliances. The team watched the MCP servers configured on an administrator workstation, then reviewed the recommended install for 35 servers drawn from two vendor catalogs and its own lab. Corelight also published the network and endpoint steps it used to find the pattern, and a freezing procedure it then tested.
02How it works
One-step package runners, uvx for Python and npx for npm, rebuild a server's environment from public registries, and each rebuild resolves the dependency versions again. A pin names the server's release or commit, not the versions of the packages underneath it, so new code arrives with no configuration change and no visible version bump. Because an MCP server loads its dependencies into its own process, a replaced package runs with the server's credentials and reach.
03Who is affected
Hosts that start MCP servers through uvx, npx or an @latest tag are in scope, and Corelight singles out servers, jump hosts and administrator workstations, where these servers often hold credentials for firewalls, SIEMs and sensor management. Of the 35 installs Corelight reviewed, 23 resolved dependencies fresh from a public registry. The measured counts for its own lab server are in the table below.
04What to do
Pin each server to a commit, install it from a hash-pinned lock file into a dedicated environment with hash checking, launch the installed server directly and turn off startup update checks. Corelight reports that five frozen servers then started 457 times over two weeks with identical package lists, so name an owner for scheduled re-locking and vulnerability review, because freezing also holds old code in place.
Questions people ask
- Does pinning an MCP server version stop its dependencies from changing?
- Pinning an MCP server to a release tag or a commit does not hold its dependencies still, Corelight reports. One-step runners such as uvx and npx resolve the whole dependency tree again whenever they rebuild the environment, so a server pinned to one commit ran 15 distinct dependency sets in five weeks. Hash-pinned lock files and a frozen install are what stop the drift.
- How can I tell whether my MCP servers rebuild from a public registry?
- Corelight starts from network evidence: find the hosts that query GitHub, PyPI and npm domains, then confirm with TLS server names and with process attribution from endpoint data. Launcher sessions appear as short bursts of roughly 24 KB within about three seconds of each start. Corelight treats registry contact as a lead only, and verifies by reading the installed package list on disk.
- What does freezing an MCP server install cost?
- Freezing moves a server to a hash-pinned install, which stops silent dependency changes but also pins older code. Corelight reports that 40 packages in its community server lagged behind what the launcher would have pulled, so someone has to own scheduled re-locking and vulnerability review. Frozen servers started faster in its tests, in about two seconds rather than four to eleven.
Sources 3 links, all fetched
- 1corelight.comCorelight Research
- 2corelight.comMCP Network Security
- 3jfrog.comJFrog mcp-remote RCE