MCP server dependency drift security deserves attention when a pinned release still installs new code. In a November 10, 2026 study, Corelight found one unchanged MCP server release running with 15 distinct dependency sets over five weeks. The finding describes a supply chain exposure in a lab, not a reported compromise.
Corelight traced the change to how AI coding assistants launched the server. The launcher installed from package metadata instead of the project’s hash-pinned lock file, so rebuilds could select newer packages. Teams need to know which code actually ran and what credentials it could reach. If an external provider supplies the MCP server, include its deployment path in third party risk management platform reviews; endpoint inventory establishes local exposure.
MCP server dependency drift security: what changed under a fixed release?
Corelight examined a community server pinned to a release built from a specific commit. Its seven direct dependencies were fixed, and its project published a hash-pinned lock file. The one-step launcher did not install from that lock, so transitive packages were resolved within their allowed ranges when the environment was rebuilt.
The launcher’s cache held 19 builds of that same release and commit over five weeks. Corelight found 15 distinct environments among those builds; 23 of the 69 installed packages changed version. Those numbers describe one observed server, while the broader review covered 35 servers from two vendor catalogs and Corelight’s lab.
- 35MCP servers reviewed across catalogs and a labSource: Corelight research, November 10, 2026
- 23Reviewed servers with a recommended install that could resolve dependencies afreshSource: Corelight research, November 10, 2026
- 15Distinct environments for one fixed release over five weeksSource: Corelight research, November 10, 2026
- 23 of 69Packages that changed version in that observed serverSource: Corelight research, November 10, 2026
Corelight says 23 of the 35 reviewed servers had recommended installations that could resolve dependencies again, either at launch or during installation or image builds. This is a review of selected servers and guidance, not a prevalence estimate for all MCP deployments. The authors also observed one commit-pinned server with 19 builds and 17 distinct environments.
How can the same release load different code?
The server’s source version and the installed dependency tree are separate inputs. A one-step launcher can reuse its cached environment on most starts, then rebuild when it finds newer allowed package releases. Corelight observed an ordinary launch install two dependencies released since the previous day’s build, without a configuration change.
That distinction matters because dependencies load in the MCP server’s process. Corelight’s administrator workstation used servers with credentials for management systems, so package code inherited the server’s reach. A compromised dependency could therefore matter even if the server’s own release identifier remained unchanged; Corelight did not report such a compromise in this case.
The pattern extended beyond the Python launcher in Corelight’s review. Some hosted-server setup instructions used an npm one-step proxy tagged “latest” to attach a local API token. Such a setup can fetch a newly published proxy version without a controlled deployment decision. The MCP server and tool access guide covers the broader permission model; this finding adds a check on the installed code behind that access.
What evidence shows a package actually changed?
Corelight used network records to find hosts contacting code hosts and package registries, then endpoint telemetry to identify the process and parent. A privileged workstation stood out because an AI assistant started a launcher that contacted GitHub and PyPI. The same process lineage led to MCP servers connecting to management systems.
Registry traffic alone is a lead, not proof of drift. A cached environment may perform a tag check without downloading a changed package. Corelight verified the change by comparing the launcher’s cache and endpoint file events, which recorded installed package versions across rebuilds. The team’s MCP scanner audit offers a separate view of tool behavior; package-version comparison answers a different question.
Corelight’s network hunt used DNS and TLS metadata to narrow the endpoint search. It warned that encrypted TLS client names can reduce visibility, and that forwarded DNS requests can make a resolver appear busy. Our reading is to prioritize privileged workstations and servers that fetch packages outside an approved update window, then confirm changes on the endpoint.
What should teams freeze and verify?
Corelight froze five MCP servers by installing from platform-appropriate, hash-pinned dependency files into dedicated environments. It launched the installed programs directly and disabled startup update checks. Across the next two weeks, the five servers started 457 times, and each installed package list matched its installation-day list.
- Inventory launch pathsRecord each MCP server, local proxy, runner, credential and reachable system.
- Compare installed codeCapture package names and versions, then compare them across restarts and approved updates.
- Freeze the deploymentUse a commit or image digest and a platform-matched hash-pinned dependency set.
- Verify operationCheck the MCP handshake, available tools, package list and launch-time network activity.
- Assign update ownershipReview and re-lock dependencies on a schedule; check new versions for known vulnerabilities.
The package-list comparison is the decisive verification. Corelight also saw launch-time registry connections disappear after the freeze, but cautioned that quiet network logs alone cannot prove it. A cached, unfrozen install can be quiet until its next rebuild.
Which risk remains after the freeze?
Frozen dependencies need deliberate maintenance. Corelight found 40 packages in its frozen community server were older than versions the launcher would have selected that day. An owner must review changes, update the lock on a schedule and check pinned versions for known vulnerabilities.
Credential scope remains a second decision. Corelight recommends a dedicated account or API client for each MCP server, with only the access its tools need. Read-only access and expiring tokens reduce the impact if package code is later compromised. The key question is what each server can reach from its host.
From August 15 through November 13, 2026, Brandefense Blackhole counted 15 dark-chat posts matching “Corelight.” The measured unit is posts matching a company-name query, which may include unrelated discussion. This count does not establish an MCP incident, malicious package delivery or exploitation. Teams should base their local decision on the installed package inventory and credential scope.
Frequently Asked Questions
Does pinning an MCP server release pin its dependencies?
Not necessarily. Corelight observed a fixed release whose launcher ignored the project lock file and resolved transitive packages again during environment rebuilds.
Does a connection to a package registry prove dependency drift?
No. Corelight says a cached launcher may only check a tag. Compare installed package versions, cache records or endpoint file events to establish a change.
What should teams verify after freezing an MCP server?
Verify that the server still completes its MCP handshake and offers the expected tools. Compare installed package lists across starts and review endpoint and network records as supporting evidence.
