Unauthenticated SSRF Enables Cloud Metadata Exfiltration and Internal Network Access
The Risk
An endpoint on a cryptocurrency platform's website required no login and could be used to access the company's internal network and cloud infrastructure. Through this single endpoint, an attacker could have retrieved cloud account credentials, mapped out 14 internal servers, and reached 11 cloud management services. This is the equivalent of leaving an unlocked door from the public internet straight into the company's server room.
The Vulnerability
An API endpoint designed to forward messages to an internal chat service accepted a webhookUrl parameter without authentication or destination validation. The backend made an HTTP request to the provided URL and reflected the full response body back in JSON.
No origin checks, no URL allowlisting, and no restrictions on the destination address. The endpoint was completely unauthenticated, meaning anyone on the internet could trigger arbitrary server-side HTTP requests.
The Attack
First test: pointing the URL at localhost returned ECONNREFUSED 127.0.0.1:80, confirming the request was made server-side rather than client-side. The error message itself leaked internal network behavior.
Second test: pointing the URL at an external echo service reflected the backend's real IP address and User-Agent header (node-fetch/1.0), confirming the server was making outbound HTTP requests with the response body fully reflected to the caller.
Cloud Metadata Exfiltration
The cloud instance metadata service (IMDS) only accepts GET requests, but the vulnerable endpoint sent POST requests. Direct requests to the metadata IP returned errors.
Bypass: using an external redirect service to issue a 302 redirect. The server followed the redirect, converting the POST into a GET against the metadata endpoint. The full instance identity document was reflected back, including the account ID, instance ID, region, private IP address, and instance type.
A follow-up check confirmed an IAM role was attached to the instance. If the role name were discovered (through additional metadata paths or error messages), temporary cloud credentials including access key, secret key, and session token would be directly exfiltrated through the same SSRF.
Internal Network Mapping
Using the private IP discovered from the metadata response as a starting point, a sweep of the internal subnet revealed 14 live hosts. The services discovered included:
- Go microservices exposing health check and debug endpoints
- Prometheus metrics endpoints leaking internal performance data
- Nginx reverse proxies with status pages accessible
- Kubernetes worker nodes with the Kubelet API reachable
- The Kubernetes API server itself, accessible from the SSRF
Beyond the internal VPC, 11 cloud service APIs were also reachable. Object storage, compute, database, container registry, message queue, and other control plane endpoints all returned valid API responses when accessed through the SSRF. This opened a path for lateral movement across the entire cloud environment.
The Impact
- Full-read SSRF with complete response reflection
- Cloud instance metadata exfiltration, including account ID and infrastructure topology
- IAM credential theft path, one step from full cloud API access
- Complete internal VPC network map with 14 live hosts identified
- Kubernetes cluster accessible, including both Kubelet and API server
- 11 cloud control plane APIs reachable for lateral movement
Remediation
- Add authentication to the webhook endpoint
- Allowlist webhook URLs to the intended chat service domain only
- Block internal destinations including loopback, RFC1918, link-local, and cloud metadata address ranges
- Disable or re-validate HTTP redirects on server-side requests
- Stop reflecting response bodies back to the caller
- Enforce IMDSv2 (token-based metadata access) on all cloud instances