Today's MCP server CVE wave: SSRF and path traversal behind an agent tool

A series of CVEs affecting small MCP servers and tools was published on 9 August 2026. Two defect classes recur: server-side request forgery in URL-fetching functions and path traversal in functions that read or write workspace data. Each flaw has its own conditions, but their shared problem is architectural: an argument produced by a client or agent becomes a network address or system path without adequate boundary enforcement.

That matters more than the CVSS number alone. An MCP server commonly runs locally, so a record may receive a “local” vector. At the same time, a model may call its tool after reading an untrusted website, document or search result. A local API is not automatically under human control when an agent mediates the decision.

Four representative flaws published today

CVE	Component and range	Class	Status in the sources
CVE-2026-19328	Skill Ninja MCP Server 0.1.0	path traversal through workspacePath	version 0.1.1 is marked unaffected
CVE-2026-19336	spec-workflow-mcp 2.2.0–2.2.6	path traversal through categoryName	fixed in 2.2.7
CVE-2026-19337	mcp-google-search through 0.3.1	SSRF in read_webpage	a fixing commit exists; the record names no safe version
CVE-2026-19339	Alibaba Cloud DataWorks MCP Server 1.0.0–1.0.43	remote SSRF through a resource URI	the record names no fixed version

CVE-2026-19328 covers functions that install, update and remove skills and modify AGENTS.md. Manipulating workspacePath could take an operation outside the expected project. The 0.1.1 fix introduces trusted roots, resolves paths and rejects operations outside those roots.

CVE-2026-19336 concerns category names in the spec-workflow-mcp approval mechanism. Version 2.2.7 applies controls at two layers: the tool handler rejects separators and parent traversal, while the storage layer uses safe path joining. The project commit documents this defence in depth.

Two forms of SSRF

CVE-2026-19337 resides in the read_webpage tool of mcp-google-search. A controlled URL could direct a request toward resources reachable by the MCP host. The fixing commit restricts protocols to HTTP/HTTPS, resolves DNS, blocks private, loopback, link-local and multicast IPv4/IPv6 addresses, and disables automatic redirects.

CVE-2026-19339 affects ReadResourceRequestSchema in Alibaba Cloud DataWorks MCP Server through 1.0.43. The request.params.uri argument leads to SSRF, and the record classifies exploitation as remote. The CNA names no unaffected version and notes that the project had not responded to an earlier report. Here, egress restriction and disabling the tool until a fix appears matter as much as package-version monitoring.

SSRF in an agent tool may reach a localhost panel, private-network service, cloud metadata endpoint or API that trusts the MCP host address. This is environment-dependent potential impact; the CVEs do not establish that every target was reachable in every deployment.

Why “local” does not always mean “low priority”

In a conventional application, a local user must invoke the vulnerable function. In an agent system, the argument can emerge from several steps:

1. an agent retrieves an external document or page;
2. the content suggests a tool call and supplies an argument value;
3. the MCP client sends the call to a local server;
4. the server interprets the value as a URL or path with its process authority.

The CVE sources do not state that this chain was exploited. It is a Breachroad conclusion explaining why agent context should change prioritisation. A model is not a security boundary and cannot replace deterministic authorisation in the tool implementation.

CVSS describes the conditions for directly calling the affected component. An organisation must add context: who can influence prompts, whether calls are automatic, what files and networks the process can access, and whether a human must approve the operation.

Handling paths safely

Path validation should begin with an explicit trusted root. The application resolves both the root and candidate into canonical form, then verifies containment. It must account for Windows and POSIX separators, absolute paths, symbolic links and the time-of-check/time-of-use race.

Checking for .. alone is insufficient. A robust solution combines:

• a simple identifier instead of an arbitrary path in the tool schema;
• an operator-defined workspace allowlist that the model cannot change;
• safe join and canonicalisation APIs;
• minimum process privileges and mounts limited to required directories;
• separate approval for writing, deleting and changing files that control the agent.

Handling URLs safely

An http and https allowlist is only the beginning. A server should block loopback, private, link-local, multicast and other special ranges for IPv4 and IPv6, validate every redirect target and control DNS resolution. In cloud environments, a separate egress policy should block metadata and management networks even if application validation fails.

The safest interface does not accept an arbitrary URL. It may retrieve only a result from a preceding search operation, a resource identifier belonging to a defined provider or a domain on an approved list. Reducing tool expressiveness is often more effective than maintaining a growing exception list.

Building an MCP tool risk register

A list of server names and versions is insufficient because the same tool can have radically different impact in two clients. For every function, record its argument schema, permitted data sources, process identity, directories, egress policy, secrets, approval requirement and target systems. A separate field should show whether tool output returns to model context and can influence another call.

Next, label effects: public-data read, internal read, workspace write, process execution, configuration change or administrative operation. “Read” in a name does not always imply low impact—a URL read may send a request from a privileged network, while a file read may disclose a secret that enables writing elsewhere. Classification must describe the actual effect, not the function’s marketing name.

The team deciding to install and authorise the server should own the risk, not the model provider alone. An MCP vendor owns its code fix, but the organisation owns the decision to expose cloud metadata, a home directory or a production key to the process. Give each entry a review date because agent clients and enabled toolsets change faster than typical business applications.

Testing the real trust flow

A unit test calling a handler with hand-written JSON covers only the last step. An integration scenario should begin with untrusted content, pass through model choice, client policy, MCP transport and tool implementation, and end with an observable effect in a controlled resource. The objective is not to produce a working exploit; it is to prove that policy blocks a disallowed URL or path regardless of how the argument reached the call.

Measure at least the allow/deny decision, reason, run identity, human involvement and whether the effect matches declared scope. Negative testing matters as much as positive testing: a legitimate operation in an approved workspace should succeed, while a similar operation outside the root must fail without a partial write. For URLs, include DNS changes and redirects because validating only the initial string does not control the final connection destination.

Plan for teams using MCP

1. Inventory every MCP server, version, installation source and tool enabled in clients.
2. Update Skill Ninja MCP Server to 0.1.1 and spec-workflow-mcp to 2.2.7 or later.
3. For mcp-google-search, verify that the running artifact actually contains the fixing commit; do not infer that from a repository branch.
4. Disable or isolate ReadResource in DataWorks MCP until the project identifies a safe release.
5. Restrict MCP process egress and filesystem access independently of application patches.
6. Log the tool name, normalised argument, policy decision, user or agent run, and result without storing secrets.
7. Require human approval for writing, deleting, installing and accessing new domains.
8. Test indirect influence from untrusted content on a tool call, not only a manual invocation with valid JSON.

Facts versus Breachroad conclusions

The facts are today’s publication of the listed CVEs, the version ranges and mechanisms described by the CNAs, and concrete commits for three projects. Public records do not confirm a shared campaign or the compromise of named organisations.

Breachroad’s conclusion is that the series signals a maturing MCP ecosystem but also recurring debt in basic boundary implementation. AI security and secure-development training should cover the complete flow from untrusted content to system effect. An AI security assessment can map servers, tools, egress, workspaces, secrets and the points that require deterministic approval.