Backstage CVE-2026-106495

Exploitation requires (1) a valid authenticated session on the Backstage backend, and (2) an operator having configured action exclusions via backend.actions (e.g. the pluginSources allowlist or attribute/id filters) - the flaw is only observable where an operator intended to restrict certain actions, since the DefaultActionsRegistryService failed to re-apply those filters at invocation. Limiting factors: the attacker must already be authenticated (PR:L); impact is bounded because existing per-action permissions and downstream authorization checks remain fully enforced; and there is no confidentiality or availability impact. Deployments that did not configure any action exclusions are not meaningfully affected.

This is a genuinely low-to-moderate priority issue despite being a real access-control flaw. The vendor CVSS of 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) is internally consistent with the description: exploitation requires an already-authenticated user (PR:L), is network-reachable with low complexity, and yields only a limited integrity impact (I:L) with no confidentiality or availability loss. Crucially, the description states that existing action permissions and downstream authorization remain enforced, so the flaw only lets an authenticated user invoke actions that an operator deliberately excluded via configuration - it does NOT bypass the underlying permission model. No EPSS score, CISA KEV listing, or public POC was provided in the intelligence set, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The combination of required authentication, config-dependent attack surface, and preserved downstream authorization makes this a defense-in-depth hardening fix rather than an urgent emergency. No signals conflict here; the main caveat is the absence of exploitation-probability data (EPSS) and the fact that impact is bounded by the actions an operator chose to exclude.

An authenticated low-privilege user of a Backstage developer portal sends a request to the backend actions registry to invoke an action that the platform operator had explicitly excluded through the backend.actions configuration (for example an action source the operator restricted). Because the registry did not re-apply the operator's action filters at invocation time, the excluded action executes. No public exploit code was provided in the intelligence set, and downstream authorization on the action itself still applies, limiting the practical effect.