Cloud Security Wire
AWS Azure GCP RSS
AWS CVE Analysis high

CVE-2026-15643: SSRF in AWS HealthLake MCP Server Leaks Temporary AWS Credentials

A pagination-handling flaw in awslabs.healthlake-mcp-server lets an attacker redirect requests to a malicious endpoint and capture STS credentials via a crafted next_token parameter. Here's how it works and how to lock down MCP servers touching AWS APIs.

By Cloud Security Wire · ·
#cve-2026-15643#mcp#ssrf#aws-healthlake#credential-theft#iam#ai-agents#sts
High Severity

This issue has been assessed as high severity. Review affected configurations immediately.

AWS published a security bulletin on July 14, 2026 disclosing CVE-2026-15643, a server-side request forgery (SSRF) vulnerability in awslabs.healthlake-mcp-server, the Model Context Protocol (MCP) server AWS ships to let AI agents query Amazon HealthLake. Versions before 0.0.14 fail to validate that pagination URLs actually point back to the HealthLake API, which lets an authenticated attacker redirect a downstream request to infrastructure they control and capture the caller’s temporary AWS credentials in the process. NVD assigns it CVSS 3.1 7.3 (High) and CWE-918 (Server-Side Request Forgery); the CVSS 4.0 score comes in at 9.2 (Critical), reflecting how directly the flaw leads to credential exposure.

This is the latest in a growing pattern: MCP servers wired into AWS SDKs inherit the IAM permissions of whatever principal is running them, and a single unvalidated URL parameter is enough to turn that trust into an exfiltration channel.

How the flaw works

awslabs.healthlake-mcp-server exposes tools that let an MCP client (an LLM agent) list and paginate through HealthLake FHIR resources. Like most paginated APIs, list operations return a next_token that the client submits on the next call to fetch the following page.

The vulnerable code treated the next_token value as an opaque continuation string, but under the hood it was constructed from — and partially trusted as — a URL. Because the server never verified that the resolved URL still pointed at the expected healthlake.<region>.amazonaws.com endpoint, an attacker who could influence the next_token (directly, or via a manipulated first response) could redirect the server’s follow-up HTTP call to an arbitrary attacker-controlled host.

Since the MCP server process authenticates to AWS using the credentials of the IAM principal it runs as (an execution role, an instance profile, or a developer’s assumed role), redirecting an outbound call is enough to leak the Authorization headers — and with them, the temporary access key, secret key, and session token — to the attacker’s listener. Those STS credentials are then usable for as long as they remain valid, against whatever the underlying role is permitted to do.

AWS credits researcher Marios Gyftos with the finding.

Why this matters beyond HealthLake

The specific service is HealthLake, but the vulnerability class applies to any MCP server (or any tool-calling agent, for that matter) that:

  • Makes outbound HTTP calls using pagination tokens, redirect URLs, or webhook callbacks supplied in a prior response
  • Runs with a real IAM role rather than a scoped-down, credential-less sandbox
  • Doesn’t pin or allowlist the destination host before dereferencing a “continuation” URL

If you run other AWS Labs MCP servers, or you’ve built internal MCP tools that wrap boto3 calls, audit them for the same pattern before assuming this is a HealthLake-only bug.

Remediation

1. Patch immediately.

pip install --upgrade "awslabs.healthlake-mcp-server>=0.0.14"

Confirm the running version inside your MCP host config (Claude Desktop, Amazon Q Developer, Bedrock AgentCore, etc.) and restart the server process so the update takes effect.

2. Scope the IAM role instead of trusting --readonly. The --readonly flag on this server only restricts which tools are exposed at the application layer — it does not change what the underlying IAM principal is authorized to do. Bind the execution role to a least-privilege policy scoped to specific HealthLake datastore ARNs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "HealthLakeReadOnlyScoped",
      "Effect": "Allow",
      "Action": [
        "healthlake:ListFHIRDatastores",
        "healthlake:DescribeFHIRDatastore",
        "healthlake:SearchWithGet",
        "healthlake:SearchWithPost"
      ],
      "Resource": "arn:aws:healthlake:us-east-1:111122223333:datastore/*",
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "us-east-1" }
      }
    }
  ]
}

3. Rotate credentials for any deployment that ran a vulnerable version. If the MCP server was reachable by untrusted or lower-trust callers before you patched, treat the associated role’s temporary credentials as potentially compromised:

# Identify the role and force new sessions by revoking active ones
aws iam put-role-policy \
  --role-name healthlake-mcp-execution-role \
  --policy-name DenyAllUntilRotated \
  --policy-document file://deny-all.json

# Once verified clean, restore least-privilege policy and monitor
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=healthlake-mcp-execution-role \
  --start-time "$(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)"

4. Add egress controls so credential exfiltration fails closed even against unknown future bugs. If the MCP server runs in a VPC (Fargate, EC2, Lambda with VPC config), restrict outbound traffic to only the AWS service endpoints it needs via a VPC endpoint policy and security group egress rules, rather than allowing open internet egress:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.us-east-1.healthlake \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-0123456789abcdef0 \
  --security-group-ids sg-0123456789abcdef0

Pair the endpoint with a security group that denies egress to 0.0.0.0/0 on 443 by default, so a redirected request to an attacker-controlled host has no route out.

5. Monitor for anomalous STS usage. Enable GuardDuty’s UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration and CredentialAccess finding types, and alert on AssumeRole or API activity from the affected role originating from IP ranges outside your expected VPC or CI/CD egress.

The broader lesson

MCP servers are becoming a standard part of how AI agents reach AWS APIs, and each one is effectively a new confused-deputy surface: it holds real IAM credentials but takes untrusted input (prompts, tool arguments, and — as this CVE shows — data returned from the API itself) that can influence where those credentials get used. Treat every MCP server touching cloud credentials as you would any other privileged service: least-privilege IAM, network egress restrictions, and prompt patching when the vendor ships a fix.

Sources: AWS Security Bulletin 2026-054, NVD CVE-2026-15643

← All Analysis Subscribe via RSS