Security recommendation

The AWS Instance Metadata Service version 1 (IMDSv1) is a request/response protocol that does not require session tokens. It is susceptible to server-side request forgery (SSRF) attacks, which can be abused to retrieve the EC2 instance profile credentials. IMDSv2 mitigates this risk by requiring a session-oriented token-based protocol. All workloads should use IMDSv2 exclusively.

Compliance

• Restrict access to instance metadata to IMDSv2 (found in CIS AWS Foundations Benchmark)

Documentation

The EC2 Instance Metadata Service (IMDS) is reachable from any process on an EC2 instance (or any container running on it) at the link-local address 169.254.169.254. IMDS exposes instance metadata, including the temporary credentials attached to the instance profile. These credentials can be used to authenticate to AWS APIs with the permissions of the instance role.

IMDSv1 uses simple, unauthenticated GET requests, which makes it trivially exploitable through SSRF vulnerabilities in workloads exposed to the network: an attacker who can coerce a vulnerable process into making an outbound HTTP request can retrieve the instance credentials and pivot into the AWS account.

IMDSv2 mitigates this class of attack by requiring callers to first obtain a session token via a PUT request that includes a TTL hop limit. SSRF flaws that only allow GET requests are unable to obtain the session token, and therefore cannot retrieve the credentials.

This finding is raised when the Workload Protection agent observes a process on the host (or in a container running on the host) accessing the EC2 metadata service using the IMDSv1 protocol. Findings are scoped to the host, since IMDSv2 enforcement is an instance-level configuration.

Remediation

Prerequisites

You must have:

• Access to the AWS console or AWS CLI with permissions to modify EC2 instance metadata options
• Knowledge of the applications running on the instance and the AWS SDK / IMDS client libraries they use
• Agent v7.60 or newer for Workload Protection IMDS monitoring

Step-by-step guide

Step 1: Identify the process making IMDSv1 requests

Use the agent event details to identify which process is calling IMDSv1, on which host, and from which container (if any).

In the Workload Protection event details, look at:

• process.file.name and process.file.path — the executable making the IMDSv1 call
• process.ancestors — the call chain leading to the request
• container.id / container.name — the originating container, if any
• host — the EC2 instance hosting the workload

On the host itself, you can also correlate against network logs:

# Recent connections to the IMDS endpoint
sudo ss -tnp | grep 169.254.169.254

# Live capture of IMDS traffic
sudo tcpdump -i any -n host 169.254.169.254

# Process tree for further context
ps -ef --forest

Step 2: Update the application to use IMDSv2

For applications using the AWS SDK, upgrade to a recent SDK version that uses IMDSv2 by default and ensure the SDK is configured to use it:

• AWS SDK for Go v2, AWS SDK for Java v2, AWS SDK for Python (boto3) >= 1.20, AWS SDK for JavaScript v3, AWS SDK for Rust, etc., all use IMDSv2 by default.
• If your application uses raw HTTP calls to the metadata endpoint, update it to first request a session token:

# Request an IMDSv2 session token (valid for up to 6 hours)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Use the token on subsequent metadata requests
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

Step 3: Enforce IMDSv2 on the EC2 instance

Once all workloads on the instance support IMDSv2, enforce it at the instance level so that IMDSv1 requests are rejected by AWS.

# Require IMDSv2 (HttpTokens=required) and keep the default hop limit
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

For Auto Scaling groups, update the launch template:

aws ec2 create-launch-template-version \
  --launch-template-id lt-0123456789abcdef0 \
  --source-version "\$Latest" \
  --launch-template-data '{"MetadataOptions":{"HttpTokens":"required","HttpEndpoint":"enabled"}}'

For Terraform-managed instances, set metadata_options on the aws_instance or aws_launch_template resource:

metadata_options {
  http_endpoint               = "enabled"
  http_tokens                 = "required"
  http_put_response_hop_limit = 2
}

Step 4: Prevent regression

• Set the account-level default to require IMDSv2 for new instances:

aws ec2 modify-instance-metadata-defaults \
  --http-tokens required \
  --http-endpoint enabled

• Add a guardrail (AWS Config rule, SCP, or CSPM policy) to flag any instance launched with HttpTokens=optional.
• Continue to monitor this finding in Workload Protection — re-emergence indicates a new workload or rolled-back configuration.