AWS HealthLake MCP Server SSRF Credential Exfiltration via Pagination Token

Technical Analysis

The MCP server processes a crafted next_token pagination parameter without validating that the resulting URL targets the expected AWS HealthLake FHIR endpoint, creating a classic server-side request forgery condition. An authenticated user (agent or human operator invoking the MCP tool) can supply a malicious next_token that causes the server to issue subsequent paginated requests to an actor-controlled server instead of AWS, and in doing so may transmit AWS temporary security credentials (e.g., SigV4 headers or bearer tokens) to that attacker-controlled endpoint. This crosses the tool-to-cloud-resource trust boundary: the MCP server acts as a credentialed intermediary between an AI agent and AWS HealthLake, and the flaw allows credential exfiltration outside of the intended AWS API surface. Once obtained, the attacker could reuse the temporary credentials to access other AWS resources permitted by the underlying IAM role, extending impact beyond the MCP server itself.

Affected Systems

awslabs.healthlake-mcp-server; protocols: MCP

Detection Signatures

• Outbound HTTP/HTTPS requests from MCP server host to non-AWS domains following pagination calls
• Unusual next_token values containing full URLs or non-standard hostnames
• AWS credential material (Authorization headers, X-Amz-Security-Token) present in requests to unexpected external domains
• MCP server logs showing pagination requests to endpoints outside *.healthlake.*.amazonaws.com
• Anomalous egress traffic correlated with HealthLake MCP tool invocations

Remediation Steps

1. 1

   Upgrade the MCP server

   Update awslabs.healthlake-mcp-server to version 0.0.14 or later, which validates pagination URLs against the expected HealthLake endpoint.

2. 2

   Restrict egress from MCP server hosts

   Apply network egress controls (allow-listing only AWS HealthLake and required AWS API endpoints) so pagination redirection to arbitrary hosts is blocked at the network layer.

3. 3

   Scope and rotate credentials

   Use least-privilege IAM roles for the MCP server, enable short-lived credentials, and rotate/revoke any credentials that may have been exposed prior to patching.

4. 4

   Validate server responses

   Ensure any custom or forked MCP server code strictly validates that continuation/pagination tokens resolve to trusted, pre-approved endpoints before reuse.

5. 5

   Monitor AWS CloudTrail

   Review CloudTrail logs for anomalous API calls using the MCP server's IAM role from unexpected source IPs following the vulnerability window.