Exposed Cloud Metadata Services

Exposed Cloud Metadata Services is a high-severity vulnerability that allows attackers to access the instance metadata service (IMDS) available on cloud virtual machines to steal temporary IAM credentials, extract sensitive configuration data, and pivot to other cloud resources. Every major cloud provider runs a metadata service at a well-known link-local IP address (169.254.169.254 for AWS and GCP, 169.254.169.254 or the Azure Instance Metadata Service endpoint for Azure) that provides instance-level information including IAM role credentials to any process running on the instance.

The metadata service is a fundamental component of cloud infrastructure—it enables instances to discover their own identity, retrieve temporary credentials for authorized API calls, and access user-provided configuration data (user data scripts). However, this same service becomes a critical attack vector when applications running on cloud instances are vulnerable to Server-Side Request Forgery (SSRF), where an attacker can induce the application to make HTTP requests to arbitrary URLs, including the metadata service endpoint.

The Capital One breach of 2019, which exposed 100 million customer records, was a watershed moment that demonstrated the devastating impact of metadata service exploitation. The attacker exploited an SSRF vulnerability in a web application firewall to access the EC2 metadata service, steal temporary IAM credentials, and use those credentials to download data from S3 buckets. This attack pattern remains one of the most impactful cloud-specific exploitation techniques because the metadata service provides a direct path from web application vulnerability to cloud infrastructure compromise.

The attack begins with an SSRF vulnerability in an application running on a cloud instance. The attacker sends a crafted request that causes the application to make an HTTP request to the metadata service. For AWS EC2 instances using IMDSv1, the attacker simply needs to induce a request to http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name], which returns temporary AWS credentials (access key ID, secret access key, and session token) that the attacker can use directly from their own machine to authenticate to AWS APIs with the instance's IAM role permissions.

The SSRF vector can be exploited through various application features: URL preview/unfurling functions, PDF generators that fetch remote resources, image processing that downloads from user-supplied URLs, webhook endpoints that make outbound HTTP requests, or any feature where user input influences an outbound HTTP request destination. Even partial SSRF (where the attacker controls only the hostname but not the path) can be exploited using DNS rebinding techniques to redirect requests from a legitimate domain to 169.254.169.254.

Beyond IAM credentials, the metadata service exposes additional sensitive information: user data scripts (which often contain hardcoded secrets, database passwords, or bootstrap configurations), network configuration details, instance identity documents that can be used for instance impersonation, and in some configurations, custom metadata tags that may contain application-specific secrets. In GCP, the metadata server also provides OAuth tokens for service accounts. In Kubernetes environments running on cloud instances, the metadata service may expose the kubelet credential or node-level service account tokens that enable cluster compromise.

• Theft of temporary IAM credentials enabling full access to all cloud resources authorized by the instance's IAM role, often including S3 buckets, DynamoDB tables, and SQS queues
• Lateral movement across cloud infrastructure using stolen credentials to access other services, accounts, or regions authorized by the compromised role
• Exposure of secrets embedded in instance user data scripts, including database passwords, API keys, and service credentials used during instance bootstrapping
• Instance identity theft using stolen instance identity documents to impersonate the compromised instance in API calls and trust relationships
• Kubernetes cluster compromise when metadata service exploitation on worker nodes provides access to kubelet credentials or service account tokens
• Persistent access through stolen credentials that remain valid for their entire session duration (up to 12 hours for AWS STS credentials) even after the SSRF vulnerability is patched

1. Enforce IMDSv2 (Instance Metadata Service Version 2) on all AWS EC2 instances by setting HttpTokens: required in instance metadata options. IMDSv2 requires a PUT request with a TTL header to obtain a session token before accessing metadata, which prevents exploitation through most SSRF vectors because SSRF attacks typically cannot issue PUT requests with custom headers. Implement equivalent protections on GCP (metadata request header requirement) and Azure (metadata header requirement).
2. Implement comprehensive SSRF prevention in all applications: validate and sanitize user-supplied URLs, maintain allow-lists of permitted outbound destinations, block requests to private IP ranges (including 169.254.0.0/16) at the application level, and use DNS resolution validation to prevent DNS rebinding attacks.
3. Apply least-privilege IAM roles to all cloud instances. Reduce the blast radius of credential theft by granting instances only the minimum permissions required for their specific function. Avoid attaching roles with broad permissions (S3 full access, Administrator access) to instances running internet-facing applications.
4. Implement network-level metadata service access controls. Use AWS VPC endpoints for IMDS, configure iptables rules to restrict metadata access to specific processes or users on the instance, and in Kubernetes, use network policies to block pod access to the metadata service on worker nodes.
5. Deploy web application firewalls (WAFs) with rules that detect and block SSRF attempts targeting metadata service IPs. Configure WAF rules to inspect request parameters, headers, and bodies for patterns matching metadata service URLs (169.254.169.254, metadata.google.internal).
6. Remove secrets from instance user data and instead use dedicated secrets management services (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) that require explicit IAM authorization for each secret access.
7. Monitor CloudTrail, GCP Audit Logs, and Azure Activity Logs for API calls made using instance role credentials from IP addresses outside your known infrastructure ranges, which indicates stolen credential usage.

Test metadata service exposure by first inventorying all cloud instances and checking their IMDS configuration. For AWS, use aws ec2 describe-instances --query "Reservations[].Instances[].[InstanceId, MetadataOptions]" to identify instances still using IMDSv1. From within instances, test metadata accessibility by running curl http://169.254.169.254/latest/meta-data/ and verifying whether credentials are accessible at /latest/meta-data/iam/security-credentials/.

Test applications for SSRF vulnerabilities that could be used to reach the metadata service. Identify all application features that make outbound HTTP requests (URL fetchers, webhook processors, PDF generators, image loaders) and test each with payloads targeting the metadata endpoint. Use various bypass techniques: IP address encoding variations (decimal: 2852039166, hex: 0xA9FEA9FE, octal: 0251.0376.0251.0376), DNS rebinding, URL redirect chains through controlled domains, and protocol smuggling through different URL schemes.

Validate network-level protections by attempting to reach the metadata service from different contexts: application processes, containers, pods, and different network interfaces. In Kubernetes environments, test whether pods can access the node metadata service through the host network or through the pod network. Use tools like Nuclei with cloud-specific templates to automate SSRF-to-metadata testing across multiple applications. Verify that IMDSv2 enforcement effectively blocks SSRF exploitation by attempting metadata access through SSRF vectors that cannot issue PUT requests.