One HTTP Request From Full Account Takeover: How to Stop SSRF-to-IMDS Cloud Credential Theft in 2026

The fastest path to owning a cloud account in 2026 is not a zero-day. It is a single, well-placed HTTP request that tricks one of your own applications into reading its instance metadata service (IMDS) and handing over the credentials attached to it. This is exactly why learning to prevent SSRF cloud metadata credential theft with IMDSv2 is one of the highest-leverage things a cloud team can do this quarter — and why the technique is at the heart of the most destructive campaigns unfolding right now.

You do not have to imagine the impact. The TeamPCP supply-chain campaign and its successor worm, PCPJack, have spent 2026 doing precisely this at scale: a compromised developer or security tool runs a short bash script, the script queries the instance metadata endpoint, and within seconds AWS, Azure, and GCP credentials are exfiltrated. By March 2026, TeamPCP had amassed more than 500,000 credentials from over 10,000 CI/CD pipelines, according to Palo Alto Unit 42. The metadata service was the crowbar.

How the SSRF-to-Metadata Attack Actually Works

Every cloud VM ships with a link-local metadata endpoint — 169.254.169.254 on AWS and GCP, and a nearly identical address on Azure. Any process on the instance can reach it, and if the instance has an attached IAM role or managed identity, the endpoint will hand back short-lived credentials for that role. This is a feature: it is how your app gets keys without hardcoding them.

The problem is the two ways an attacker reaches that endpoint. The first is Server-Side Request Forgery (SSRF). If your web application can be tricked into fetching an attacker-supplied URL — a common flaw in image proxies, webhook handlers, PDF renderers, and misconfigured reverse proxies — the attacker simply points it at http://169.254.169.254/latest/meta-data/iam/security-credentials/. The application dutifully fetches the credentials and returns them in the response. Fortinet has tied a wave of AWS credential compromises to exactly this pattern via a years-old Grafana SSRF flaw (CVE-2020-13379), and SSRF-to-metadata findings routinely score 8.8–9.8 CVSS because they require no authentication and yield the keys to the kingdom.

The second path is local code execution — which is what the TeamPCP worm uses. Once a trojanized tool runs on the host, its kamikaze.sh payload fingerprints the environment and reads IMDS directly, alongside ~/.aws/credentials, GOOGLE_APPLICATION_CREDENTIALS service-account JSON, and Azure service-principal secrets.

IMDSv1 vs. IMDSv2: Why the Version Matters

The original metadata service, IMDSv1, answers any GET request, no questions asked. That is why a plain SSRF — which can usually only issue GETs and cannot set custom headers — walks straight through it.

IMDSv2 closes that door with session-oriented requests. Before reading any metadata, the caller must send an HTTP PUT to obtain a token, including the custom header X-aws-ec2-metadata-token-ttl-seconds, then present that token on subsequent GETs. Most SSRF primitives cannot perform the PUT-then-GET sequence or set custom headers, so they fail. IMDSv2 also refuses to issue a token to any request carrying an X-Forwarded-For header, which neutralizes open reverse proxies, and its low default response hop limit stops the token from being relayed through a misconfigured network layer. As AWS puts it, this is defense in depth against open firewalls, reverse proxies, and unpatched SSRF.

The catch: enforcement is not automatic. IMDSv2 protects nothing if instances still accept v1 calls, and token-hopping protections can still fail in misconfigured ECS and Lambda setups. Enforcement is a configuration you must actively require and verify.

Impact Assessment

The blast radius of a single leaked instance credential is the entire permission set of its IAM role or managed identity — and in practice those roles are chronically over-permissioned. From one set of harvested keys, an attacker can enumerate S3 buckets, read secrets, spin up compute for cryptomining, pivot to other accounts through trust relationships, and, as the VECT ransomware crews have demonstrated, feed stolen CI/CD and cloud tokens straight into an extortion kill chain.

Risk rating for an internet-exposed workload running IMDSv1 with an attached role: Critical. Affected platforms span every major cloud (AWS EC2/ECS, Azure VMs, GCE), every containerized workload that inherits node credentials, and any Kubernetes node whose pods can reach the metadata IP. If your applications accept user-controlled URLs and your instances still allow IMDSv1, you are one unpatched SSRF away from account takeover.

The CloudShieldSecure Perspective

Enforcing IMDSv2 is a checkbox that thousands of instances quietly fail, because a single legacy AMI, a Terraform module with the wrong default, or one team’s forgotten launch template reopens the door. CloudShieldSecure treats metadata exposure as a first-class posture finding: it continuously inventories every instance still answering IMDSv1, ranks those findings by real exploitability — an internet-facing workload with a high-privilege role outranks an isolated batch node — and hands engineers the exact remediation instead of a raw alert.

Just as importantly, CloudShieldSecure watches the behavior around the metadata service at runtime. Anomalous access to 169.254.169.254, credentials suddenly used from a new geography or ASN, and the environment-fingerprinting patterns that scripts like kamikaze.sh leave behind are exactly the signals it surfaces — catching credential theft in progress even when a novel SSRF or a trojanized tool slipped past static review. Enforcement plus runtime detection is the combination that turns “one HTTP request from takeover” into “detected and contained.”

Recommended Actions

Use this checklist to close the metadata attack path across your fleet:

1. Require IMDSv2 on every instance. Launch with HttpTokens=required. Set HttpPutResponseHopLimit=2 where containers run, so the Docker bridge network can still relay the token.
2. Find your IMDSv1 stragglers. Watch the CloudWatch MetadataNoToken metric to identify instances still taking v1 calls, fix the apps making them, and flip HttpTokens to required once the metric holds at zero.
3. Codify it. Bake IMDSv2 into every IaC template and golden AMI, and enforce a Service Control Policy (SCP) that blocks the launch of any non-compliant instance org-wide.
4. Right-size instance roles. Apply least privilege so a stolen credential yields as little as possible; remove wildcard permissions and unused role attachments.
5. Patch and test for SSRF. Prioritize internet-facing apps that fetch URLs (proxies, webhooks, renderers); block requests to link-local ranges at the application layer.
6. Enforce IMDSv2 on ECS and Lambda paths too — do not assume managed services are covered by default.
7. Monitor metadata access at runtime, alerting on anomalous 169.254.169.254 access and credential use from unexpected locations.
8. Rotate on suspicion and keep credential TTLs short so leaked tokens expire fast.

The metadata service is one of the most useful features in the cloud and one of the most abused. Enforce IMDSv2, verify the enforcement continuously, and watch how the credentials are used — and you turn the attacker’s favorite one-request shortcut into a dead end.

CloudShieldSecure, built by CloudKonsult, gives cloud teams continuous posture visibility and runtime detection so metadata exposure is caught before it becomes an incident. Learn more at https://cloudshieldsecure.cloudkonsult.cloud

Sources & References

• Amazon Web Services — Defense in depth against SSRF with EC2 Instance Metadata Service enhancements: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
• Palo Alto Unit 42 — Weaponizing the Protectors: TeamPCP’s Multi-Stage Supply Chain Attack: https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/
• SentinelOne Labs — PCPJack: Cloud Worm Evicts TeamPCP and Steals Credentials at Scale: https://www.sentinelone.com/labs/cloud-worm-evicts-teampcp-and-steals-credentials-at-scale/
• Fortinet — AWS credential compromises tied to Grafana SSRF attacks: https://www.fortinet.com/resources/articles/aws-credential-compromises-tied-to-grafana-ssrf-attacks
• Resecurity — SSRF to AWS Metadata Exposure: How Attackers Steal Cloud Credentials: https://www.resecurity.com/blog/article/ssrf-to-aws-metadata-exposure-how-attackers-steal-cloud-credentials
• OneUptime — How to Use IMDSv2 for Secure Instance Metadata Access: https://oneuptime.com/blog/post/2026-02-12-use-imdsv2-for-secure-instance-metadata-access/view