CVE-2026-81091 in mcp-use
Summary
by MITRE • 08/27/2026
The proxy middleware in mcp-use's inspector forwards requests to a destination the caller names. mountMcpProxy in libraries/typescript/packages/inspector/src/server/proxy/mcp-proxy.ts read the target from the X-Target-URL header or the __mcp_target parameter and proxied to it without inspecting the host, so loopback, link-local and private addresses were all accepted, as were names that resolve to them, and the validation was not reapplied to a redirect the destination returned. A caller could therefore make the server issue requests to addresses reachable only from the host it runs on and read the responses. The current code calls isSafeProxyTarget, which checks the resolved address against private, loopback and link-local ranges before proxying and bounds the number of redirects followed.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in the mcp-use inspector component represents a critical server-side request forgery flaw rooted in insufficient validation of outbound network connections. The core issue resides within the mountMcpProxy function located in libraries/typescript/packages/inspector/src/server/proxy/mcp-proxy.ts, which acts as a proxy middleware for forwarding requests to user-specified destinations. This mechanism allows callers to dictate the target endpoint by providing either an X-Target-URL header or a __mcp_target query parameter. The initial implementation failed to adequately sanitize these inputs, permitting the server to initiate connections to loopback addresses such as 127.0.0.1, link-local addresses like 169.254.x.x, and private network ranges including 10.x.x.x, 172.16-31.x.x, and 192.168.x.x. This lack of restriction effectively turns the vulnerable service into a pivot point for internal network reconnaissance or exploitation of services that are not exposed to the public internet but remain accessible from the host machine itself.
The technical severity is compounded by two specific deficiencies in the original code logic. First, the validation process did not account for DNS rebinding attacks where a domain name resolves to an internal IP address at the time of connection rather than at the time of request initiation. Second, and perhaps more critically, the security checks were not reapplied when the target server issued HTTP redirects. An attacker could provide a public URL that responds with a 302 redirect pointing to an internal service endpoint. Because the proxy middleware did re-validate the final destination after following the redirect chain, it would blindly forward the request and return the response from the internal resource back to the caller. This behavior allows for unauthorized data exfiltration from internal systems, such as cloud metadata services like AWS EC2 instance metadata or Azure managed identity endpoints, which are commonly targeted in SSRF attacks to steal credentials or access sensitive configuration data.
From a threat modeling perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically the variant involving bypassing validation through redirect chains and DNS resolution manipulation. In terms of the MITRE ATT&CK framework, this flaw facilitates the T1534 technique for Internal Network Discovery and potentially T1071 Application Layer Protocol if used to exfiltrate data over standard web protocols. The operational impact is significant because it allows an authenticated or unauthenticated user, depending on the surrounding access controls of the inspector interface, to interact with internal infrastructure that should be isolated from external influence. This can lead to full compromise of backend services, leakage of sensitive secrets stored in metadata endpoints, and further lateral movement within a compromised network segment if the proxy server has broader internal connectivity than intended.
The remediation strategy involves implementing robust input validation and strict egress filtering mechanisms. The current codebase has been updated to address these issues by introducing an isSafeProxyTarget function that explicitly checks the resolved IP address against known private, loopback, and link-local ranges before any network connection is established. This check must be performed after DNS resolution occurs but before the socket connects to ensure protection against DNS rebinding attacks. Furthermore, the implementation now bounds the number of redirects followed and re-validates the target URL at each step in the redirect chain. To further harden the system, it is recommended to implement allowlists for permitted outbound destinations where possible, utilize network-level controls such as firewall rules or security groups to restrict egress traffic from the proxy server, and ensure that all external-facing services operate with minimal privileges to limit the blast radius of any successful exploitation attempt.