AWS Security Hub · EC2
EC2.8: IMDSv1 lets an SSRF steal instance credentials
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub EC2.8 check?
EC2.8 fails instances that do not require IMDSv2, i.e. the instance metadata service still accepts the older, token-less IMDSv1 requests (HttpTokens is "optional" rather than "required").
Why does EC2.8 matter?
IMDSv1 is the mechanism behind some of the most damaging cloud breaches: a server-side request forgery (SSRF) in your app can read the instance metadata endpoint and steal the role's temporary credentials. IMDSv2 requires a PUT-issued session token, which SSRF payloads generally cannot obtain, closing that path.
How do I fix EC2.8?
- Set HttpTokens=required (and a low HttpPutResponseHopLimit) on running instances with modify-instance-metadata-options.
- Bake IMDSv2-required into your launch templates and AMIs so new instances are safe by default.
- Confirm your SDKs and agents are recent enough to use IMDSv2 before enforcing fleet-wide.
Remediation script · bash
# Flip a running instance to IMDSv2-only (EC2.8).
aws ec2 modify-instance-metadata-options --instance-id i-0abc12def345f6789 \
--http-tokens required --http-put-response-hop-limit 1 --http-endpoint enabled
# Migrate the launch source to a launch template with IMDSv2 required (AutoScaling.3),
# then roll the fleet so existing instances actually pick it up.
aws ec2 create-launch-template-version --launch-template-id lt-0fee123abc456def0 \
--source-version '$Latest' \
--launch-template-data '{"MetadataOptions":{"HttpTokens":"required","HttpPutResponseHopLimit":2,"HttpEndpoint":"enabled"}}'
aws autoscaling start-instance-refresh --auto-scaling-group-name etl-workers-asg
# Lock it account-wide so new instances are born compliant.
aws ec2 modify-instance-metadata-defaults --http-tokens required --http-put-response-hop-limit 2Full walkthrough (console steps, edge cases and verification) in the lesson Enforce IMDSv2 on EC2.
Is EC2.8 a false positive?
EC2.8 fails whenever HttpTokens is "optional", but "optional" doesn't always mean the instance is reachable over IMDSv1 in practice. An instance that has the metadata endpoint turned off entirely (HttpEndpoint=disabled) is arguably safer than one forced to IMDSv2, yet the control's pass condition is specifically HttpTokens=required, so a disabled endpoint can still surface as a finding rather than a clean PASS. The control also evaluates HttpTokens alone and does not consider whether an IAM role is attached, so an instance with no instance profile (which has no role credentials in metadata for an SSRF to steal) still fails on HttpTokens=optional; the finding is real for defence-in-depth but lower-risk than one on a role-bearing host, so it's reasonable to deprioritise (not ignore) role-less instances. A genuine, rare reason to keep IMDSv1 enabled is a legacy agent or vendored SDK that predates IMDSv2 and breaks under token enforcement. In that case don't ship a workaround that re-opens SSRF risk: pin a low HttpPutResponseHopLimit, isolate the host, and set the finding's workflow status to SUPPRESSED with a remediation date for upgrading the software, rather than treating IMDSv1 as a permanent state.
More EC2 controls
- EC2.1 An EBS snapshot is publicly restorable by any account
- EC2.2 Default security groups still allow traffic
- EC2.3 Attached EBS volumes are not encrypted at rest
- EC2.4 Long-stopped instances are abandoned attack surface
- EC2.6 No VPC flow logs, so there is no network audit trail
- EC2.7 New EBS volumes are not encrypted by default
- EC2.9 Instances are directly reachable on public IPv4
- EC2.10 EC2 API traffic leaves the VPC over the internet
- EC2.13 SSH (port 22) is open to the entire internet
- EC2.14 RDP (port 3389) is open to the entire internet
- EC2.15 Subnets auto-assign public IPs to new instances
- EC2.17 Instances with multiple ENIs can bridge network boundaries