MCP Drift Check

ORYNVAL RESEARCH / 25 SEP 2026

How often did mutable MCP package refs appear in our public GitHub search sample?

On 25 September 2026 we ran documented GitHub code searches for public files whose exact basename was .mcp.json and that mentioned npx or npm exec. We fetched the commit-specific blobs and classified npm package selectors statically with the same MCP Drift Check logic.

232 of 259 parsed configs in this retrieved sample that contained npm/npx package references had at least one HIGH mutable reference. GitHub search ranking is not random and result caps constrain the sample, so this is not an ecosystem prevalence estimate.

Read methodology + snapshot Open sanitized datasetReproduce the method
2026-09-25 snapshotPASSIVE / PUBLIC DATA

RETRIEVED SEARCH SAMPLE

Evidence you can reproduce.

296  exact .mcp.json search hits after de-duplication295  configs fetched and parsed259  configs with npm/npx package references232  configs with at least one HIGH mutable reference392  npm/npx refs classified: 360 HIGH, 3 MEDIUM, 29 SAFE
NO SERVER EXECUTIONNOT PREVALENCE

Public evidence

The configs.

A mutable reference can resolve to newer package code while the config remains unchanged. That is a reproducibility and review-boundary signal, not proof of exploitation.

06

CZI Single Cell Data Portal

six mutable refs including bare @modelcontextprotocol packages, bare @playwright/mcp, bare @czi-sds/mcp, and @zeroheight/mcp-server@latest

View config
Follow-up issue

Interpretation

What this does — and does not — show.

Why is this not a prevalence estimate?

The sample comes from GitHub code search for npx / npm exec. Search ranking is not random, result counts are capped, and configs using other launch mechanisms are outside this census. The numbers describe only the retrieved sample.

What is the risk signal?

A bare package or mutable selector can resolve to a different version later, so a one-time security review may not describe the exact code executed in a future session.

Does pinning make a dependency safe?

No. Pinning makes the artifact reproducible. Provenance, code review, vulnerability analysis and runtime controls remain separate questions.

Why publish concrete examples?

Because evidence is more useful than a generic warning. Every example links to a public, commit-specific configuration so another engineer can inspect the claim independently.

TRY IT

Check your own MCP configuration.

The CLI is open source and zero-execution, with a GitHub Action and SARIF output for CI. The census script and sanitized dataset are public too. If the same signal appears in a production environment and you need help interpreting actual security impact, use private triage rather than posting sensitive configuration publicly.

Open MCP Drift Check Submit a Security Problem