CVE-2026-19339: Alibaba DataWorks MCP Server SSRF Flaw

CVE-2026-19339 Overview

CVE-2026-19339 is a Server-Side Request Forgery (SSRF) vulnerability affecting the Aliyun alibabacloud-dataworks-mcp-server project up to version 1.0.43. The flaw resides in the ReadResourceRequestSchema function within src/resources/initResources.ts. An authenticated remote attacker can manipulate the request.params.uri argument to coerce the server into issuing arbitrary outbound requests. The project maintainers were notified through a public issue report but had not responded at the time of disclosure. The vulnerability is classified under CWE-918: Server-Side Request Forgery.

Critical Impact
Remote attackers with low privileges can abuse the MCP server to reach internal network resources, cloud metadata services, or unintended endpoints, potentially exposing sensitive information across an Alibaba Cloud DataWorks integration.

Affected Products

Aliyun alibabacloud-dataworks-mcp-server versions up to and including 1.0.43
Model Context Protocol (MCP) integrations built on the affected server
Alibaba Cloud DataWorks workflows consuming the vulnerable MCP resource handler

Discovery Timeline

2026-08-09 - CVE-2026-19339 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-19339

Vulnerability Analysis

The vulnerability exists in the resource-loading path of the Model Context Protocol (MCP) server. When a client submits a ReadResource request, the handler defined in src/resources/initResources.ts reads the request.params.uri value and uses it to fetch a resource. The URI is not sufficiently validated or restricted to an allow-list of expected schemes and hosts.

An attacker who can send MCP requests to the server can substitute a crafted URI targeting internal HTTP services, cloud instance metadata endpoints, or loopback addresses. The server then executes the request under its own network identity and returns responses to the caller. This creates an SSRF primitive suitable for reconnaissance of internal networks and potential credential retrieval from metadata services.

Root Cause

The root cause is missing input validation on the uri parameter consumed by ReadResourceRequestSchema. The handler treats any client-supplied URI as trusted and issues the outbound fetch without checking scheme, host, or destination address. There is no network egress boundary enforced within the resource resolution logic, so the process can reach any host reachable from the server.

Attack Vector

Exploitation requires network access to the MCP server and low-privilege authentication. A remote actor sends a ReadResource request in which request.params.uri points to an attacker-chosen destination, such as http://169.254.169.254/latest/meta-data/ for cloud metadata or an internal service URL. The server performs the request server-side and returns the fetched content, exposing data that should not be reachable from outside the trust boundary. No user interaction is required.

Because no verified proof-of-concept code is publicly available, refer to the VulDB entry for CVE-2026-19339 and the GitHub Issue Tracker for further technical context.

Detection Methods for CVE-2026-19339

Indicators of Compromise

Outbound HTTP requests from the MCP server process to internal RFC1918 addresses, 127.0.0.1, or cloud metadata endpoints such as 169.254.169.254.
MCP ReadResource requests containing uri values with unexpected schemes (file://, gopher://) or non-DataWorks hostnames.
Anomalous spikes in resource-fetch latency or response sizes originating from initResources.ts request handling.

Detection Strategies

Log all MCP requests with the raw request.params.uri value and alert on URIs that resolve to internal, link-local, or metadata IP ranges.
Correlate MCP server egress traffic with the destination allow-list expected for DataWorks integrations; flag deviations for review.
Deploy application-layer detections that parse MCP JSON payloads and match against SSRF payload patterns.

Monitoring Recommendations

Forward MCP server logs and network flow data into a centralized analytics platform for correlation across host and network telemetry.
Enable egress DNS logging on hosts running the MCP server and alert on lookups to metadata service hostnames.
Track process-level network connections from the Node.js runtime hosting alibabacloud-dataworks-mcp-server and alert on new outbound destinations.

How to Mitigate CVE-2026-19339

Immediate Actions Required

Restrict network access to the MCP server so only trusted DataWorks clients can reach it.
Place the MCP server behind an egress proxy that blocks requests to RFC1918, loopback, and cloud metadata addresses.
Remove or disable IMDSv1 on cloud instances hosting the server and require IMDSv2 with hop-limit enforcement.
Audit recent MCP request logs for suspicious uri values and investigate any that reference internal endpoints.

Patch Information

No vendor patch has been published at the time of writing. The maintainers of aliyun/alibabacloud-dataworks-mcp-server were notified through the GitHub Issue Tracker but had not responded. Monitor the project repository for updates beyond version 1.0.43.

Workarounds

Implement a URI allow-list in a reverse proxy or gateway in front of the MCP server, permitting only known DataWorks resource hosts.
Enforce scheme validation at the network layer to drop non-HTTPS requests originating from the MCP server process.
Run the MCP server in a network segment with no route to metadata services or internal management planes.

bash

# Example egress restriction using iptables to block metadata service access
iptables -A OUTPUT -m owner --uid-owner mcp-server \
         -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner mcp-server \
         -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner mcp-server \
         -d 10.0.0.0/8 -j REJECT