Backstage: Explicit negative email verification can be ignored during shared OAuth profile normalizationGHSA-xm5q-p7w3-x6cp
MEDIUMFix: backstage/backstage@507e65aGHSA-xm5q-p7w3-x6cp is a medium-severity (CVSS 6.8) Improper Authentication vulnerability in @backstage/plugin-auth-node. A fix is available for @backstage/plugin-auth-node — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-xm5q-p7w3-x6cp.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-xm5q-p7w3-x6cp by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
@backstage/plugin-auth-node📦@backstage/plugin-auth-nodeReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Impact
Several Passport-based authentication providers use shared OAuth profile normalization from @backstage/plugin-auth-node. Affected versions may pass an email to email-based sign-in resolvers even when verification metadata supplied for that same address is explicitly negative. The ID-token-only fallback likewise did not consistently respect email_verified: false.
Exploitation requires a deployment where an admitted identity-provider user can supply or change an email address without verification and Backstage uses that profile email to resolve catalog identities. In that configuration, the user may be able to assume another catalog identity and obtain its associated access and permissions.
An absent email_verified claim is not by itself considered an affected condition. Some providers rely on authoritative organizational provisioning and intentionally omit the optional claim. Operators using email-based sign-in resolution must ensure that the configured provider restricts sign-in to the intended user population and supplies an authoritative email address, either through provider verification or trusted immutable provisioning.
This advisory covers the shared Passport profile normalization path when the selected profile email itself carries verified: false, when a matching raw provider email carries email_verified: false, or when an email obtained only from an ID token carries email_verified: false. It does not apply verification metadata from a different address or from a separate ID token to an independently fetched provider-profile email.
The generic OIDC provider follows a separate profile transform and is covered by GHSA-826h-28h9-65hg. The two advisories are complementary; deployments using both affected paths should apply both package updates. VMware Cloud uses a separate custom token transformation and is not changed by this patch.
Patches
Fixed in @backstage/plugin-auth-node versions 0.6.15 and 0.7.5. Users remaining on the 0.6.x line should upgrade to at least 0.6.15; users on 0.7.x should upgrade to at least 0.7.5.
The patched packages were released with Backstage v1.49.7 and Backstage v1.54.7, respectively. The fix is also present on master in commit 507e65a.
Workarounds
- Require the identity provider to verify user-controlled email addresses before allowing sign-in.
- Ensure profile emails are immutable and provisioned from a trusted organizational source.
- Use a sign-in resolver that does not depend on the profile email.
- Use a custom profile transform that omits an email when matching provider metadata explicitly marks it as unverified.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @backstage/plugin-auth-node | ≥ 0.3.0&&< 0.6.15 | 0.6.15npm install @backstage/plugin-auth-node@0.6.15 |
| 📦npm | @backstage/plugin-auth-node | ≥ 0.7.0&&< 0.7.5 | 0.7.5npm install @backstage/plugin-auth-node@0.7.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @backstage/plugin-auth-node, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @backstage/plugin-auth-node to 0.6.15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xm5q-p7w3-x6cp is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Red Hat rates this flaw as Moderate severity because successful exploitation requires significant prerequisites, specifically an authenticated identity provider account and an ability to assign arbitrary unconfirmed email addresses. In deployments running Red Hat Developer Hub or Red Hat Ansible Automation Platform…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for GHSA-xm5q-p7w3-x6cp (CC BY 4.0)
Frequently Asked Questions
Is GHSA-xm5q-p7w3-x6cp in your dependencies?
Find it across npm, including transitive dependencies.