EUVD-2026-49407
GHSA-qr8r-mqp7-36xx
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Authorized client can trigger the tool (PR:L) but impactful token leak needs specific config/pagination (AC:H); leaked token reaches other GCP services so S:C, pure confidentiality leak so C:H, I:N/A:N.
Primary rating from Vendor (google).
CVSS VectorVendor: google
Lifecycle Timeline
5DescriptionCVE.org
A Server-Side Request Forgery (SSRF) and credential exfiltration vulnerability exists in the cloud-healthcare-fhir-fetch-page tool of googleapis/mcp-toolbox.
The tool takes an unvalidated pageURL parameter from the client and issues an HTTP GET request to it using an authenticated client. The underlying transport automatically attaches an Authorization: Bearer header to every outbound request regardless of the destination host. An attacker can supply an arbitrary external URL to the pageURL parameter (either directly via the tool execution payload or implicitly via data-driven pagination tracking loops), leading Toolbox into sending its OAuth/service-account access token to an attacker-controlled listener. Depending on the configuration, this leaks either the end-user's token or the broader service-account access token (ADC), potentially exposing Protected Health Information (PHI) and secondary Google Cloud Platform services.
AnalysisAI
Server-side request forgery in Google's MCP Toolbox for Databases (googleapis/mcp-toolbox) versions 0.19.1 through 1.4.0 lets the cloud-healthcare-fhir-fetch-page tool dispatch an outbound HTTP GET to an attacker-chosen URL using an authenticated HTTP client, which automatically attaches an Authorization: Bearer credential to every request regardless of destination host - so supplying an arbitrary pageURL (directly in the tool payload or implicitly through a data-driven pagination loop) exfiltrates the caller's OAuth token or the broader Application Default Credentials service-account token to an attacker-controlled listener. Exploitation requires an attacker who can reach and influence the tool as an authenticated MCP client (CVSS PR:L) and depends on credential configuration for the more damaging service-account outcome, matching the vendor's high attack-complexity rating; no public exploit code has been identified at time of analysis (SSVC exploitation: none, Automatable: no) and EPSS is low at 0.25% (16th percentile), so this is a genuine-but-moderate credential-disclosure issue rather than an urgent one.
Technical ContextAI
The flaw is a classic CWE-918 server-side request forgery compounded by transport-level credential leakage. MCP Toolbox for Databases is Google's Go-based MCP server that exposes database and API sources as callable tools; the Cloud Healthcare source exposes cloud-healthcare-fhir-fetch-page, which follows FHIR search pagination by fetching a caller-supplied next-page URL. In the vulnerable code path (internal/sources/cloudhealthcare/cloud_healthcare.go), FHIRFetchPage accepted the pageURL string and passed it straight into http.NewRequestWithContext without validating scheme, host, or path. The authenticated client is built with Google's OAuth2 transport, which injects an Authorization: Bearer header on every outbound request irrespective of the destination host - the intended target is healthcare.googleapis.com, but the transport does not scope the token to that host. Distinct from a conventional SSRF where the attacker wants internal network reach, the primary impact here is credential exfiltration: an attacker only needs any reachable host they control to harvest the bearer token, and because pagination URLs can be derived from data returned by prior queries, a poisoned next-page link can trigger the leak through a benign-looking tracking loop rather than a direct tool invocation. The consequences scale with the credential in use: a per-user OAuth token limits blast radius to that user's data, while Application Default Credentials backed by a service account can expose Protected Health Information and secondary Google Cloud Platform services in the same project. The upstream fix in PR #3453 hardens the function by allowlisting only healthcare.googleapis.com and healthcare.mtls.googleapis.com, forcing https, path.Clean-ing and structurally validating the FHIR path (API version, projects/<project>, locations/<region>, datasets/<dataset>, fhirStores/<store>, fhir) against the configured source, and re-running validation inside httpClient.CheckRedirect to prevent bypass via redirect to an external host, capped at 10 redirects.
RemediationAI
Apply the upstream fix delivered in googleapis/mcp-toolbox pull request 3453 (https://github.com/googleapis/mcp-toolbox/pull/3453), which adds a host allowlist restricted to healthcare.googleapis.com and healthcare.mtls.googleapis.com, enforces the https scheme, structurally validates the FHIR path against the configured project/region/dataset/fhirStore, and re-validates every redirect target inside httpClient.CheckRedirect; note patch status as upstream fix available (PR/commit); released patched version not independently confirmed, so confirm with the vendor advisory (https://nvd.nist.gov/vuln/detail/CVE-2026-16481, EUVD-2026-49407, https://vuldb.com/vuln/383547) that your chosen build contains commit 0ce7496c4ba4 or later before treating the deployment as fixed. If an upgraded build is not yet available, disable or remove the cloud-healthcare-fhir-fetch-page tool from the Toolbox toolset configuration - the trade-off is that FHIR search pagination and large result-set retrieval via Toolbox stop working, so clients must page through the Healthcare API directly. Additional compensating controls, each with costs: run the Cloud Healthcare source under short-lived per-user OAuth tokens rather than Application Default Credentials so a successful SSRF leaks only one user's narrow-scope token instead of a broad service-account token (increases per-request auth plumbing and may require user consent flows); grant the source's service account the minimum FHIR read roles and no unrelated GCP permissions (does not prevent the leak, only limits post-leak reach); enforce egress filtering so the Toolbox process can only reach healthcare.googleapis.com and your database backends (blocks the exfiltration channel but risks breaking legitimate tools that call other Google APIs, and must be maintained as hosts change); and alert on Toolbox logs showing GET requests or redirects to hosts outside the expected allowlist along with any Authorization header reaching a non-Google destination (detection only - tokens leaked before the alert must be revoked). If token exposure is suspected, revoke and rotate the affected user tokens and service-account keys, and review Healthcare API and GCP audit logs for unauthorized PHI access.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today