See how an SSRF vulnerability reaches cloud metadata and steals IAM credentials, why URL filters keep failing, and the exact controls that stop SSRF for good.
What Is an SSRF Vulnerability?
SSRF stands for Server-Side Request Forgery. MITRE tracks it as CWE-918. The server fetches a URL it was given, but "does not sufficiently ensure that the request is being sent to the expected destination."
OWASP lists it as A10:2021 in the OWASP Top 10.
The pattern appears anywhere your app fetches a URL for a user:
- Webhook delivery and callback URLs
- Fetching images or files by link
- PDF and screenshot generators
- Link preview and import-from-URL features
None of these features are bugs. The bug is trusting the destination.
How SSRF Reaches Cloud Credentials
Every major cloud provider runs a metadata service on the link-local address 169.254.169.254. The internet cannot route to it. From inside the instance, it answers.
That service holds instance details and temporary credentials for the role attached to the machine.
The chain is short:
- The attacker finds a feature that fetches a URL.
- They point it at the metadata endpoint.
- Your server sends the request from inside the trust boundary.
- The response returns role credentials.
- The attacker replays them against your cloud API.
No password is stolen. No malware runs. If the role has broad permissions, the blast radius covers everything it can reach.
Real-World Example: The MLflow SSRF Flaw
MLflow is a widely used machine learning platform. In August 2026, an unauthenticated SSRF flaw in its Tracking Server was published as CVE-2026-64849, rated CVSS 9.3.
The flaw sat in webhook delivery. A validation function checked the URL, but the delivery code followed HTTP redirects without checking again. The unauthenticated test endpoint also returned the response body, making it a full-read SSRF. DNS rebinding worked too, because the resolved IP was never pinned.
It was reported privately in June 2026 and fixed in MLflow 3.15.0.
Attribution matters here. watchTowr did not find the bug. Its honeypot network saw attackers hitting exposed MLflow servers within hours of the CVE going public. They were trying to extract cloud credentials. That is confirmed exploitation, not a lab demo.
Why SSRF Filters Keep Failing
Most fixes block strings instead of destinations. Common bypasses:
- Redirects. The first URL passes the check. The 302 lands on the metadata IP.
- DNS rebinding. The hostname resolves to a public IP at validation, then an internal IP at request time.
- Alternate IP formats. Decimal, octal, and IPv6-mapped versions of the same address.
- Blocklist gaps. Teams block 169.254.169.254 and forget localhost or 10.0.0.0/8.
A blocklist must be right every time. An attacker needs one gap.
How to Prevent SSRF
Fix it in the application and in the network. One layer is not enough.
In the application:
- Use a positive allowlist for scheme, host, and port. Do not build denylists.
- Accept an ID or fixed value instead of a full URL where possible.
- Disable redirect following, or revalidate every hop.
- Resolve the hostname, then connect to that exact resolved IP. This stops rebinding.
- Never return the raw upstream response to the user.
In the network:
- Apply deny-by-default egress rules. Servers should reach only what they need.
- Segment services that fetch remote URLs.
At the metadata layer:
- AWS: Require IMDSv2. It needs a PUT to obtain a session token, then that token in a header on every GET. The default hop limit is 1, and PUT requests with an X-Forwarded-For header are rejected. A basic SSRF cannot complete that handshake.
- Azure: IMDS requires a Metadata: true header and rejects requests containing X-Forwarded-For.
- Google Cloud: The metadata server requires a Metadata-Flavor: Google header.
Then scope instance roles to least privilege, so a leaked token is not a master key.
What Should Security Testing Cover?
Ask your testers to prove these cases:
- Redirect-based bypass, not just direct hits on the metadata IP
- DNS rebinding against every URL-fetching feature
- Blind SSRF confirmed through out-of-band callbacks
- The real IAM permissions on the role, to measure blast radius
Testing only the direct payload gives false confidence.
Also Read: Best Cloud Penetration Testing Services
How OraSec Can Help
OraSec tests SSRF the way attackers use it. We map every URL-fetching feature, attempt redirect and rebinding bypasses, and check what the flaw actually reaches. You get a proven attack path and a fix plan, not a scanner alert.
Conclusion
An SSRF vulnerability is small in code and large in consequence. One unchecked URL can expose the credentials that hold your cloud together.
Treat every fetch as untrusted. Allowlist destinations, stop following redirects, pin resolved IPs, enforce IMDSv2, and cut your egress. Then have someone test it properly.
FAQs
Is SSRF the same as CSRF? No. CSRF abuses a user's browser session. SSRF abuses your server's network position.
Can a WAF stop SSRF? It helps against obvious payloads. It rarely stops redirect chains or DNS rebinding, because those look normal at the request layer.
Does IMDSv2 fully prevent SSRF? It blocks credential theft through simple SSRF. It does not fix the flaw. The same bug can still reach internal APIs and databases.
Is blind SSRF still dangerous? Yes. You may not see the response, but the request still runs. Attackers use out-of-band callbacks to confirm access.
How often should we test for SSRF? Test after any change to features that fetch URLs, and include it in your regular penetration testing cycle.
