CVE-2026-106460 in Backstage
Summary
by MITRE • 10/07/2026
Backstage is an open framework for building developer portals. From 0.3.0 until 0.6.15 and 0.7.5, the @backstage/plugin-auth-node package did not consistently honor explicit negative email verification during shared OAuth profile normalization. The affected paths include a selected profile email marked verified: false, a matching raw provider email marked email_verified: false, and an email obtained only from an ID token marked email_verified: false. Exploitation requires an admitted identity-provider user who can supply or change an unverified email and a deployment that uses the selected profile email to resolve catalog identities. The verification metadata must apply to the selected email; an absent email_verified claim alone is not affected. In an affected configuration, the user may assume another catalog identity and obtain its associated access and permissions. This issue is fixed in versions 0.6.15 and 0.7.5.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified within Backstage prior to version 0.3.0 through 0.6.15 and 0.7.5 represents a critical authentication logic flaw located specifically within the @backstage/plugin-auth-node package. This open-source framework for building developer portals relies heavily on accurate identity resolution to map external users to internal catalog entities, which in turn dictate access controls and permissions. The core technical failure stems from an inconsistency in how shared OAuth profile normalization handles explicit negative email verification claims. When Backstage aggregates user data from various OpenID Connect or OAuth providers, it must determine the canonical email address for a given identity. In this flawed implementation, the system failed to consistently respect explicit indicators that an email address had not been verified by the identity provider. Specifically, if a selected profile contained an email marked as unverified (verified: false), or if a matching raw provider email carried an email_verified claim set to false, or even if the only available email source was an ID token with email_verified set to false, the system did not adequately enforce this negative status during the normalization process. This oversight means that the authentication layer treated these unverified emails as valid and authoritative for identity resolution purposes, bypassing a crucial security control intended to prevent impersonation via untrusted or user-controlled email attributes.
The operational impact of this vulnerability is severe because it directly compromises the integrity of catalog identities within the Backstage environment. In typical deployments where the selected profile email is used to resolve catalog identities, an attacker who has been admitted by the identity provider can exploit this logic error. By supplying or changing their account's unverified email address on the external identity provider side, and ensuring that the verification metadata applies specifically to the selected email rather than being absent entirely, the user can manipulate which internal Backstage entity they are mapped to. If a target catalog entity exists with an email address matching this manipulated unverified value, the attacker will be authenticated as that specific user. This allows for identity assumption, granting the adversary access and permissions associated with the victim's role rather than their own intended privileges. The scope of exploitation is limited to configurations where email-based resolution is active and relies on these specific verification states; if no email_verified claim is present at all, or if different resolution mechanisms are used, this particular vector remains inactive. However, in vulnerable setups, the ability to assume another catalog identity effectively bypasses authorization controls tied to those identities, potentially leading to unauthorized access to sensitive developer tools, code repositories, and infrastructure configurations managed through Backstage.
From a standards perspective, this vulnerability aligns with CWE-287, which covers Improper Authentication, specifically regarding the failure to correctly verify user credentials or identity attributes before granting access. It also relates to CWE-613, Insufficient Session Expiration, insofar as it allows an attacker to maintain persistent unauthorized access under a false identity once authenticated. In terms of MITRE ATT&CK mapping, this behavior is characteristic of Tactic TA0004 (Privilege Escalation) and specifically Technique T1078, Valid Accounts, where the adversary uses legitimate credentials but manipulates attributes to gain higher or different privileges than intended. The flaw essentially allows a valid user account to masquerade as another valid entity by exploiting weak validation of identity assertions during the normalization phase. This is not a traditional injection or buffer overflow issue but rather a business logic error in how trust boundaries are enforced between external identity providers and internal service catalogs.
Mitigation for this vulnerability requires immediate upgrading to patched versions, specifically Backstage 0.6.15 or 0.7.5 and later releases where the normalization logic has been corrected to strictly honor negative verification states. Administrators should verify that their deployment configurations do not rely solely on unverified email claims from identity providers for critical identity resolution without additional validation layers. If upgrading is not immediately feasible, organizations can implement compensating controls by configuring Backstage to ignore emails marked as unverified during the catalog entity matching process or by enforcing stricter policies at the identity provider level that ensure only verified emails are propagated in ID tokens and profile data. Additionally, auditing logs for unusual patterns of user-to-entity mapping changes may help detect potential exploitation attempts before they result in significant security breaches. Regular review of authentication plugins and their handling of external claims is essential to maintain robust access control integrity in developer portal environments.