SSRF in Cloud Environments: Hidden Paths to Critical Infrastructure Exposure

A developer builds an image processing service in AWS. Users submit URLs. The application fetches images, resizes them, and returns optimized versions. Standard functionality. Clean architecture. The service runs on EC2 with an IAM role granting S3 access for storing processed images.

A security researcher submits this URL: http://169.254.169.254/latest/meta-data/iam/security-credentials/. The application dutifully fetches the content, processes it as an image (failing, since it's JSON), but the damage is done. The response includes temporary AWS credentials with full S3 permissions. The researcher now has the same cloud access as the application itself.

This is Server-Side Request Forgery (SSRF) in cloud environments, and it represents one of the most critical attack vectors in modern cloud infrastructure. What seems like a simple feature vulnerability becomes a complete infrastructure compromise when combined with cloud metadata services.

Understanding SSRF in Cloud Context

Server-side request forgery occurs when applications make HTTP requests based on user-supplied input without proper validation. The application acts as a proxy, fetching resources on behalf of users. In traditional environments, SSRF enables port scanning internal networks, accessing internal services, or reading local files.

Cloud environments amplify SSRF impact exponentially. Every major cloud provider exposes metadata services that provide sensitive information to running instances: credentials, configuration data, network details, encryption keys. These services are accessible only from within the cloud environment, assuming network-level protection. SSRF bypasses these assumptions.

The metadata service typically runs at a special IP address unreachable from the internet but accessible from any instance in the cloud environment. AWS uses 169.254.169.254. Azure uses the same IP. Google Cloud Platform uses metadata.google.internal or 169.254.169.254. These services don't require authentication for basic queries, trusting network isolation as security.

When an application with SSRF vulnerabilities runs in the cloud, attackers exploit it to query metadata services. The application makes the request from inside the cloud environment where metadata services are accessible. Responses include IAM credentials, instance metadata, user data scripts containing secrets, and configuration details that enable deeper compromise.

During cloud penetration testing, SSRF consistently ranks among the most critical findings. A single SSRF vulnerability can escalate to full AWS account compromise, cross-account access, or complete infrastructure takeover depending on IAM role permissions and pivot opportunities.

AWS Metadata Service Exploitation

AWS Instance Metadata Service (IMDS) provides critical data to EC2 instances. Applications query it to discover their instance ID, availability zone, security groups, and most critically, IAM role credentials.

IMDSv1 exploitation is straightforward. The original metadata service accepts GET requests without additional validation:

GET http://169.254.169.254/latest/meta-data/

This returns a directory listing of available metadata categories. The security-credentials path contains IAM role credentials:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/

This returns the role name. Querying that role name returns temporary credentials:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]

The response includes AccessKeyId, SecretAccessKey, and SessionToken. These credentials provide whatever permissions the IAM role grants. If the role has broad permissions (common in development or loosely configured production environments), the attacker gains extensive AWS access.

A web application penetration testing engagement demonstrated this pattern. A document conversion service accepted URLs for documents to convert. The application ran on EC2 with an IAM role granting administrator access to simplify development. SSRF allowed querying the metadata service, extracting credentials with AdministratorAccess, and compromising the entire AWS account.

IMDSv2 and bypass techniques introduced additional protections. AWS recognized metadata service abuse and released IMDSv2 requiring a session token. Applications must first request a token via PUT, then include it in subsequent metadata queries:

PUT http://169.254.169.254/latest/api/token

X-aws-ec2-metadata-token-ttl-seconds: 21600

This returns a token. Subsequent requests include it:

GET http://169.254.169.254/latest/meta-data/

X-aws-ec2-metadata-token: [token]

IMDSv2 prevents simple SSRF exploitation because most SSRF vectors can't perform PUT requests or add custom headers. However, vulnerabilities persist if applications support these capabilities or if IMDSv1 remains enabled (it's backward compatible).

User data and instance metadata expose additional sensitive information. The user-data endpoint contains initialization scripts that often include secrets:

GET http://169.254.169.254/latest/user-data

These scripts might contain database passwords, API keys, or configuration secrets. Developers embed credentials in user data for convenience during instance launch, creating permanent credential exposure through metadata service.

ECS task metadata provides credentials for containerized applications. ECS tasks receive IAM roles through a different metadata endpoint. The AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable points to credentials:

GET http://169.254.170.2[relative-uri]

This returns temporary credentials for the task's IAM role. SSRF in containerized applications on ECS extracts these credentials similarly to EC2 instances.

Azure Metadata Service Attacks

Azure Instance Metadata Service (IMDS) follows similar patterns to AWS but with Azure-specific endpoints and authentication mechanisms.

Azure IMDS structure uses versioned API calls to the same link-local address:

GET http://169.254.169.254/metadata/instance?api-version=2021-02-01

Metadata: true

The Metadata: true header requirement provides minimal SSRF protection. Attackers need SSRF vectors that allow custom headers. Many do: server-side request libraries, webhook implementations, or proxy services.

Managed Identity credential theft targets Azure's mechanism for granting cloud permissions to resources. Managed Identities eliminate credential management by providing automatic authentication to Azure services. The metadata service issues access tokens:

GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

Metadata: true

This returns an OAuth access token with permissions defined by the Managed Identity's role assignments. An application with Contributor access provides tokens that can modify Azure resources. A Reader role still exposes sensitive configuration and data.

Azure Cloud Shell and internal services expose additional attack surface. Cloud Shell uses a metadata service at http://169.254.169.254/metadata/identity/info. Azure App Service instances have environment variables pointing to credential endpoints. Each creates unique SSRF exploitation paths specific to Azure's architecture.

A SaaS security assessment of an Azure-hosted application revealed SSRF in a webhook processing feature. The application made POST requests to user-supplied URLs, allowing custom headers. Attackers queried the Azure metadata service, obtained Managed Identity tokens with subscription-level access, and could enumerate all resources, read configuration secrets, and modify deployed applications.

Google Cloud Platform Metadata Exploitation

GCP's metadata service uses both metadata.google.internal and 169.254.169.254. The service structure differs from AWS and Azure but the exploitation principles remain consistent.

GCP metadata format uses a path-based API:

GET http://metadata.google.internal/computeMetadata/v1/

Metadata-Flavor: Google

The Metadata-Flavor: Google header requirement prevents accidental metadata queries but doesn't stop SSRF with header control.

Service account credentials accessible through metadata provide GCP authentication:

GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Metadata-Flavor: Google

This returns an OAuth2 access token scoped to the service account's permissions. GCP service accounts often have broad permissions across projects, making stolen tokens highly valuable.

Project-level metadata and secrets store configuration data accessible through metadata service:

GET http://metadata.google.internal/computeMetadata/v1/project/attributes/

Metadata-Flavor: Google

Project metadata might contain database connection strings, API keys, or other secrets that developers store for convenience. The metadata service makes these universally accessible to all instances in the project, amplifying single SSRF impact.

GKE workload identity credentials extend metadata service access to Kubernetes pods. GKE Workload Identity binds Kubernetes service accounts to GCP service accounts. Pods query metadata for credentials automatically. SSRF in applications running on GKE can extract these credentials and pivot to GCP resources outside the cluster.

During API penetration testing, a GCP-hosted API demonstrated SSRF through a PDF generation feature. The API accepted HTML templates, converted them to PDF, and processed external resources referenced in the HTML. Attackers included <img src="http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"> in templates. The PDF generator's request included the Metadata-Flavor header (the library set it), returning service account tokens with project editor permissions.

Kubernetes Metadata and Service Discovery

Kubernetes introduces additional metadata services and internal APIs that SSRF can exploit within cluster environments.

Kubernetes API server access through SSRF targets the API endpoint accessible from pods. Default Kubernetes configurations mount service account tokens in pods at /var/run/secrets/kubernetes.io/serviceaccount/token. Applications that read local files might expose these. Combined with SSRF, attackers query the Kubernetes API:

GET https://kubernetes.default.svc/api/v1/namespaces

Authorization: Bearer [token]

This enumerates namespaces. Subsequent queries list pods, secrets, configmaps, and other resources. Permissions depend on the pod's service account RBAC bindings.

Kubelet API exploitation targets the node agent running on each Kubernetes node. The kubelet exposes APIs on port 10250. If not properly secured, SSRF can query:

GET https://[node-ip]:10250/pods

This returns all pods running on that node, including environment variables, mounted secrets, and container configurations.

Service discovery through DNS enables SSRF to identify internal services. Kubernetes creates DNS records for services: [service-name].[namespace].svc.cluster.local. SSRF payloads probe these to map internal services and identify additional attack targets.

A containerized application with SSRF running in GKE demonstrated the complete attack chain during offensive security testing. Initial SSRF queried GCP metadata for service account tokens. Those tokens listed GKE clusters. The attacker used cluster credentials to query the Kubernetes API, discovered secrets containing database credentials, and ultimately accessed production databases from the cluster network.

IAM Role Assumption and Cross-Account Access

Stolen cloud credentials from metadata services enable privilege escalation and lateral movement through IAM role assumption.

AWS role assumption using stolen credentials allows accessing additional accounts and roles. If the compromised IAM role has sts:AssumeRole permissions, attackers chain credentials:

aws sts assume-role --role-arn arn:aws:iam::TARGET-ACCOUNT:role/TargetRole --role-session-name attack

This returns new credentials for the target role. Organizations with cross-account trust relationships become vulnerable to complete multi-account compromise from single SSRF vulnerabilities.

Azure role-based access and subscription hopping follows similar patterns. Managed Identity tokens with appropriate permissions can manage resources across subscriptions. Attackers enumerate subscriptions, identify high-value resources, and use stolen tokens to access them.

GCP service account impersonation allows compromised service accounts with appropriate permissions to impersonate other service accounts:

gcloud iam service-accounts add-iam-policy-binding [target-sa]@[project].iam.gserviceaccount.com --member=[compromised-sa]@[project].iam.gserviceaccount.com --role=roles/iam.serviceAccountTokenCreator

This chains access from the initially compromised account to more privileged ones.

SSRF Detection Techniques

Identifying SSRF during application security assessment requires testing URL inputs, webhooks, file fetching features, and any functionality that makes server-side requests.

URL parameter testing starts with obvious input vectors. Any feature accepting URLs warrants SSRF testing: image processors, document converters, webhooks, URL previewers, RSS feed readers, XML parsers with external entity support.

Test with metadata service addresses directly:

• http://169.254.169.254/latest/meta-data/
• http://metadata.google.internal/computeMetadata/v1/
• Internal IP ranges: http://10.0.0.1/, http://192.168.1.1/, http://172.16.0.1/

Bypass techniques for filtering target common protection mechanisms. Applications might block metadata service IPs. Bypasses include:

• Decimal IP encoding: http://2852039166/ (decimal for 169.254.169.254)
• Hexadecimal: http://0xa9fea9fe/
• Octal: http://0251.0376.0251.0376/
• Domain redirection: Register domain pointing to 169.254.169.254
• DNS rebinding: Domain initially resolves to safe IP, then changes to metadata service
• URL encoding: http://169.254.169.254 becomes http://169.254.169.254%00

Blind SSRF detection applies when responses aren't directly visible. Use out-of-band techniques:

• Burp Collaborator or similar services
• DNS exfiltration through subdomain queries
• Timing attacks observing response delays
• Error message differences between accessible and blocked endpoints

Protocol smuggling exploits URL parsing inconsistencies. Different URL libraries parse protocols differently. Submit gopher://169.254.169.254/, dict://169.254.169.254/, or file:///etc/passwd to test protocol support. Some parsers support unexpected protocols that bypass filters.

Cloud-Specific SSRF Attack Chains

SSRF in cloud environments enables complete attack chains from initial access to full infrastructure compromise.

Metadata to credentials to resource access represents the fundamental chain. SSRF extracts credentials from metadata services. Those credentials access cloud resources: S3 buckets, databases, key vaults, storage accounts. Data exfiltration, modification, or deletion follows.

Secrets extraction from managed services targets cloud-native secret storage. Stolen credentials with appropriate permissions read secrets from AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. These secrets often include database credentials, API keys, or certificates enabling deeper access.

Lambda and serverless function invocation uses stolen credentials to invoke functions. AWS Lambda functions might have environment variables containing additional secrets or might perform privileged operations when invoked. SSRF to credentials to Lambda invocation chains into application logic exploitation.

Network scanning and internal service discovery uses cloud instances as pivot points. SSRF combined with curl or wget enables scanning internal networks, identifying databases, admin panels, or other services not exposed externally. Cloud environments often have less restrictive internal security, assuming network isolation provides protection.

A financial services cloud security assessment revealed this complete chain. SSRF in a customer-facing API provided EC2 metadata service access. The stolen IAM credentials had permissions to list Lambda functions. Function names revealed their purposes. Environment variables for database functions contained RDS credentials. The attacker chain progressed: SSRF → credentials → Lambda enumeration → environment variables → database access → customer data exfiltration.

Container and Serverless SSRF Patterns

Modern cloud architectures using containers and serverless functions create unique SSRF attack surfaces.

Docker socket exposure in containerized applications provides devastating access. If containers mount the Docker socket (/var/run/docker.sock), SSRF can interact with it through file:// protocol or if the application provides file access:

GET file:///var/run/docker.sock/containers/json

This lists running containers. Creating new containers or executing commands in existing ones follows, effectively granting host-level access.

Lambda function environment and execution role makes Lambda-hosted applications high-value SSRF targets. Lambda functions execute with IAM roles. SSRF in Lambda functions accesses metadata services for credentials. The execution role often has broad permissions across AWS services.

Cloud Run and container instances in GCP follow similar patterns. Cloud Run services receive service account credentials through metadata. SSRF extracts these credentials despite Cloud Run's managed nature.

Fargate task metadata on AWS ECS Fargate provides credentials through a task-specific metadata endpoint. The endpoint path appears in AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable. SSRF that can read environment variables or is documented in application logs enables credential theft.

Defense in Depth Strategies

Preventing SSRF in cloud environments requires multiple defensive layers addressing both the vulnerability and its exploitation path.

Input validation and allowlisting is the primary control. Validate all URLs before processing. Implement allowlists of permitted domains or IP ranges. Block private IP ranges (RFC 1918), link-local addresses (169.254.0.0/16), and localhost. Validate protocols, allowing only https:// for external resources.

Network segmentation and security groups limit metadata service access. Cloud security groups can't block metadata services (they're necessary for normal operations), but network ACLs and host-based firewalls can restrict which processes can query them.

IMDSv2 enforcement on AWS prevents basic SSRF exploitation. Require IMDSv2 for all instances. The session token requirement blocks most SSRF vectors. Configure through instance metadata options:

aws ec2 modify-instance-metadata-options --instance-id i-xxx --http-tokens required

Least privilege IAM roles minimize stolen credential impact. Grant only permissions absolutely necessary. An image processing service needs S3 read/write for specific buckets, not administrator access. Regularly audit and tighten permissions.

Service mesh and sidecars in Kubernetes environments can intercept and filter outbound requests. Service meshes like Istio enable egress filtering, preventing pods from accessing metadata services or unauthorized external endpoints.

Web Application Firewall rules detect and block SSRF attempts. AWS WAF, Azure Application Gateway, or Google Cloud Armor can filter requests to metadata service IPs or suspicious URL patterns. However, WAFs provide defense in depth, not primary protection.

Monitoring and alerting detects exploitation attempts. Log and alert on metadata service queries from applications, unusual IAM credential usage patterns, or cross-account assume role operations. AWS CloudTrail, Azure Activity Log, and GCP Cloud Audit Logs capture these events.

During continuous penetration testing, defense validation confirms that SSRF protections actually work. Test that allowlists block metadata service access. Verify that IMDSv2 prevents credential theft. Ensure monitoring generates alerts on SSRF attempts.

Testing and Remediation

Security teams must actively test for SSRF and validate remediation effectiveness.

Automated scanning using tools like Burp Suite, OWASP ZAP, or Nuclei catches basic SSRF vulnerabilities. These tools probe URL inputs with metadata service addresses and common bypass techniques. However, automated tools miss business logic SSRF in complex features.

Manual testing methodology for cloud SSRF includes:

1. Identify all URL input points
2. Test direct metadata service access
3. Attempt common bypasses (encoding, DNS tricks)
4. Test file:// protocol for local resource access
5. Verify cloud-specific endpoints (ECS task metadata, GKE metadata)
6. Attempt credential extraction from responses
7. Validate stolen credentials work for cloud resource access

Remediation verification confirms fixes prevent exploitation. Don't just patch the specific test case. Ensure comprehensive URL validation covers all bypass techniques. Test that metadata service access fails even with creative encoding or protocol manipulation.

Code review for SSRF patterns identifies vulnerable code before deployment. Look for HTTP client usage accepting user input without validation. Review webhook implementations, file fetching code, and API proxies. Static analysis tools can flag potential SSRF, but expert review catches logic flaws tools miss.

Cloud Provider Security Features

Major cloud providers offer security features specifically addressing SSRF and metadata service abuse.

AWS IMDSv2 as previously discussed requires PUT requests and session tokens. Organizations should enforce it account-wide using AWS Config rules or Service Control Policies preventing instance launch without IMDSv2 requirement.

Azure's Managed Identity restricted endpoints limit token audience. Request tokens scoped to specific Azure services rather than broad management tokens. This limits stolen token utility.

GCP Organization Policy constraints can restrict metadata service access or require service account impersonation logging. These policies apply across the organization, preventing exceptions that create vulnerability.

Cloud Security Posture Management tools from providers and third parties continuously assess configurations for SSRF risk factors: IMDSv1 enabled instances, overly permissive IAM roles, missing network controls.

Industry-Specific Considerations

Different industries face unique SSRF risks based on their cloud architecture and data sensitivity.

Financial services must protect transaction systems and customer financial data. SSRF enabling credential theft leads to fraud, data breaches, and regulatory violations. PCI DSS requirements mandate network segmentation that also helps contain SSRF impact.

Healthcare protects PHI subject to HIPAA. SSRF exposing patient records creates regulatory liability and patient safety concerns. Healthcare applications often integrate with multiple systems, creating numerous URL input vectors.

SaaS platforms serving multiple tenants must prevent SSRF from enabling cross-tenant access. Proper tenant isolation combined with SSRF prevention protects all customers.

A healthcare fintech security assessment found SSRF in a telemedicine platform's prescription integration. The feature fetched pharmacy data from external URLs. SSRF accessed Azure metadata, provided Managed Identity tokens, and enabled access to patient health records across the entire system.

Frequently Asked Questions

1. How does SSRF differ between on-premise and cloud environments?

On-premise SSRF typically enables internal network scanning or accessing internal services. Cloud SSRF adds metadata service access, providing temporary credentials with cloud-wide permissions. The impact scales from internal reconnaissance to complete infrastructure compromise. Cloud environments also have more implicit trust in network isolation, making SSRF more dangerous.

2. Can IMDSv2 completely prevent metadata service exploitation?

IMDSv2 significantly raises the bar by requiring PUT requests and custom headers, which most SSRF vulnerabilities can't satisfy. However, SSRF in applications that use HTTP libraries supporting arbitrary methods and headers can still exploit IMDSv2. Additionally, IMDSv1 fallback support and legacy instances may still be vulnerable if not properly configured.

3. What's the best way to test for SSRF without accessing production metadata?

Use dedicated testing environments that mirror production. Create test instances with limited IAM roles. Test SSRF against metadata service endpoints to validate protections work. Monitor logs to confirm SSRF attempts are detected. Alternatively, use allowlist validation in code reviews before testing proves effectiveness.

4. How do I know if my cloud instances are vulnerable to SSRF-based credential theft?

Audit applications for URL input features: webhooks, image processors, document converters, RSS readers. Review HTTP client usage in code. Check IMDSv2 configuration on EC2 instances. Test metadata service access from application contexts. Review IAM role permissions to understand stolen credential impact.

5. What should I do if I discover SSRF in a production cloud application?

Immediately assess whether metadata service access is possible and what permissions the IAM role has. If credentials could be compromised, rotate them. Implement blocking at network layer if possible. Deploy code fixes expeditiously. Review audit logs for exploitation indicators. Perform incident response if you find evidence of actual compromise.