We Found an SSRF at a Client — What It Is, and Why It Matters

We found a Server-Side Request Forgery (SSRF) vulnerability at one of our clients. Since it is one of the more misunderstood bug classes, here is the short version of what it is and why it matters.

What is SSRF?

Server-Side Request Forgery is an attack that lets an attacker make the server send an HTTP request to anywhere they choose - from the server itself. That means from inside the internal network, with the server's own identity and network position.

The danger is not the outbound request on its own. It is where that request can reach: a server sitting behind the firewall can often talk to internal services, admin interfaces, and cloud metadata endpoints that were never meant to be exposed to the outside world. An SSRF turns the application into a proxy into your internal network.

Why it keeps happening

Anywhere an application fetches a URL on the user's behalf - a webhook, a “preview this link” feature, an image loaded from a remote address, an integration that calls a third party - is a candidate. If the destination is influenced by user input and the outbound request is not constrained, you have the ingredients for SSRF.

What to do about it

• Do not let user input decide, unchecked, where the server sends a request. Validate against an allow-list of destinations, not a block-list.
• Block access to internal ranges and to cloud metadata endpoints from the application's HTTP client.
• Treat the response carefully too - do not reflect internal responses back to the user.

On its own an SSRF can look academic. In a real assessment it is often the first link in a chain that ends somewhere far more serious.

What we actually found

The finding that prompted this was in a product that had folded AI capabilities into an existing feature for uploading files and analysing documents. The user could supply either a file to upload or an external URL, and the system would fetch the content, send it to an internal AI service, and return a summary. On the face of it a convenient feature - in practice it created a serious SSRF.

Because the url field never went through real validation, an attacker could send a request like this:

POST /api/analyze
{
"url": "169.254.169.254/latest/meta-data/iam/security-credentials/"
}

Instead of downloading a PDF, the internal service reached the cloud metadata service and returned valid credentials. From there it is a short road to storage buckets, internal secrets and API calls at the level of the whole cloud account. In further testing we saw that calls to internal services on 10.x and 172.x were accepted too, which allowed full movement across the infrastructure layer through what looked like a legitimate proxy.

This is a critical weakness that was born out of an entirely harmless feature request. Somebody wanted to allow document analysis from a URL instead of a file upload, and without thinking about it created a proxy that lets an attacker reach the core assets of the environment directly.

I first shared a version of this as a LinkedIn post on 2025-09-30. It is republished here, lightly edited, so it is easier to find and reference. — Erez Metula