MCP: compare dependencies across two restarts
A fixed server version can conceal changes in transitive dependencies. Compare the environment actually installed before accepting the next startup.
Lire en portugaisBy Pentesty
The finding and its limits
On November 10, 2026, Corelight described an MCP server whose unchanged commit produced 15 dependency sets over five weeks: 23 of 69 packages changed. The investigation began on an administrator workstation where no compromise was identified. The observed issue was a launcher rebuilding an environment without consuming the project’s locked dependency file, rather than an inherent MCP protocol flaw. This establishes code drift, not confirmed credential theft.
Find the installation the configuration actually runs
Start with the execution path of a server connected to a business system. Record its assistant configuration entry, launched command, working directory, final executable and account. Identify where environment preparation ends and service execution begins. This distinction lets the team assign each change to the right owner and point in time.
Compare that command with the approved installation procedure. A lockfile in a repository is useful evidence only when the procedure consumes it. Request an installation execution record, the resulting package inventory and the delivered artifact identifier. Recording only the application commit leaves the transitive dependency tree outside acceptance.
The uv documentation distinguishes keeping a lockfile current from synchronizing an environment. Turn that distinction into a requirement: preparation should reject unapproved changes, while operational startup should execute the prepared environment. Test how the project installs its components before mechanically changing launcher options.
Build a comparison that accounts for caching
Choose one server and two authorized test conditions: restarting the prepared environment and rebuilding it on an equivalent validation machine. Retain interpreter version, platform, package names and versions, approved file hashes and the effective command. Compare normalized sets so that listing order does not create artificial differences.
An unchanged restart is only one sample. A rebuild tests whether the same approved inputs produce the expected installation. For each difference, identify the package, the rule that allowed its selection and the responsible stage. Require a reproducible explanation before classifying the change as an attack or an authorized update.
Use network records to locate candidates and process events to connect them to the assistant and installer. A package-registry lookup should begin an investigation rather than establish that code changed. The installed inventory and the files actually executed provide the decisive evidence for this test.
Accept a complete artifact and test its functions
For Python installation, pip’s hash-checking mode requires dependency hashes and pinned requirements as well. Apply that principle to the entire approved artifact, including transitive components. A hash checks correspondence with selected bytes; deciding whether to trust those bytes still requires review of their origin and contents.
Record functionality separately: does the server start, negotiate its MCP session and expose the expected tools? Perform a read operation against test data and an operation that should be refused. Compare responses and records. A stable environment that has lost a required function also needs correction before acceptance.
Connect this check to PyPI release-file provenance assessment. These answer complementary questions: who published a file, and which set of files actually executed. Retain the approved identifier in the operational configuration and keep a usable earlier version available for recovery.
Decide when the dependency set may change
Assign an update reviewer and a window for rebuilding, comparing and promoting the next environment. Provide a separate route for urgent security fixes. Locking installation should make changes deliberate and traceable while keeping component maintenance active.
Give the service owner an acceptance package containing configuration, inventory, hashes, explained differences and functional results. Include the account used and reachable systems to prioritize any discrepancy. These records support a concrete decision: approve an update, correct the installation procedure or investigate unexpected execution.
Frequently asked questions
Is pinning the MCP server version enough?
Acceptance should cover the complete installation. Check which transitive versions were actually selected and whether the procedure consumes the approved lockfile, rather than relying solely on the server identifier.
Does PyPI access prove a compromise?
No. Treat contact as an investigation lead and correlate the process, installed files and observed change. Corelight did not identify a compromise on the workstation in its study.
Does an approved hash guarantee a safe package?
It verifies correspondence with the selected file. Origin assessment, review, testing and vulnerability monitoring remain decisions separate from the integrity check.
What evidence completes the assessment?
A reproduced installation with the expected inventory, required functionality preserved and differences explained. Record preparation and restart results, together with responsibility for the next update.
Sources and references
- Corelight: MCP server dependency research, November 10, 2026
- Astral: locking and syncing in uv
- pip: installs with required hash verification
Original Pentesty analysis, published November 11, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.