SSRF Exploitation in Cloud-Hosted SaaS Applications

In cloud-hosted SaaS applications, SSRF stops being a contained web bug the moment it touches the metadata service. What starts as a single URL-fetching feature, an image resizer, a webhook handler, becomes a pivot mechanism that hands an attacker IAM credentials, internal network access, and in the worst cases, the entire cloud account. Understanding that chain end to end, not just the injection point, is what separates a patch from an actual fix.

Why SSRF is structurally different in cloud-hosted environments

SSRF happens when an attacker tricks a server into making an HTTP request to a destination of the attacker's choosing. The server becomes an unwitting proxy, and it does so with elevated internal network access and a level of implicit trust no external attacker could otherwise touch.

On a traditional on-premises server, that's still bad, but the damage is roughly bounded by whatever internal network the server can see. When that same server moves into the cloud, the blast radius stops being just the network. It includes the cloud control plane itself.

The asymmetry here makes this so dangerous. Cloud metadata services (AWS at 169.254.169.254, Azure at that same address, GCP at metadata.google.internal) are reachable from any instance running inside the environment, but not from the public internet. Engineers built entire security models on that assumption: if you can't reach it from outside, it's safe. SSRF wrecks that assumption completely, because it doesn't ask the outside world to reach the metadata service. It makes the server reach it from the inside, on the attacker's behalf.

Worse, these endpoints usually require no authentication for basic queries. They trust that only legitimate workloads can even get to them, and SSRF sidesteps that trust boundary entirely. And this isn't some rare edge case reserved for advanced red teams. Data cited by the Cloud Security Alliance, sourced from Sweet Security, found that 80% of customers had experienced SSRF attack attempts in their cloud environments Cloud Security Alliance — Defending Against SSRF Attacks. That's routine exploitation, not a hypothetical. SSRF appears at #5 in OWASP Top 10:2025 (retained from 2021 addition) because the underlying conditions (applications fetching URLs on user behalf, reachable metadata endpoints, lax default segmentation) have not changed OWASP Top 10:2025 — Injection.

The injection points: where SSRF enters SaaS applications

Almost every SSRF vulnerability starts life as a completely ordinary feature. None of these sound dangerous on their own.

Take the appsecure.security example: a developer builds an image processing service on AWS EC2. Users submit a URL, the application fetches the image, resizes it, and returns the result. Clean architecture, nothing unusual about it. Then a researcher submits http://169.254.169.254/latest/meta-data/iam/security-credentials/ instead of an image link, and the application, being obedient, fetches it anyway.

A separate Azure-hosted assessment found the same pattern in a webhook processing feature. The application made POST requests to user-supplied URLs, and it allowed custom headers on those requests. That header-forwarding capability turns out to matter quite a bit, because several cloud metadata endpoints require a specific header to respond, and an application that forwards arbitrary headers will forward that one too.

This isn't just legacy web app territory either. CVE-2026-44578, rated High with a CVSS 3.1 score of 8.6, affects self-hosted Next.js applications through crafted WebSocket upgrade requests, where the built-in Node.js server can be tricked into proxying connections to destinations the attacker picks (Vercel-hosted deployments aren't affected). And CVE-2026-64849, an unauthenticated flaw carrying a CVSS score of 9.3, sits in MLflow's model-registry webhooks, letting an attacker proxy requests through the Tracking Server straight to internal cloud metadata endpoints.

Looking across all of these, a pattern jumps out: the injection point is almost never exotic code. It's a legitimate, user-facing feature, and the vulnerability is missing validation on what URLs the application is even allowed to resolve. AI agents and MCP (Model Context Protocol) integrations are shaping up to be the newest version of this same story, since LLM-connected tools now make server-side HTTP requests based on model-generated or user-supplied input, often without the validation discipline older HTTP client code has slowly accumulated.

Exploitation doesn't require the attacker to see a response. In blind SSRF, the application never reflects the fetched content back, so the attacker leans on out-of-band techniques like DNS callbacks or timing analysis. The request still lands on the internal target either way. The primary attack surface consists of URL-fetching features: image processors that accept user-supplied URLs, webhook handlers that POST to user-configured endpoints, document converters that fetch remote files, link preview generators, PDF renderers, and integration connectors.

The metadata endpoint exploitation path, step by step

Once an attacker finds an SSRF-capable endpoint in a cloud environment, the metadata service is the obvious next stop. On AWS running IMDSv1, there's no session token requirement at all. An attacker submits http://169.254.169.254/latest/meta-data/ and gets back a directory listing, then queries /iam/security-credentials/ for the role name, then queries that role name directly and receives the AccessKeyId, SecretAccessKey, and SessionToken, the exact same credentials the application itself uses.

There's a second credential store sitting right next to it. The user-data endpoint, http://169.254.169.254/latest/user-data, returns whatever initialization script launched the instance, and developers routinely embed database passwords and API keys in those scripts for convenience at launch time. Same SSRF channel, second payoff.

Containerized workloads aren't spared either. ECS tasks receive credentials through the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable, and an SSRF request against http://169.254.170.2[relative-uri] extracts the task's IAM role credentials just as cleanly. So the attack surface isn't limited to EC2 instances, it covers containerized SaaS applications running the exact same way. On GCP, the metadata endpoint at http://metadata.google.internal/computeMetadata/v1/ Requires a Metadata-Flavor: Google header. The Azure webhook case that allowed custom headers turned out to be so dangerous because of that. In that case, the attacker walked away with Managed Identity tokens carrying subscription-level access, enough to enumerate every resource, read configuration secrets, and modify deployed applications.

IMDSv2 was built specifically to close this gap. It requires a PUT request to obtain a session token before any metadata query goes through, and most naive SSRF vectors simply can't perform a PUT or inject a custom header. But if the vulnerable feature does support those capabilities, as some webhook integrators do, IMDSv2 offers no protection at all. And IMDSv1 is still enabled by default on many instances for backward compatibility unless someone explicitly turns it off.

None of this is theoretical. The Capital One breach in 2019 is the case that put this exploitation chain on the map: an attacker exploited SSRF in a misconfigured WAF on AWS, queried the IMDSv1 endpoint, retrieved temporary IAM credentials tied to the EC2 role, and used those credentials to reach an S3 bucket full of personal data. A separate pen test found a document conversion service running on EC2 with an IAM role granted AdministratorAccess "to simplify development." SSRF pulled those credentials straight out, and the entire AWS account went with them. In that case, the catastrophe wasn't the SSRF flaw by itself, it was IAM over-permissioning stacked on top of it.

Credential theft through this path is fast, and it can be automated end to end. What the attacker does next depends entirely on how much that stolen role can actually do.

Lateral movement and escalation once credentials are in hand

Stolen IAM credentials don't stay confined to the vulnerable application. Once an attacker has them, they're used entirely outside it, through the AWS CLI or direct API calls issued from the attacker's own infrastructure. From there, everything hinges on role scope.

Broad permissions, an AdministratorAccess role or an overly permissive production role, let an attacker read every S3 bucket, enumerate EC2 instances, reach into RDS databases, pull secrets out of Secrets Manager, rewrite IAM policies, or pivot to other accounts entirely through cross-account role assumptions. Narrowly scoped permissions bound the damage to whatever that role actually needs to function. Least privilege works as containment regardless of whether the SSRF itself gets exploited.

The metadata path isn't the only target either. SSRF can reach internal microservices and administrative interfaces that were never meant to face the internet: internal APIs, management consoles, unauthenticated internal endpoints, all separate from the metadata angle entirely. The MLflow case shows how quickly this gets operationalized. Attackers were scanning for exposed MLflow instances within hours of CVE-2026-64849 being assigned on August 17, 2026, targeting well-known internal IP addresses and services to pull out credentials and secrets. This is industrial-scale scanning, driven by an automated attacker sweeping targets at volume.

Detection has its own blind spot here. Once a token is in an attacker's hands, its use looks exactly like legitimate API activity. That gap matters more given the trend line: SSRF attacks surged 452% between 2023 and 2024, appsecbrief.com reports, and that growth turns lateral movement from SSRF into a standard playbook rather than a novelty AppSec Brief — SSRF Prevention Guide 2026. For healthcare SaaS applications handling PHI, there's a regulatory tail on top of the technical one. HIPAA liability kicks in the moment SSRF exposes patient records, and lateral movement into a database or storage bucket holding regulated data turns a technical finding into a reportable breach.

Application-layer URL validation alone does not close the risk

Knowing the chain matters, but closing it takes more than fixing the one parameter that let the first request through. Most teams reach for application-layer validation first, but it's the most fragile, because the bypasses are numerous and well documented.

DNS rebinding is one of the cleanest examples: a domain resolves to a public IP the moment it's validated, then rebinds to an internal IP by the time the application actually makes the request. IP encoding is another. Allowlist checks written against the literal string "169.254.169.254" miss the decimal form (2130706433 for 127.0.0.1), hex and octal representations, and IPv6 forms of the same address OWASP Top 10:2025 — Injection. Open redirects on otherwise trusted domains let an attacker supply a whitelisted URL that quietly redirects to the metadata service. And URL parser inconsistencies mean the validator and the HTTP client can disagree on what a malformed URL actually points to, since different libraries parse the same string differently.

That's the whole reason SSRF has stayed on the OWASP list even as developer awareness of it has climbed. The fix was never a single regex check, the fragility is structural. Blind SSRF makes the problem worse still: even when the application never shows the attacker a response, the request still fires, and an attacker running out-of-band DNS callback infrastructure can confirm an internal endpoint is reachable without seeing a byte of the reply. The MLflow case is a good illustration of how stubborn this gets. watchTowr noted that CVE-2026-64849 bypassed a prior fix specifically because of how it handled web redirects: an earlier patch existed and simply wasn't enough. Incomplete SSRF fixes are a documented pattern.

Validation still belongs in the stack. It just can't be the only layer, and it needs network-layer controls and IAM constraints sitting alongside it to mean anything.

The defensive layers that contain SSRF in cloud environments

Layer one is application validation, necessary but never sufficient on its own. Allowlisting permitted destinations beats denylisting known bad ones, since denylist bypasses are too numerous to keep up with. Resolve the destination URL at validation time, then re-validate the resolved IP against that allowlist, blocking RFC 1918 ranges, 169.254.0.0/16, and loopback addresses. Disable HTTP redirects in the client library, or re-validate wherever a redirect points before following it. And never pass a raw, user-supplied string straight into an HTTP client, parameterize what the application is allowed to fetch.

Layer two is enforcing IMDSv2 and turning IMDSv1 off entirely. IMDSv2 requires a PUT request for a session token before any metadata query goes through, and most SSRF vectors simply can't issue a PUT or inject the header that requires. IMDSv1 is still on by default on plenty of instances for backward compatibility, so disabling it explicitly removes the simplest credential-theft path no matter what SSRF bugs exist upstream in the application. This is a platform-layer control, and it protects the environment without demanding the application code be flawless.

Layer three is IAM least privilege. The AdministratorAccess case makes the cost of skipping this layer obvious: scope every IAM role down to the minimum the workload actually needs. Credential theft against a tightly scoped role yields an attacker almost nothing useful, and this layer limits blast radius when everything above it fails.

Layer four is network egress control. Internal service-to-service traffic should require an explicit network policy, because default-allow internal networking turns every SSRF bug into a free internal service scanner. A policy that blocks application-tier instances from reaching the metadata endpoint except through IMDSv2 defends against credential theft regardless of how good or bad the application code turns out to be.

Layer five is detection. The Sweet Security and CSA case again illustrates the gap: without application-level detection and response sitting alongside cloud detection and response, the team only saw machine names and API Gateway alerts in CloudTrail, nothing about origin, success, or whether the traffic was internal or external. Correlating those two signal sources is what actually surfaces the full attack path. Monitor for any request to 169.254.169.254 or equivalent metadata ranges coming from application processes, since that should never happen in a properly hardened environment. And audit IAM credential usage for anomalous API calls, particularly from unexpected source IPs or at odd hours, since stolen temporary credentials used from an attacker's own infrastructure will appear in CloudTrail if the alerting is configured to catch it.

For teams running self-hosted Next.js, the remediation for CVE-2026-44578 is concrete and immediate: upgrade to 15.5.16 or 16.2.5 or later (Vercel-hosted deployments were never affected). The GitHub advisory for CVE-2026-44578 went out May 6, 2026, with NVD publishing its own entry a week later on May 13, 2026; self-hosted Next.js users should upgrade to 15.5.16 or 16.2.5 or later, while Vercel-hosted deployments are not affected.

How a whitebox pen test finds SSRF that scan

Automated scanners look for a URL parameter, a payload, or a reflected response. They're built to catch the SSRF that behaves the way a scanner expects. What they miss is the SSRF that only exists once someone reads the actual source, the webhook handler that forwards arbitrary headers, the internal library that resolves a redirect differently than the validator upstream assumed, the IAM role sitting one policy attachment away from AdministratorAccess.

A whitebox pen test starts from the code and the cloud configuration together, tracing every place a server-side request gets built from user input, then checking what that server can actually reach once the request fires, including the metadata service, an internal microservice, or an unauthenticated admin console. It maps IAM role permissions against what a stolen credential could actually do, and checks whether the SSRF exists. Finding a URL that shouldn't be fetchable is different from finding the full chain that turns a single fetch into account-wide compromise, and a black-box scan, by design, never sees that chain.