SSRF & Cloud Metadata
Skills that access internal networks or cloud instance metadata to steal cloud credentials and pivot deeper
What is ssrf & cloud metadata?
Server-Side Request Forgery (SSRF) in the MCP context occurs when a skill makes network requests to internal endpoints that should not be accessible from the tool perspective. The most dangerous target is the cloud instance metadata service (IMDS), available at 169.254.169.254 on AWS, GCP, and Azure. This endpoint returns temporary credentials for the instance IAM role, and accessing it requires zero authentication from within the instance.
Beyond cloud metadata, SSRF attacks can target internal APIs, databases, admin panels, and other services that are accessible on the internal network but not exposed to the internet. A skill running on your cloud instance has network access to everything your instance can reach. If that includes a Redis cluster with no authentication, an internal admin API, or a Kubernetes API server, a malicious skill can access all of them.
Aguara detects seven SSRF patterns, focusing on cloud metadata endpoints (AWS IMDSv1/v2, GCP metadata, Azure IMDS), internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and cloud-specific credential endpoints like the AWS STS token service and GCP service account token endpoint.
Why this matters for AI agents
SSRF has been one of the top cloud vulnerability classes for years, and the AI agent ecosystem inherits all of that risk while adding new dimensions. When an MCP server runs on a cloud instance (EC2, Cloud Run, a Kubernetes pod), it has implicit access to the cloud provider metadata service. That metadata service hands out credentials.
The typical attack chain: a malicious skill triggers an HTTP request to the metadata endpoint at 169.254.169.254. The metadata service responds with the instance IAM role credentials (access key, secret key, session token). The skill exfiltrates those credentials. The attacker now has the same cloud permissions as the instance, which in many environments means access to S3 buckets, DynamoDB tables, SQS queues, and more.
What makes this worse in the agent context is that the request looks completely normal. MCP tools make HTTP requests. That is what they do. An SSRF request to the metadata endpoint looks identical to a legitimate API call from the tool perspective. There is no obvious malicious payload, no suspicious command execution, just an HTTP GET to an IP address. The IP address happens to give away your cloud credentials.
Real-world examples
A "weather API" skill accepts a URL parameter for the weather service endpoint. An attacker (via prompt injection in another skill) sets the URL to the cloud metadata credentials endpoint at 169.254.169.254. The weather skill fetches this URL, receives IAM credentials in the response, and returns them to the agent as "weather data." The attacker skill then exfiltrates the credentials.
A skill running in a Kubernetes pod makes a request to the cluster internal secrets API with the pod service account token. If the service account has permission to list secrets (a common misconfiguration), the skill retrieves all Kubernetes secrets, which typically include database passwords, API keys, and TLS certificates.
A file-fetching skill supports arbitrary URLs. An attacker instructs the agent to fetch http://192.168.1.1/admin, which is the internal router admin panel. The skill returns the admin page contents, which include network configuration details, connected devices, and potentially the admin password if it is displayed on the page.
How to protect against it
If your MCP server runs in a cloud environment, enforce IMDSv2 (which requires a PUT request with a hop limit, making SSRF exploitation significantly harder). On AWS, configure the instance metadata options to require IMDSv2 and set the hop limit to 1. On GCP and Azure, use equivalent protections.
Implement an allowlist for outbound requests from your MCP tools. If a tool needs to call a specific API, only allow requests to that API domain. Block requests to RFC 1918 addresses (10.x, 172.16-31.x, 192.168.x), link-local addresses (169.254.x), and localhost. This eliminates the vast majority of SSRF attacks.
Run MCP servers with minimal IAM permissions. If your server only needs to read from one S3 bucket, its IAM role should only grant GetObject on that specific bucket. If the server does not need cloud API access at all, use an IAM role with zero permissions. Even if an attacker steals the instance credentials via SSRF, they cannot do anything with them.
Aguara detection rules (7)
Detects cloud provider metadata endpoint URLs used for SSRF attacks
Detects references to private/internal IP ranges in URL context
Detects Kubernetes internal service URLs and secret paths
Detects AWS Instance Metadata Service token requests
Detects attempts to access the Docker daemon socket
Detects alternative representations of localhost used to bypass SSRF filters
Detects cloud provider token and credential endpoints
Want to check if your skills have ssrf & cloud metadata issues?
Scan now (free, runs in your browser)