AWS Security Bulletin AWS-2025-021, published in September 2025, opens with a deliberately quiet sentence: "AWS is aware of a potential Instance Metadata Service (IMDS) impersonation issue that would lead to customers interacting with unexpected AWS accounts." The bulletin reads like operational guidance, but the underlying issue matters to every team running EC2 workloads: a misconfiguration or downstream library bug can cause an instance to talk to an IMDS endpoint that is not the one AWS provisioned, leaking the IAM role credentials baked into the workload. Coupled with the September 2025 in-the-wild exploitation of Pandoc CVE-2025-51591 to reach the IMDS over SSRF, AWS-2025-021 is the operational backdrop for what is shaping up to be the highest-volume EC2 credential theft year on record.
What does "IMDS impersonation" actually mean?
EC2 instances reach the metadata service at the link-local address 169.254.169.254. The kernel routes packets to that address through a Xen or Nitro hypervisor hook, which returns instance identity, user-data, and — critically — short-lived STS credentials for any IAM role attached via the instance profile. If anything in the data path between the application and that link-local address can be coerced into hitting a different endpoint, an attacker can stand up a fake metadata responder and harvest the credential bearer token an unsuspecting SDK retrieves. The "impersonation" framing in AWS-2025-021 covers several distinct failure modes: misrouted requests caused by application-level proxies, SSRF flaws in third-party libraries, container networking misconfigurations that expose IMDS to siblings, and the long-tail of legacy IMDSv1 GET requests that lack the session token IMDSv2 requires.
How does this connect to CVE-2025-51591 in Pandoc?
In September 2025, Wiz documented in-the-wild exploitation of CVE-2025-51591, an SSRF in Pandoc's HTML iframe handling that allowed attackers to submit crafted documents whose iframes pointed at 169.254.169.254/latest/meta-data/iam/info. When the rendering host ran on an EC2 instance with IMDSv1 enabled, Pandoc faithfully fetched the metadata response and embedded it in the rendered output, exposing role credentials to whoever uploaded the source HTML. The attack failed against IMDSv2-only hosts because IMDSv2 requires a PUT request to obtain a session token, and Pandoc's iframe rendering only issues GETs. AWS-2025-021 implicitly endorses the Wiz remediation guidance: enforce IMDSv2, set the hop limit to 1, and assume any workload that touches user-supplied URLs is a credential exfiltration vector until proven otherwise.
# Audit every EC2 instance for IMDSv2 enforcement and hop-limit 1
aws ec2 describe-instances \
--query 'Reservations[].Instances[?MetadataOptions.HttpTokens!=`required` || MetadataOptions.HttpPutResponseHopLimit!=`1`].[InstanceId,MetadataOptions]' \
--output table
# Force-enable IMDSv2 on a non-compliant instance
aws ec2 modify-instance-metadata-options \
--instance-id i-0123456789abcdef0 \
--http-tokens required \
--http-put-response-hop-limit 1 \
--http-endpoint enabled
Why is IMDSv2 still not universal three years after launch?
Because rollout is operationally expensive at scale. AWS launched IMDSv2 in November 2019 and made HttpTokens=required the default for new EC2 instances created via the console in January 2024, but legacy AMIs, custom Packer images, golden images baked before 2024, and instances launched via untouched Auto Scaling Group launch templates still default to optional. AWS also held back forcing the setting on existing instances because legacy SDK versions — anything older than Boto3 1.14, AWS SDK for Java 1.11.678, or AWS SDK for Go 1.30.0 — only know how to issue IMDSv1 GETs. The painful pattern is that the same regulated workloads with the strictest credential blast-radius requirements are the ones running RHEL 7 instances with five-year-old SDKs and a change advisory board that needs 90 days to approve a metadata transition. AWS-2025-021 pushes those holdouts: organizations should target full IMDSv2 enforcement by end of 2025 and use Trusted Advisor's IMDS check plus Inspector's EC2-Instance-IMDSv1-Configuration finding to chase down the laggards.
What controls actually stop impersonation?
Five concrete defenses. First, set HttpTokens=required at the launch template level for every Auto Scaling Group and use AWS Config rule ec2-imdsv2-check to remediate drift. Second, pin the IMDS hop limit to 1 — the default of 2 lets a sidecar container reach the metadata service through the host's network namespace, and most modern container workloads do not need that. Third, scope IAM roles attached to EC2 instances with aws:SourceVpc and aws:VpcSourceIp conditions so that a stolen credential cannot be replayed from outside the legitimate VPC. Fourth, force outbound proxies for any workload that accepts user-supplied URLs (PDF generators, HTML renderers, headless browsers, document converters) to drop traffic to 169.254.169.254 entirely — the Wiz writeup on CVE-2025-51591 shows how brittle Pandoc was in part because it had no such egress policy. Fifth, set up GuardDuty's UnauthorizedAccess:IAMUser/InstanceCredentialExfiltrationInsideAWS and OutsideAWS findings and integrate them with Security Hub for immediate paging.
What about workloads on EKS, ECS, and Lambda?
Lambda does not expose IMDS in the way EC2 does, so the impersonation bulletin does not apply to functions. EKS and ECS workloads are a different story. On EKS, the IMDS is reachable from pods unless you have explicitly blocked it via security group, NetworkPolicy, or by setting the IMDSv2 hop limit to 1 — this last control is essential because a pod typically sits one network hop further from the host than a process on the EC2 instance itself. The AWS recommendation since 2023 has been to use EKS Pod Identity or IAM Roles for Service Accounts (IRSA) so workloads never need to reach IMDS for credentials in the first place. For ECS, AWS Fargate handles IMDS isolation per task by default; EC2 launch type users must set ECS_AWSVPC_BLOCK_IMDS=true in /etc/ecs/ecs.config and pin the host's hop limit. AWS-2025-021 does not call these out specifically, but every postmortem of an EC2 credential exfiltration since June 2025 has surfaced one of them as a contributing factor.
What should you do in the next 30 days?
Run aws ec2 describe-instances against every region and account, count the instances with HttpTokens=optional, and treat that count as your audit target. Push a Config conformance pack to remediate the gap. Audit every EC2-attached IAM role with IAM Access Analyzer for unused permissions and tighten them to the smallest set the workload needs. Update SDK pinning in your golden AMI build pipeline so future bakes ship with IMDSv2-aware client libraries. And add an integration test to your image build pipeline that boots the AMI, asserts curl http://169.254.169.254/latest/meta-data/ without a token returns HTTP 401, and fails the build if it does not.
How Safeguard Helps
Safeguard pulls EC2 inventory and metadata options across linked AWS accounts on a 15-minute cadence, surfacing every instance configured with HttpTokens=optional as a P1 finding tagged against AWS-2025-021. Reachability analysis maps applications that handle user-supplied URLs — Pandoc, Ghostscript, wkhtmltopdf, headless Chromium — to the EC2 instances running them, so the Pandoc CVE-2025-51591 advisory immediately surfaces the exploitable subset rather than your entire fleet. Policy gates block AMI builds and Terraform plans that produce IMDSv1-capable launch templates, and SBOMs for every bake are diffed against the AWS SDK minimum versions required for IMDSv2 support. Griffin AI correlates GuardDuty InstanceCredentialExfiltration findings with the originating workload's SBOM to point on-call at the vulnerable component within seconds.