CVE-2026-16481 in MCP Toolbox for Databases
Summary
by MITRE • 07/27/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/27/2026
This vulnerability represents a critical server-side request forgery flaw in the googleapis/mcp-toolbox cloud-healthcare-fhir-fetch-page tool that demonstrates poor input validation and insecure credential handling practices. The issue stems from the tool's failure to validate or sanitize the pageURL parameter provided by clients, creating an environment where untrusted input directly controls outbound HTTP requests. When the tool processes this parameter, it automatically forwards authenticated requests without proper destination verification, leveraging the underlying transport layer that indiscriminately attaches Authorization: Bearer headers to all outgoing communications regardless of target host integrity.
The technical implementation of this vulnerability exposes a fundamental flaw in access control and request routing mechanisms within the application's authentication flow. The system operates under the assumption that all outbound requests are legitimate and secure, failing to implement destination validation or credential scope restrictions. This design oversight allows attackers to manipulate the tool into making authenticated requests to arbitrary external endpoints, effectively transforming the tool's legitimate authentication capabilities into an attack vector for credential exfiltration.
The operational impact of this vulnerability extends beyond simple data leakage to encompass serious compliance and security implications within healthcare environments. The exposure of OAuth tokens or service-account credentials can lead to unauthorized access to protected health information, potentially violating hipaa regulations and other healthcare data protection standards. Attackers could leverage these compromised credentials to access not only the primary FHIR data sources but also secondary Google Cloud Platform services that may contain additional sensitive data, creating a cascading security risk throughout the organization's cloud infrastructure.
This vulnerability aligns with CWE-918, which specifically addresses server-side request forgery vulnerabilities where applications fail to properly validate or restrict destination URLs in authenticated requests. The flaw also maps to attack techniques described in the MITRE ATT&CK framework under T1566 for server-side request forgery and T1078 for valid accounts exploitation. Organizations utilizing this tool face significant risk of credential compromise that could enable persistent access to cloud resources, potentially allowing attackers to maintain long-term presence within the environment while accessing sensitive healthcare data.
Mitigation strategies should focus on implementing strict input validation and destination verification mechanisms that prevent requests from being sent to external URLs without explicit authorization. The tool must be configured to validate all pageURL parameters against a predefined whitelist of trusted domains or implement proper credential scoping that restricts token usage to specific service endpoints. Organizations should also consider implementing network-level restrictions that prevent outbound connections to arbitrary external addresses, combined with monitoring and alerting for unusual authentication patterns that could indicate credential exfiltration attempts. Additionally, service-account tokens should be scoped appropriately to limit access to only necessary resources, reducing the potential impact of any successful exploitation attempts.