CVE-2026-106460 Overview
CVE-2026-106460 is an authentication bypass vulnerability in Backstage, an open framework for building developer portals. The flaw resides in the @backstage/plugin-auth-node package, which fails to consistently honor explicit negative email verification during shared OAuth profile normalization. An authenticated identity-provider user who can supply or change an unverified email may assume another catalog identity and inherit its access and permissions. The issue affects versions from 0.3.0 up to 0.6.15 and 0.7.5, and is categorized under Improper Authentication [CWE-287].
Critical Impact
An admitted identity-provider user who controls an unverified email address can impersonate another Backstage catalog identity and obtain its associated permissions.
Affected Products
- @backstage/plugin-auth-node versions 0.3.0 through 0.6.14
- @backstage/plugin-auth-node versions 0.7.0 through 0.7.4
- Backstage releases prior to v1.49.7 and v1.54.7
Discovery Timeline
- 2026-10-06 - CVE-2026-106460 published to NVD
- 2026-10-07 - Last updated in NVD database
Technical Details for CVE-2026-106460
Vulnerability Analysis
The vulnerability stems from how @backstage/plugin-auth-node normalizes OAuth profile data returned by identity providers. During profile normalization, the auth-node package selected an email from the OAuth profile without consistently rejecting it when the provider explicitly flagged the email as unverified. Three distinct paths are affected: 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.
When Backstage deployments resolve catalog identities using the selected profile email, an attacker-controlled unverified email can be matched against another user's catalog entry. The result is identity assumption and silent privilege acquisition. An absent email_verified claim alone is not vulnerable; the issue applies only when verification metadata explicitly says false on the selected email.
Root Cause
The root cause is missing enforcement of the verified and email_verified fields during profile normalization inside plugins/auth-node/src/passport/PassportHelpers.ts. The pre-patch code accepted the first email from profile.emails without inspecting its verification status.
Attack Vector
Exploitation requires an attacker who is already an admitted user in the connected identity provider and who can supply or modify an unverified email on their IdP profile. The attacker sets this unverified email to match the catalog email of a higher-privileged Backstage identity. On the next OAuth sign-in, Backstage resolves the attacker's session to the victim's catalog identity.
// Source: https://github.com/backstage/backstage/commit/507e65ab9160aae6b602513dbfaebdd6be0ca8bb
// Patch in plugins/auth-node/src/passport/PassportHelpers.ts
profile: PassportProfile,
idToken?: string,
): ProfileInfo => {
+ const extendedProfile = profile as PassportProfile & {
+ emails?: Array<{
+ value: string;
+ type?: string;
+ verified?: unknown;
+ }>;
+ _json?: unknown;
+ };
+
let email: string | undefined = undefined;
- if (profile.emails && profile.emails.length > 0) {
- const [firstEmail] = profile.emails;
+ let emailWasRejected = false;
+
+ if (
+ Array.isArray(extendedProfile.emails) &&
+ extendedProfile.emails.length > 0
+ ) {
+ const [firstEmail] = extendedProfile.emails;
email = firstEmail.value;
+ emailWasRejected = firstEmail.verified === false;
} else if (profile.email) {
// This is the case for Atlassian
email = profile.email;
}
+
+ const rawProfileValue = extendedProfile._json;
Detect Identity Attacks the Moment Authentication Fails
Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.
Stop Identity AttacksDetection Methods for CVE-2026-106460
Indicators of Compromise
- OAuth sign-in events where the resolved Backstage catalog identity does not match the IdP user's canonical identifier (sub or stable user ID).
- IdP audit entries showing a user changing their email address to match another known Backstage user's email shortly before signing in.
- Backstage access logs showing permission grants or catalog actions by a user whose IdP profile email was recently modified and remained unverified.
Detection Strategies
- Correlate OAuth profile payloads with resolved Backstage identities and alert when email_verified: false or verified: false appears alongside a successful identity resolution.
- Inventory running Backstage deployments and confirm the installed version of @backstage/plugin-auth-node; flag any instance below 0.6.15 or 0.7.5.
- Review sign-in resolvers to identify deployments that resolve catalog identities by profile email rather than by provider-stable identifier.
Monitoring Recommendations
- Forward Backstage auth plugin logs and IdP sign-in events to a centralized analytics pipeline for cross-source correlation.
- Alert on repeated profile email changes from a single IdP user, especially when the new address matches an existing catalog entity.
- Track permission-sensitive catalog actions (ownership changes, entity edits, token issuance) performed immediately after a new OAuth session.
How to Mitigate CVE-2026-106460
Immediate Actions Required
- Upgrade @backstage/plugin-auth-node to version 0.6.15 or 0.7.5, or deploy Backstage release v1.49.7 or v1.54.7.
- Audit catalog sign-in resolvers and switch email-based resolution to provider-stable identifiers where feasible.
- Review recent sign-in events for unexpected catalog identity assumptions and revoke any suspicious sessions.
Patch Information
The fix is implemented across commits 507e65a, f0a43da, and fc5e30a. The patched PassportHelpers.ts now inspects verified on the selected profile email and email_verified on the raw provider payload and ID token, rejecting the email when verification is explicitly false. Full details are available in the Backstage Security Advisory GHSA-xm5q-p7w3-x6cp.
Workarounds
- Configure sign-in resolvers to use the IdP's stable subject identifier instead of email for catalog identity resolution.
- Restrict identity-provider configuration so end users cannot self-set or change email addresses without administrative verification.
- Enforce IdP-side policies that require email verification before issuing OAuth tokens to Backstage.
# Upgrade example using yarn in a Backstage monorepo
yarn up @backstage/plugin-auth-node@^0.6.15
# or for the 0.7.x line
yarn up @backstage/plugin-auth-node@^0.7.5
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

