Backstage EUVD-2026-94012

Requires the deployment to use @backstage/backend-defaults with external service credentials configured WITH access restrictions (e.g., accessRestrictions limiting a static/service token to a specific plugin or to action:read). The attacker must already possess such a restricted-but-valid service credential (hence PR:L) and must route the request through a plugin-to-plugin delegation path (getPluginRequestToken onBehalfOf), where the original permission-name or permission-attribute restrictions were not propagated into the forwarded plugin token. LIMITING FACTORS: no exploitation if access restrictions are not used; the bypass is scoped to plugins reachable via delegation; affected only in versions prior to 0.16.1 / 0.17.8. This is not an unauthenticated remote RCE - it is an authorization-boundary bypass for an already-trusted restricted principal.

This is a genuine but conditional privilege-escalation issue (CWE-269) rather than a drive-by remote compromise. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L, base 7.6) is internally consistent with the description: network-reachable, low complexity, but requiring PR:L - the attacker must already hold a valid external service credential. The real risk driver is the integrity impact (I:H): a credential intended to be read-only can perform writes on plugins it was restricted from modifying. No EPSS score, CISA KEV entry, or public proof-of-concept was supplied in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the only public artifacts are the vendor patch commits and advisory, not weaponized code. Severity is 'High' by CVSS but real-world urgency is gated by a non-default precondition: the deployment must use @backstage/backend-defaults with external service credentials that have access restrictions configured. For environments that rely on those read-only restrictions as a security boundary this is a real priority; for environments that do not configure access restrictions at all, the practical exposure is limited. Note a version-labeling discrepancy worth verifying (see confidence_notes): the description cites fixes in 0.16.1/0.17.8 while the referenced release tags are v1.49.6/v1.54.6.

An organization issues an external service a static token scoped to read-only access on the catalog plugin. The compromised or malicious holder of that restricted token calls a plugin-to-plugin delegation path (getPluginRequestToken onBehalfOf) so the request is re-issued without the original read-only restriction being preserved, allowing it to perform write operations it was never authorized for. No public exploit code was provided; only the vendor's fix commits are publicly available.