[AVE] New class: mcp-resource-path-traversal (content layer)

[chaksaray]

Before you open this issue

• I have searched the registry at ave.bawbel.io and the records/ directory
• This is a genuinely distinct behavioral class, not a variant of an existing record
• I have a citable primary source (CVE, paper, disclosure, or working PoC)

---

Behavioral fingerprint

An MCP resource or file-handler tool's own path-validation logic fails to normalize or reject directory-traversal sequences (../, encoded variants) in a caller-supplied path parameter, allowing the tool to read or write files outside its configured/declared scope — including credentials, SSH keys, or unrelated protected endpoints.

Why this is a new class, not a variant

Checked against AVE-2026-00022 (Privilege Escalation - Scope Creep): "Component instructs the agent to access files, APIs, databases, or systems that were not declared in the component's manifest." That record is content-layer — a skill's text instructs the agent to ask for out-of-scope resources, and detection is prompt-content scanning.

This candidate is a CWE-22 flaw in a resource/file handler's own path-validation code, triggered by a parameter value with no instruction content involved at all — the same distinction as the command-injection candidate filed alongside this one (code vulnerability vs. prompt-driven overreach), and the same detection-method split (SAST path-validation pattern review vs. content-layer scanning).

Primary source

Three independently NVD-confirmed CVEs, verified by direct fetch:

• NVD CVE-2026-11720 — Google MCP Toolbox for Databases, HTTP tool URL builder, CVSS 9.3 (CVSS 4.0). Dot-segment (../) sequences are normalized during URL resolution, letting an unauthenticated attacker escape the configured path scope (e.g. /api/v1/users → /admin/secrets) using the toolbox's own configured credentials.
• NVD CVE-2025-66689 — Zen MCP Server < 9.8.2, CWE-22/CWE-552, CVSS 6.5. is_dangerous_path() uses exact string-match blacklisting, bypassable via subdirectory traversal to read SSH keys and API credentials.
• NVD CVE-2026-15138 — tumf mcp-text-editor ≤ 1.0.2, CWE-22, _validate_file_path improperly handles the file_path parameter.

Additional context (not independently re-verified, cited via search): the Vulnerable MCP Project database reportedly tracks 50+ known MCP vulnerabilities with 13 rated critical, and reports 82% of ~2,600 surveyed MCP file-operation implementations as traversal-prone — supports this being a systemic pattern, not an isolated bug, though I have not fetched that database directly to confirm the exact figures.

Proposed record skeleton

attack_class:        Tool Abuse - Resource Path Traversal  (or Supply Chain - MCP Resource Path
                      Traversal; naming open to discussion)
severity:             CRITICAL (est., worst documented case CVE-2026-11720 CVSS 9.3); typical
                      individual instances score MEDIUM (CVE-2025-66689: 6.5) — severity is highly
                      dependent on what the traversal reaches
owasp_mcp:            [MCP02, MCP07]   (MCP02 = Privilege Escalation via Scope Creep — matches the
                      Google Toolbox CVE's own description, "escape the configured path scope";
                      MCP07 = Insufficient Authentication and Authorization, secondary)
owasp_asi:            (none proposed — TBD during implementation)
mitre_atlas:          none — classic CWE-22, outside ATLAS's ML-adversarial-technique scope
detection_layer:      content   (static scan of the tool's own path-handling source code)
detection_stage:      static_detection
evidence_basis_engines: [semgrep, pattern]

Real-world evidence

Three independent CVEs (2026-11720 CVSS 9.3, 2025-66689 CVSS 6.5, 2026-15138) across three different MCP server implementations, one from Google's own MCP Toolbox. Real, disclosed — pushes THM toward 1.0 in AIVSS scoring.

Indicators of compromise

• Path-validation function uses exact string-match blacklisting instead of canonical-path resolution and containment checking (e.g. checking startswith() against a denylist rather than resolving to a real path and verifying it stays under a configured root)
• A file-path or resource-URI parameter is passed to a file-open/read/write call without prior normalization against a configured root directory
• ../ or URL-encoded traversal sequences (%2e%2e%2f) accepted unmodified in a resource URI or file-path parameter

Researcher

Bawbel Security Research Team (research-new-attack-classes skill run, 2026-07-10)

[chaksaray]

Implemented as AVE-2026-00053 (commit 54d1015 on vendor-neutral, not yet merged to main).

• Record, detection rule (rules/pattern/AVE-2026-00053.py), and positive/negative fixtures all in place
• python scripts/validate_records.py clean, pytest tests/ -x -q green (106 passed)
• Decision 1 applied consistently with AVE-2026-00052: detection_layer: content

AIVSS landed at 6.3/MEDIUM (not the issue's original CRITICAL-worst-case estimate) -- this is for the general behavioral class, not any single cited CVE. cvss_base (8.5) is weighted toward confidentiality impact since none of the three cited CVEs demonstrate a write-capable traversal instance. The record's aivss.notes explicitly says a scanner may reasonably score an individual finding higher when the specific traversal target is known to reach something sensitive -- matching how CVE-2026-11720 itself scored 9.3 for a credentials-reachable instance specifically.

Rule passed both fixtures on the first attempt and held up against four additional safe near-misses I stress-tested afterward (os.path.join, an unrelated startswith check, a single-interpolation URL, a pathlib resolve+containment pattern).

Leaving open until merged to main.