MCPSafe.io
RegistryThreatsMethodologyDocsPricingScanSign in
MCPSafe.io

Security checks for MCP servers — public packages and private repos, fast or deep.

Legal

Privacy PolicyCookie PolicyTerms of ServiceSecurity disclosure

Resources

State of MCP SecuritySupportSystem statusMade in Germany 🇩🇪

© 2026 MCPSafe. All rights reserved.

GDPR — Privacy Policy
← Threat Catalog

Configuration & Environment

Vulnerable or unpinned dependencies

HIGHAIVSS 7.5CWE: CWE-1104OWASP: LLM03Agentic: T13Rule: MCP-072

Dependencies declared in `requirements.txt` or `package.json` that are either left unpinned (`>=` or no version) or pinned to a version with a known CVE — so the MCP server inherits someone else's vulnerability.

What it is

Every MCP server is also a dependency graph. An unpinned dependency (`requests>=2`) means the resolved version depends on when and where the package is installed — your audit of one install does not generalise to the next. A pinned but vulnerable version (say, `requests==2.19.1` with its known redirect flaw) means every install ships the vulnerability on purpose. Both patterns turn a server author's local environment into a liability for every downstream agent.

Why it matters for MCP

MCP packages are installed by end-user agents on short notice and rarely audited after install. Unlike a web backend with a quarterly dependency review, an MCP server installed today is likely to be invoked on production data tomorrow. A vulnerable transitive dependency (pickle-based config loader, XML parser with XXE) is reachable from any tool call that touches untrusted input.

Vulnerable example

example.py
1
# requirements.txt
2
requests               # unpinned — resolves differently on every install
3
pyyaml>=3.0            # range allows the unsafe 3.13 era
4
flask==0.12.2          # pinned, but known RCE chain (CVE-2018-1000656 adjacent)
5
jinja2                 # transitive; unpinned

Secure example

example.py
1
# requirements.txt
2
requests==2.32.3      # latest stable, no open CVEs
3
pyyaml==6.0.2         # post yaml.load() hardening
4
flask==3.0.3
5
jinja2==3.1.4
6
7
# Regenerate via `pip-compile --upgrade` on a cadence.
8
# In CI, run `pip-audit` and fail on HIGH or CRITICAL findings.

How MCPSafe detects this

We parse `requirements.txt`, `pyproject.toml`, and `package.json`, flag any declaration without an exact-version pin (`==x.y.z` for Python, non-caret non-range for npm), and cross-check pinned versions against our mirror of GitHub Advisory Database / PyPI safety DB — any match emits a finding annotated with the CVE.

See the full threat catalog for every documented detection.

Framework alignment

OWASP LLM Top-10 (2025)
LLM03 — Supply Chain
OWASP Agentic AI Top-10
T13 — Rogue Agents
AIVSS v0.5
7.5 (HIGH)AIVSS:1.0/S:HIGH/AV:N/AU:L/BR:H/CD:I

Illustrative CVEs

CVEs of the same CWE class. Not MCP-specific, but exemplify the failure mode MCPSafe detects.

  • CVE-2023-4863 — libwebp heap overflow — transitive dep across Electron/Chromium stacks

Further reading

  • CWE-1104: Unmaintained Third-Party Components
  • pip-audit
  • GitHub Advisory Database

Scan an MCP server for this issue

MCPSafe runs this check — and every other rule in the catalog — on any MCP server you paste in.

Scan now