Skip to content

ToolHive: SSRF in remote MCP server authentication discovery (host-side, bypasses container isolation)

Low severity GitHub Reviewed Published Jun 26, 2026 in stacklok/toolhive • Updated Jul 15, 2026

Package

gomod github.com/stacklok/toolhive (Go)

Affected versions

< 0.31.0

Patched versions

0.31.0

Description

Security Advisory: SSRF in remote MCP server authentication discovery

Severity: High. CWE: CWE-918. Affected: ToolHive through the latest release v0.29.3 and current main (HEAD b672d82f, 2026-06-12; re-verified 2026-06-14). FetchResourceMetadata and the discovery clients remain unguarded; no commits to pkg/auth/discovery or pkg/auth/remote address this. Originally identified at commit 05f11b53; all line references below are against HEAD b672d82f.

Summary

ToolHive's remote MCP server authentication discovery issues outbound HTTP requests to URLs the remote MCP server controls, with no private-IP or loopback guard and no restriction on redirects. ToolHive's core security model treats every MCP server as untrusted: the README states it "runs every MCP server in an isolated container" with "no local credentials," and it ships an egress proxy for network isolation. This discovery code runs host-side, in the ToolHive process, before and outside that per-server container sandbox. A malicious or compromised remote MCP server, added by a user through ToolHive's normal remote-server workflow, can therefore drive the ToolHive host itself to fetch arbitrary internal URLs, including cloud instance metadata, which bypasses the isolation ToolHive exists to provide. The user never selects a malicious target; they connect to a server they intend to use, and the attack is carried entirely in that server's discovery response.

ToolHive already establishes this boundary in code. ValidateRemoteURL (cmd/thv-operator/pkg/validation/url_validation.go:61) rejects internal IPs and known internal hostnames for the configured remote URL, and IsPrivateIP (pkg/networking/utilities.go:105) blocks RFC1918, link-local, 169.254.0.0/16, and loopback for outbound requests. The discovery clients below never call either guard, and the attacker-supplied resource_metadata URL and its redirect target are validated by neither. This is a deviation from the project's intended behavior, not a configuration choice by the operator.

The discovery clients are explicitly marked as trusted

The three outbound requests in this finding carry the maintainers' own gosec suppressions, each with a rationale comment asserting the URL is trusted:

  • discovery.go:165 -- resp, err := client.Do(req) // #nosec G704 -- targetURI is the MCP server endpoint URL from internal config
  • discovery.go:219 -- resp, err := client.Do(req) // #nosec G704 -- uri is built from the MCP server endpoint for auth discovery
  • discovery.go:931 -- resp, err := client.Do(req) // #nosec G704 -- URL is the OIDC well-known metadata endpoint

gosec's G704 is its SSRF taint-analysis rule: it flags exactly this pattern, an HTTP request whose URL flows from external input. The suppressions dismiss it on the premise that the URL comes "from internal config" or is "the MCP server endpoint." That premise is the bug. The targetURI is the remote MCP server endpoint, and the resource_metadata URL at line 931 comes straight from the server's WWW-Authenticate header (parsed by ParseWWWAuthenticate, discovery.go:293; resource_metadata extracted at discovery.go:315). Under ToolHive's own threat model the remote MCP server is untrusted, so "the MCP server endpoint" is attacker-controlled input, not internal config. A parallel cluster of //nolint:gosec // G706 (log-injection) suppressions on the same discovery responses (discovery.go:212, 221, 240, 268, 273, 280) shows the same data being treated as trusted throughout this code path. The maintainers saw the taint-analysis warning on these requests and waved it through on a trust assumption that contradicts the project's design.

Relationship to existing reports

This is distinct from issue #5135 (DCR resolver SSRF). #5135 is scoped to the DCR registration client, which already refuses redirects: client.CheckRedirect = errDCRRedirectRefused (pkg/auth/dcr/resolver.go:1281), with an in-code comment explaining that the wrapping client "refuses to follow HTTP redirects ... never for a redirected request whose URL the upstream chose" (resolver.go:1240). The discovery sinks below set no CheckRedirect and no private-IP guard, and are reached by a different path (the WWW-Authenticate resource_metadata discovery and the OIDC issuer discovery). The project demonstrably understands that redirect-following to an upstream-chosen URL is dangerous and guarded the DCR client against it; it left the discovery clients open. Fixing #5135 does not address them.

This is also distinct from GHSA-pph6-vfjv-vpjw (published 2026-06-04), which reports that the IsPrivateIP guard itself misses the IPv6 NAT64 ranges and so requires a NAT64/DNS64 gateway to reach internal addresses. The finding here does not depend on that guard's completeness: the discovery clients never call IsPrivateIP at all, so the host fetches 169.254.169.254 directly on any deployment, with no NAT64 dependency, and additionally follows redirects. The NAT64 fix to IsPrivateIP does not protect these clients because they do not use the guard.

Details

  1. remote.Handler.Authenticate calls discovery.DetectAuthenticationFromServer (pkg/auth/remote/handler.go:62), which issues a GET to the remote URL (client built at discovery.go:93 with no CheckRedirect; request at discovery.go:165).
  2. A 401 with WWW-Authenticate: Bearer ... resource_metadata="<url>" is parsed by ParseWWWAuthenticate (discovery.go:293), and the server-supplied resource_metadata value is stored (discovery.go:315).
  3. tryDiscoverFromResourceMetadata calls FetchResourceMetadata (handler.go:411, discovery.go:899). That client is built with no CheckRedirect and no private-IP dialer guard (discovery.go:916) and issues client.Do(GET <attacker url>) (discovery.go:931). FetchResourceMetadata requires the initial metadata URL to use HTTPS (discovery.go:911), but that check runs once on the supplied URL only; the client then follows the 302 Location to any scheme and any address with no re-validation.
  4. The OIDC issuer discovery path (.well-known/openid-configuration, .well-known/oauth-authorization-server) and the well-known existence probe (discovery.go:219) use the same unguarded client pattern.

Proof of concept (reproduced; recording available)

The attacker is the remote MCP server, not a URL the victim chooses. The victim connects to a server they intend to use (from a registry, a shared config, or a previously-legitimate endpoint that was later compromised) and the entire attack lives in that server's discovery response.

  1. A remote MCP server the victim has added responds to discovery with 401 WWW-Authenticate: Bearer realm="x", resource_metadata="https://<server>/.well-known/oauth-protected-resource" (HTTPS, so it passes the discovery.go:911 scheme check), and returns 302 Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> for that metadata URL. In the recording a loopback mock instance-metadata service stands in for 169.254.169.254 to avoid touching a real cloud account; the ToolHive code path is identical on a cloud instance, where the same redirect reaches the real metadata endpoint with no extra precondition.
  2. The victim runs that server the normal way: thv run <remote-mcp-server> --remote-auth. ToolHive performs the auth discovery automatically; the victim never targets an internal address.
  3. Observed: ToolHive's host process fetches the server-supplied resource_metadata URL and follows the 302 to the internal metadata path with no address filtering. The mock instance-metadata service received the request from ToolHive's Go HTTP client (Go-http-client/1.1) and returned a Metadata-Flavor header with IAM credentials, confirming the host follows the server-controlled redirect to an internal endpoint. The proven primitive is "the ToolHive host issues a GET to a server-controlled internal address and follows redirects with no filtering." On an instance with AWS IMDSv1 enabled that primitive returns IAM credentials directly, since IMDSv1 answers a plain GET. IMDSv2 (token via PUT plus a header) and GCP (Metadata-Flavor header) are not reachable by a redirect-following GET, so on those the reachable impact is the broader internal-GET surface: internal-only HTTP services, IMDSv1 where still enabled, link-local and RFC1918 endpoints, and reachability or error oracles.

Impact

A remote MCP server forces the host to issue arbitrary internal GET requests with redirect following and no address filtering. The host-side reach is the proven impact: internal-only services not exposed to the network, link-local and RFC1918 endpoints, and reachability or error oracles. On instances with AWS IMDSv1 enabled the request to 169.254.169.254 returns IAM credentials directly. Because the discovery runs in the host process and not in the per-server container, this is exactly the reach that the MCP server's own container sandbox is designed to deny.

Suggested fix

Apply the DCR client's hardening to the discovery clients: set CheckRedirect to reject cross-host or scheme-downgrade redirects, and wrap DialContext with the project's existing IsPrivateIP guard (pkg/networking/utilities.go:105) for FetchResourceMetadata, DetectAuthenticationFromServer, and the issuer-discovery client. Re-validating the redirect target, not only the initial URL, is the load-bearing part: the discovery.go:911 HTTPS check is bypassed by a 302 from an HTTPS metadata URL to an internal http address.

Verification status

The resource_metadata path was dynamically reproduced with a recording (against commit 05f11b53; the sink code at HEAD b672d82f is source-identical, with the unguarded clients and the three #nosec G704 suppressions confirmed present). The OIDC issuer discovery path is confirmed by source review against the same unguarded client and is in scope of the same fix.

References

@rdimitrov rdimitrov published to stacklok/toolhive Jun 26, 2026
Published to the GitHub Advisory Database Jul 15, 2026
Reviewed Jul 15, 2026
Last updated Jul 15, 2026

Severity

Low

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality Low
Integrity None
Availability None
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P

EPSS score

Weaknesses

Server-Side Request Forgery (SSRF)

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. Learn more on MITRE.

CVE ID

CVE-2026-58196

GHSA ID

GHSA-pr64-jmmf-jp54

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.