AWS HealthLake MCP Pagination SSRF Could Exfiltrate Temporary Credentials — CVE-2026-15643
AWS has disclosed a server-side request forgery flaw in the open-source AWS HealthLake MCP Server. Before version 0.0.14, the pagination path could accept a crafted next_token that redirected a follow-up request to an attacker-controlled endpoint. AWS says a remote authenticated user could use the flaw to exfiltrate temporary AWS security credentials.
The issue is tracked as CVE-2026-15643 and AWS bulletin 2026-054-AWS, published July 14. The remediation floor is awslabs.healthlake-mcp-server 0.0.14; the repository currently identifies a later 0.0.16 version. Operators should upgrade rather than treating the server's --readonly option as a containment boundary.
A continuation token became an outbound-request primitive
FHIR search results can include a next link for another page. The vulnerable implementation surfaced too much of that link as caller-controlled continuation state and later followed it without proving that the destination was the expected regional HealthLake endpoint. In an MCP deployment, a value that looks like ordinary pagination metadata therefore crossed into URL selection.
This is a particularly consequential SSRF sink because HealthLake requests use AWS Signature Version 4. AWS states that exploitation could disclose temporary security credentials to an arbitrary endpoint. The affected caller still needed authenticated access to the MCP server, but it did not need permission to make the server contact an arbitrary host as a separate tool action: the outbound request was hidden inside a normal paginated operation.
The server connects AI assistants to HealthLake FHIR datastores, so the authority attached to its AWS role matters more than the label on the MCP tool. Stolen STS credentials remain governed by the role's IAM policy. A tightly scoped role limits what they can do; a broad role can turn one forged pagination response into access well beyond the original read operation.
The patch stops carrying URLs across the trust boundary
The merged fix no longer returns a continuation URL to the caller. It extracts the HealthLake page cursor and page size, packs them into a bounded opaque token, and reconstructs the next URL from trusted datastore, resource, patient, region, and count values on the server. URL-shaped and malformed tokens are rejected before an HTTP client is created.
The patch adds a second control at request signing. The SigV4 authentication helper can be given an expected hostname and refuses to sign when the request host differs, including wrong-region and deceptive suffix cases. That defense is important because input validation and URL construction can regress independently; the credential-bearing operation should still enforce its own destination scope.
Version history needs careful reading. The security fix was merged in early May as part of a broader pagination and error-handling change. The project's changelog was later corrected to state that 0.0.14, released May 5, was the first published package carrying the fixes; 0.0.12 and 0.0.13 were not published to PyPI. AWS's July bulletin makes 0.0.14 the authoritative public remediation floor.
Read-only mode does not reduce credential authority
AWS explicitly warns not to rely on --readonly as a security boundary. That flag is an in-process guard over mutating MCP tools; it does not alter the IAM policy attached to the server process. If temporary credentials leave the process, an attacker can call AWS APIs directly with every permission granted to the role, including permissions the MCP server chose not to expose as tools.
This distinction mirrors an earlier AWS API MCP Server path-control flaw: application-level tool restrictions are useful, but they are not substitutes for operating-system, network, or cloud-identity enforcement. The safest role is one whose policy remains acceptable even if the agent process is bypassed.
Defensive engineering guidance
- Upgrade to 0.0.14 or later. Confirm the installed Python distribution version in the environment that launches the MCP server, rebuild pinned containers or lockfiles, and restart long-running clients.
- Audit who could supply continuation state. Identify remote or shared MCP transports, authenticated users, agent workflows that process untrusted FHIR content, and logs containing suspicious URL-shaped or malformed
next_tokenvalues. - Rotate on evidence of exposure. AWS advises operators using role-based STS deployments to consider rotating affected role credentials when they suspect use of a vulnerable version. Also review CloudTrail for unexpected calls made under the role and egress telemetry for connections to unapproved hosts.
- Replace wildcard IAM resources. Scope the MCP role to required HealthLake actions and datastore resources. Separate read and mutation roles where workflows permit, and add explicit denies for unrelated services.
- Constrain egress. Permit the server to reach only required AWS endpoints and controlled infrastructure. Alert on direct internet destinations and cloud metadata addresses from the MCP runtime.
- Keep destination checks at the signing layer. Test pagination with attacker-controlled absolute URLs, alternate regions, redirects, encoded hosts, IPv6, and hostname suffix tricks. A signed client should refuse an unexpected host even if a higher-level validator fails.
- Treat continuation tokens as capabilities, not URLs. Store only opaque state, enforce length and character constraints, reconstruct destinations from server-owned configuration, and bind tokens to the original operation and tenant where relevant.
CVE-2026-15643 is a compact example of an agent-security boundary failure: an apparently low-risk data field selected where a privileged process sent an authenticated request. The durable fix is not a larger blocklist. It is to stop accepting destinations as continuation state, rebuild requests from trusted components, and make the credential signer independently refuse to cross its assigned host boundary.
Sources: