CISA flags two AWS metadata-service exploits after credential-theft wave

Both entries abuse IMDSv1 endpoints reachable from vulnerable web apps to mint temporary role credentials. Enforcing IMDSv2 with a hop limit of one closes the path — here is the org-wide policy plus a GuardDuty detection to catch what slipped through.

CISA has added two AWS instance-metadata-service exploits to its Known Exploited Vulnerabilities catalog after a wave of credential theft traced to internet-facing applications.

What the exploits actually do

Both entries abuse the IMDSv1 endpoint at 169.254.169.254, which answers any HTTP request originating from the instance. A server-side request forgery bug in an application running on that instance is enough: the attacker persuades the app to fetch the metadata URL, and the response contains temporary credentials for whatever IAM role the instance carries.

Those credentials are valid until they expire, work from anywhere, and appear in CloudTrail as legitimate role activity. Nothing in the request looks like an intrusion.

Enforcing IMDSv2

IMDSv2 requires a PUT request to obtain a session token before any metadata read, which SSRF payloads generally cannot perform. Two settings close the path:

• Require IMDSv2 on every instance, so the v1 endpoint stops answering.
• Set the hop limit to 1, so a containerised workload on the host cannot reach metadata through an extra network hop.

Apply it account-wide rather than per instance. The EC2 account setting makes IMDSv2 the default for new launches, and a Service Control Policy can refuse RunInstances when the metadata options are wrong.

Detecting what already happened

Enforcement is forward-looking, so assume something already leaked and go hunting:

1. Search CloudTrail for API calls made with instance-role credentials from an IP address outside your VPC ranges. That combination is the clearest signal.
2. Enable the GuardDuty finding for instance credentials used from an external address, if it is not already on.
3. Review each role's permissions and cut anything the workload does not need — the blast radius of a stolen token is exactly the role's policy.
4. Rotate anything the role could reach that has its own long-lived credential.

Why this keeps happening

IMDSv2 shipped years ago and is not hard to enable. What keeps v1 alive is old AMIs, unmanaged instances outside the main account structure, and SDK versions too old to negotiate a session token. An inventory sweep for instances still permitting v1 usually finds them in the accounts nobody owns.