Module 3 · Metadata Endpoints — Still the Killer Chain

Last updated: April 29, 2026

The metadata endpoint at 169.254.169.254 is the most important IP address in cloud computing. It serves credentials, user-data, instance identity, and configuration to workloads. It’s reachable from inside the instance (intended) and sometimes from outside (unintended — SSRF). Combined, metadata endpoints turned SSRF from “inconvenience” into “cloud account compromise.”

Why this happens

Cloud instances need credentials to access other services (S3, databases, queues). Managing credentials manually is painful. Cloud providers solved it via instance metadata: instance asks “what’s my role?” — metadata endpoint responds with temporary credentials. Elegant for legitimate use.

The endpoint is at a link-local address (169.254.x.x) — reachable only from within the instance. Workload code fetches http://169.254.169.254/... to get its credentials.

The catastrophe: if the workload has SSRF, the attacker can reach the metadata endpoint through the workload. Temporary credentials for the instance’s role leak out. If the role is broad, cloud compromise follows.

IMDSv1 vs IMDSv2 (AWS)

# IMDSv1 (legacy): simple GET
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Returns role name
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/MY-ROLE
# Returns temporary AWS credentials

# IMDSv2: requires token-based auth
TOKEN=$(curl -X PUT http://169.254.169.254/latest/api/token \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/iam/security-credentials/

# IMDSv2 = SSRF mostly breaks because PUT needed first
# Modern EC2 instances default to IMDSv2-required
# But legacy + misconfigured = IMDSv1 still common

Capital One 2019 — the canonical case

SSRF in Capital One’s AWS-hosted web application reached IMDSv1. Attacker (a former AWS employee) exfiltrated temporary credentials for the WAF role. The role had over-broad S3 permissions. Attacker listed and downloaded ~100 million credit applications. ~$190M settlement + regulatory penalty.

Chain: SSRF → IMDSv1 → credentials → S3 permissions → data exfil. Each step was a configuration failure on Capital One’s side.

GCP and Azure metadata

# GCP metadata server
# Requires Metadata-Flavor: Google header (prevents naive SSRF)
curl -H "Metadata-Flavor: Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

# Azure Instance Metadata Service (IMDS)
# Requires Metadata: true header
curl -H "Metadata: true" \
    "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

Both require specific headers — harder to reach via vanilla SSRF, but possible when attacker can set headers on the outbound request.

Container metadata

Docker, Kubernetes pods: similar metadata endpoints for service accounts. K8s pod accessing kube-apiserver via service account token mounted into pod — steal token, become pod’s service account, potentially cluster-admin if misconfigured.

# Inside compromised container
cat /var/run/secrets/kubernetes.io/serviceaccount/token
# Use this JWT with kubectl or curl to kube-apiserver
curl -k https://kubernetes.default.svc/api/v1/namespaces/kube-system/secrets \
    -H "Authorization: Bearer $(cat /var/run/secrets/.../token)"

Defenses

1. IMDSv2 required on AWS (or equivalent on other clouds)
2. Disable IMDS entirely if workload doesn’t need cloud credentials
3. SSRF defense: URL allow-list, block RFC1918 + 169.254, DNS rebinding protection
4. Restrict IAM role permissions — least privilege reduces blast radius
5. Scoped tokens where possible (time-limited, service-limited)
6. Monitor metadata endpoint access — unusual patterns in CloudTrail/VPC flow logs
7. For K8s: Use Workload Identity (GKE) or IRSA (EKS) instead of mounting service account tokens

Mindset takeaway

Every workload in the cloud has credentials accessible via a well-known URL. Protect that URL. Every SSRF in a cloud workload is potentially a cloud-account compromise. The difference is IAM scope: tight IAM + IMDSv2 = SSRF stays small; broad IAM + IMDSv1 = disaster.