CVE-2026-32236: Backstage Auth Backend SSRF Vulnerability

CVE-2026-32236 Overview

A Server-Side Request Forgery (SSRF) vulnerability exists in the Backstage developer portal framework's @backstage/plugin-auth-backend component. The vulnerability occurs when the experimental Client ID Metadata Documents (CIMD) feature is enabled via auth.experimentalClientIdMetadataDocuments.enabled. While the initial client_id hostname is validated against private IP ranges, this validation is not applied after HTTP redirects, allowing attackers to potentially access internal network resources.

Critical Impact
Attackers can bypass IP address validation through HTTP redirects to make requests to internal network resources, though the impact is limited as response bodies cannot be read and request headers/methods cannot be controlled.

Affected Products

@backstage/plugin-auth-backend versions prior to 0.27.1
Backstage deployments with auth.experimentalClientIdMetadataDocuments.enabled set to true
Deployments without restricted allowedClientIdPatterns configurations

Discovery Timeline

2026-03-12 - CVE CVE-2026-32236 published to NVD
2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-32236

Vulnerability Analysis

This SSRF vulnerability exists in the CIMD metadata fetch functionality within the Backstage authentication backend. The core issue stems from inconsistent URL validation—while the initial request properly validates the client_id hostname against private IP ranges to prevent internal network access, this same validation is not enforced on subsequent HTTP redirect destinations.

The vulnerability has several mitigating factors that limit its practical exploitability. Attackers cannot read the response body from the internal request, cannot control request headers or the HTTP method (limited to GET requests), and the vulnerable feature must be explicitly enabled via an experimental flag that is disabled by default. Additionally, deployments that have configured allowedClientIdPatterns to restrict trusted domains are not affected by this vulnerability.

Root Cause

The root cause is a missing redirect validation in the CIMD client's HTTP fetch implementation (CWE-918: Server-Side Request Forgery). The code validates the initial URL against private IP ranges but allows the HTTP client to follow redirects to arbitrary destinations, including internal network addresses that would have been blocked in the initial validation. This creates a bypass mechanism where an attacker-controlled external server can redirect requests to internal services.

Attack Vector

The attack requires network access to a Backstage instance with the experimental CIMD feature enabled. An attacker can craft a malicious client_id that points to an attacker-controlled server. When Backstage fetches the metadata document, the attacker's server responds with an HTTP redirect to an internal IP address or hostname. Since redirect validation was not enforced, the request follows the redirect and accesses the internal resource.

typescript

       method: 'GET',
       headers: { Accept: 'application/json' },
       signal: AbortSignal.timeout(FETCH_TIMEOUT_MS),
+      redirect: 'error',
     });
   } catch {
     throw new InputError('Failed to fetch client metadata');

Source: GitHub Commit

The patch adds redirect: 'error' to the fetch options, which causes the HTTP client to throw an error if a redirect is encountered rather than following it automatically. This ensures that all requests are subject to the initial URL validation and prevents the redirect-based bypass.

Detection Methods for CVE-2026-32236

Indicators of Compromise

Unusual outbound HTTP requests from Backstage servers to external domains followed by internal network traffic
Authentication logs showing client_id values pointing to suspicious or attacker-controlled domains
Network traffic patterns showing redirect chains from external to internal IP addresses
Error logs in the auth-backend related to failed metadata fetches after the patch is applied

Detection Strategies

Monitor network traffic from Backstage instances for HTTP requests to internal IP ranges (10.x.x.x, 172.16.x.x-172.31.x.x, 192.168.x.x) that originate from external URL requests
Implement egress filtering and logging to detect unusual outbound connection patterns from the auth-backend service
Review Backstage configuration to identify if auth.experimentalClientIdMetadataDocuments.enabled is set to true
Analyze authentication logs for client_id patterns that do not match expected or trusted domains

Monitoring Recommendations

Deploy network monitoring to track all outbound connections from Backstage services and alert on connections to internal network ranges
Configure logging for the @backstage/plugin-auth-backend component to capture all CIMD metadata fetch attempts
Implement alerting for HTTP redirect responses received by the auth-backend service
Periodically audit Backstage configuration files for experimental features that may introduce security risks

How to Mitigate CVE-2026-32236

Immediate Actions Required

Upgrade @backstage/plugin-auth-backend to version 0.27.1 or later immediately
If unable to upgrade immediately, disable the experimental CIMD feature by setting auth.experimentalClientIdMetadataDocuments.enabled to false
Configure allowedClientIdPatterns to restrict client IDs to known, trusted domains only
Review network segmentation to limit the impact of potential SSRF attacks from the auth-backend service

Patch Information

The vulnerability is fixed in @backstage/plugin-auth-backend version 0.27.1. The fix adds redirect: 'error' to the fetch options in the CIMD client, preventing the HTTP client from following redirects. This ensures that all URL validations applied to the initial request cannot be bypassed through redirect chains. The patch is available via the GitHub commit and documented in the GitHub Security Advisory GHSA-qp4c-xg64-7c6x.

Workarounds

Disable the experimental CIMD feature entirely by setting auth.experimentalClientIdMetadataDocuments.enabled to false in your Backstage configuration
Configure strict allowedClientIdPatterns to only permit client IDs from known, trusted domains
Implement network-level controls to prevent the auth-backend service from making requests to internal network ranges
Deploy a web application firewall (WAF) or proxy that blocks redirect responses pointing to internal IP addresses

bash

# Configuration example - Disable experimental CIMD feature in app-config.yaml
# auth:
#   experimentalClientIdMetadataDocuments:
#     enabled: false
#   allowedClientIdPatterns:
#     - "^https://trusted-domain\\.com/.*$"
#     - "^https://another-trusted-domain\\.org/.*$"