Backstage plugin-auth-backend EUVD-2026-58177

Exploitation requires three concurrent conditions: (1) the target Backstage instance must have explicitly enabled auth.experimentalDynamicClientRegistration or auth.experimentalClientIdMetadataDocuments in its app-config - both are disabled by default and absent from standard configurations; (2) the configured allowedRedirectUriPatterns or allowedClientIdPatterns must include at least one wildcard-hostname glob pattern (e.g., https://*.example.com/callback) or a protocol-less pattern - the default allowlist entries reference only fixed or loopback hosts and are not affected; (3) a victim user must be induced to click a crafted OAuth authorization link and complete the approval flow, delivering the authorization code to the attacker. Exploitation is impossible against any default Backstage deployment. The attacker requires no authentication or prior session (PR:N per CVSS), but victim social engineering is a hard requirement (UI:R). Platforms running only stable, non-experimental auth features are entirely unaffected regardless of version.

The NVD-assigned CVSS 3.1 score of 4.7 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N) accurately reflects the primary constraints: no authentication is required from the attacker (PR:N), but victim interaction is mandatory (UI:R) because an OAuth authorization code is only issued after a user actively approves the authorization request. The Scope:Changed metric captures that the authorization code crosses the trust boundary of the Backstage auth backend and is delivered to attacker infrastructure. Despite the network-accessible attack vector and no authentication prerequisite, real-world risk is substantially reduced by the deployment precondition: both affected features are experimental and disabled by default, and exploitation is impossible in default Backstage installations. Only deployments that have explicitly opted in and configured wildcard-hostname or protocol-less patterns are exposed. No EPSS score was provided in the available intelligence, and neither public exploit code nor CISA KEV listing has been identified, suggesting no confirmed active exploitation at time of analysis. The practical window of exploitation also depends on the attacker's ability to register a client - dynamic client registration implies some registration endpoint is accessible, but this is gated by the experimental feature enablement. The risk level is appropriately low-to-medium for affected deployments and negligible for default configurations.

An attacker targeting a Backstage deployment with experimental dynamic client registration enabled submits a registration request for an OAuth client whose redirect URI is https://attacker.example/trusted.example.com/callback, which passes the configured https://*.example.com/callback allowlist pattern due to full-string glob matching. The attacker then delivers a crafted OAuth authorization link to a victim user; upon the victim completing the authorization flow, Backstage issues the authorization code to the attacker-controlled host, where it can be exchanged for an access token to impersonate the victim. No public exploit code has been identified at time of analysis.