CVE-2026-24048: Backstage Backend Defaults SSRF Vulnerability

CVE-2026-24048 Overview

CVE-2026-24048 is a Server-Side Request Forgery (SSRF) vulnerability in Backstage, an open framework for building developer portals. The vulnerability exists in the @backstage/backend-defaults package, specifically within the FetchUrlReader component. This component, used by the catalog and other plugins to fetch content from URLs, automatically follows HTTP redirects without proper validation against the URL allowlist.

An attacker who controls a host listed in backend.reading.allow can exploit this behavior to redirect requests to internal or sensitive URLs that are not on the allowlist, effectively bypassing the URL allowlist security control. While this vulnerability allows access to internal resources, it does not permit attackers to include additional request headers.

Critical Impact

Attackers can bypass URL allowlist restrictions to access internal resources and sensitive endpoints through controlled redirect chains.

Affected Products

• @backstage/backend-defaults versions prior to 0.12.2
• @backstage/backend-defaults versions prior to 0.13.2
• @backstage/backend-defaults versions prior to 0.14.1
• @backstage/backend-defaults versions prior to 0.15.0

Discovery Timeline

• 2026-01-21 - CVE-2026-24048 published to NVD
• 2026-01-21 - Last updated in NVD database

Technical Details for CVE-2026-24048

Vulnerability Analysis

This vulnerability is classified as CWE-918: Server-Side Request Forgery (SSRF). The FetchUrlReader component in Backstage is designed to fetch content from external URLs on behalf of the catalog and other backend plugins. To prevent unauthorized access to internal resources, Backstage implements a URL allowlist through the backend.reading.allow configuration.

However, the FetchUrlReader implementation automatically follows HTTP redirects (3xx responses) without validating whether the redirect destination is also on the allowlist. This creates a security gap where an attacker-controlled server on the allowlist can redirect requests to arbitrary internal endpoints.

The attack requires the attacker to have control over at least one host that is configured in the backend.reading.allow list. From there, the attacker can configure their server to respond with HTTP redirect responses pointing to internal infrastructure, cloud metadata endpoints, or other sensitive resources that would otherwise be blocked by the allowlist.

Root Cause

The root cause is the automatic following of HTTP redirects in the FetchUrlReader component without re-validating the redirect destination against the configured backend.reading.allow allowlist. The initial URL validation occurs before the request is made, but subsequent redirect URLs are not subjected to the same security checks.

Attack Vector

The attack is network-based and requires the attacker to control a host that is already trusted in the Backstage configuration. The attack flow involves:

1. The attacker identifies that their controlled domain is listed in backend.reading.allow
2. The attacker configures their server to respond with HTTP 302/301 redirects to internal URLs
3. When Backstage fetches content from the attacker's server, it automatically follows the redirect
4. The redirect target (an internal resource) is accessed despite not being on the allowlist
5. The response content may be returned to the attacker or used in further processing

This vulnerability allows reading internal resources but does not permit the inclusion of custom headers in the redirected request, which limits certain attack scenarios.

Detection Methods for CVE-2026-24048

Indicators of Compromise

• Unusual outbound HTTP requests from Backstage servers to internal IP ranges or cloud metadata endpoints (e.g., 169.254.169.254)
• HTTP redirect responses (301, 302, 303, 307, 308) from allowlisted hosts pointing to internal resources
• Access logs showing Backstage accessing internal services it should not normally communicate with

Detection Strategies

• Monitor Backstage server outbound network traffic for connections to RFC 1918 private addresses, link-local addresses, and cloud metadata endpoints
• Analyze HTTP response codes from allowlisted hosts, flagging redirect chains that terminate at non-allowlisted destinations
• Implement logging at the FetchUrlReader level to capture full redirect chains for security review

Monitoring Recommendations

• Deploy network monitoring to detect SSRF patterns such as internal IP access from web-facing services
• Set up alerts for Backstage accessing cloud metadata services or internal infrastructure endpoints
• Review and audit backend.reading.allow configurations regularly to minimize the attack surface

How to Mitigate CVE-2026-24048

Immediate Actions Required

• Upgrade @backstage/backend-defaults to version 0.12.2, 0.13.2, 0.14.1, or 0.15.0 or later immediately
• Review the backend.reading.allow configuration and remove any untrusted or unnecessary hosts
• Audit all currently allowlisted hosts for open redirect vulnerabilities

Patch Information

The vulnerability has been fixed in @backstage/backend-defaults versions 0.12.2, 0.13.2, 0.14.1, and 0.15.0. The fix addresses the redirect following behavior to ensure redirect destinations are validated against the allowlist. For technical details on the patch, see the GitHub Commit and the GitHub Security Advisory GHSA-q2x5-4xjx-c6p9.

Workarounds

• Restrict backend.reading.allow to only trusted hosts that you fully control and that do not issue redirects
• Audit all allowed hosts to ensure they do not have open redirect vulnerabilities that could be exploited
• Implement network-level controls (firewall rules, network policies) to block access from Backstage to sensitive internal endpoints
• Consider using a web proxy in front of Backstage that blocks redirects to internal resources

# Example: Review your Backstage app-config.yaml for reading allow configuration
# Ensure only trusted, non-redirecting hosts are listed
# Location: app-config.yaml

backend:
  reading:
    allow:
      # Only include hosts you fully control
      # Remove any hosts that may issue redirects to internal resources
      - host: 'trusted-internal-service.example.com'
      # Avoid wildcard entries where possible