The vulnerability allows an attacker to force the Backstage application to make an outgoing HTTP request to a supplied client_id URL. Because the initial host name is validated against private IP ranges but the validation is not reapplied after HTTP redirects, a carefully crafted target can induce the server to reach internal resources. However, the attacker cannot read the response body, control request headers or the HTTP method, and the feature that triggers the fetch must be explicitly enabled via the experimental flag. Thus the practical impact is limited to probing internal network addresses that the application can reach. The weakness is a classic Server‑Side Request Forgery (CWE‑918).

All deployments of the @backstage/plugin‑auth‑backend component earlier than version 0.27.1 are vulnerable. The plugin is part of the Backstage open‑source developer portal framework. If the application disables the experimental feature flag or restricts allowedClientIdPatterns to trusted domains, the vulnerability does not apply.

The vulnerability scores a CVSS of 1.7, indicating a low severity, and has a low EPSS (<1%). It is not listed in the CISA KEV catalog, implying a low likelihood of exploitation. An attacker would need the ability to modify the application configuration to enable the experimental flag and supply a target URL that redirects to an internal host. Because the exploit cannot retrieve sensitive data from the internal request, the overall risk remains low, but a patch is recommended to eliminate the possibility of internal network probing.