Backstage Pass: Bypassing SSRF Filters via Open Redirects

Backstage has become the darling of platform engineering—a unified portal where developers can find everything from API docs to service catalogs. To make this magic happen, Backstage needs to be a bit of a librarian. It reaches out to GitHub, GitLab, S3 buckets, and generic URLs to fetch catalog-info.yaml files and documentation. This heavy lifting is handled by a component in @backstage/backend-defaults called the FetchUrlReader.

Here’s the catch: when you give a server the power to fetch arbitrary URLs, you are handing it a loaded gun pointed at your internal network. To prevent developers from accidentally (or maliciously) fetching http://169.254.169.254/latest/meta-data/iam/security-credentials/ and stealing your AWS keys, Backstage implements a config called backend.reading.allow. It's essentially a bouncer list. You tell it: "Only talk to github.com and internal-docs.com."

But in CVE-2026-24048, we found out that the bouncer was only checking IDs at the front door. Once the request was inside, it could sneak out the back window to anywhere it pleased.

The vulnerability stems from a classic developer oversight: trusting the default behavior of high-level APIs. The FetchUrlReader utilized a standard fetch implementation (specifically node-fetch or similar polyfills in the Node environment). By default, when fetch receives a 3xx HTTP redirect status code (like 301 Moved Permanently or 302 Found), it automatically follows the Location header to the new URL.

In the vulnerable versions of Backstage, the code looked something like this:

1. Check: Is user_provided_url in the allow list? Yes? Proceed.
2. Fetch: Execute fetch(user_provided_url).
3. Redirect: The server at user_provided_url says "Go to evil_internal_url".
4. Follow: The fetch client says "Okay!" and requests evil_internal_url.

The security check happened only at step 1. The automatic redirect at step 4 completely bypassed the allowlist validation. It's a classic Time-of-Check to Time-of-Use (TOCTOU) logic failure, applied to network hops.

Let's look at the smoking gun. The fix involved ripping out the automatic redirect handling and replacing it with a manual loop that treats every hop as a potential threat.

The Vulnerable Logic (Conceptual):

// Blindly trusts the fetch client to handle redirects
const response = await fetch(url, {
  // defaults follow redirects
});

The Fix (Commit 27f9061d...): In the patched version, the developers explicitly disabled automatic redirects and wrote a loop to validate the Location header of every 3xx response.

// The new, paranoid approach
const response = await fetch(url, {
    redirect: 'manual', // STOP! Don't move.
});
 
if (response.status === 301 || response.status === 302) {
    const location = response.headers.get('location');
    const newUrl = new URL(location, url);
 
    // The critical check that was missing:
    if (!isAllowed(newUrl)) {
        throw new Error(`Redirect to ${newUrl} is not allowed`);
    }
    // If allowed, loop and fetch the new URL...
}

This change shifts the security model from "Trust the chain" to "Zero Trust for every hop."

So, why is this rated Low severity (CVSS 3.5)? Because pulling this off requires the stars to align. You can't just feed Backstage http://evil.com because the initial check will block it. You need a pivot point.

To exploit this, an attacker needs two things:

1. A host that is already whitelisted in backend.reading.allow.
2. A way to make that allowed host redirect to a target of the attacker's choosing (an Open Redirect vulnerability).

The Attack Chain: Let's assume the victim has allowed trusted-partner.com in their Backstage config. The attacker discovers that trusted-partner.com/login?next=... has an open redirect.

1. Trigger: The attacker registers a catalog entity pointing to https://trusted-partner.com/login?next=http://169.254.169.254/latest/meta-data/.
2. Validation: Backstage checks the URL. trusted-partner.com is on the list. Green light.
3. The Pivot: Backstage requests the URL. The partner server responds: HTTP/1.1 302 Found -> Location: http://169.254.169.254/....
4. The Loot: The unpatched FetchUrlReader blindly follows the redirect to the AWS metadata service. Backstage reads the credentials and displays them (or stores them) as if they were valid catalog data.

While the prerequisites are high, the impact in a cloud environment is catastrophic—total account compromise via metadata credentials.

The mitigation is straightforward: upgrade @backstage/backend-defaults to a patched version (0.12.2, 0.13.2, 0.14.1, or 0.15.0+). The patched component now manually iterates through redirects (up to 5 hops), validating the destination URL against the config at every single step.

If you cannot upgrade immediately, your defense-in-depth strategy is Egress Filtering. Your Backstage backend shouldn't be able to talk to the metadata service (169.254.169.254) or sensitive internal subnets anyway. A simple firewall rule dropping outbound traffic to RFC1918 addresses (excluding necessary services) renders this exploit inert, regardless of the application vulnerability.