GHSA-xm5q-p7w3-x6cp: Medium severity npm/@backstage/plugin-auth-node vulnerability

Published Oct 7, 2026
·
Updated

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 emailverified: 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 emailverified 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 emailverified: false, or when an email obtained only from an ID token carries emailverified: 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 Software

2 affected componentsFixes available
npm/@backstage/plugin-auth-node>=0.7.0<0.7.5
0.7.5
npm/@backstage/plugin-auth-node>=0.3.0<0.6.15
0.6.15

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@backstage/plugin-auth-node to a version that resolves this vulnerability.

    Fixed in 0.7.5
  2. Upgrade

    Upgrade npm/@backstage/plugin-auth-node to a version that resolves this vulnerability.

    Fixed in 0.6.15
  3. Upgrade

    Upgrade @backstage/plugin-auth-node to a version that resolves this vulnerability.

    Fixed in 0.6.15
  4. Upgrade

    Upgrade @backstage/plugin-auth-node to a version that resolves this vulnerability.

    Fixed in 0.7.5
  5. Configuration

    Configure a custom profile transform that omits the email when matching provider metadata explicitly marks it as unverified.

    Backstage authentication custom profile transform = omit email when provider metadata marks it as unverified
  6. Configuration

    Use a sign-in resolver that does not depend on the profile email.

    Backstage authentication sign-in resolver = do not depend on profile email
  7. Compensating control

    Ensure profile email addresses are immutable and provisioned from a trusted organizational source.

  8. Compensating control

    Require the identity provider to verify user-controlled email addresses before allowing sign-in.

Event History

Oct 7, 2026
Advisory Published
via GitHub·08:23 PM
Data Sourced
via GitHub·08:23 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are realistically exposed?

Deployments are exposed when an admitted identity-provider user can supply or change an email address without verification, and Backstage uses that profile email to resolve catalog identities. The risk is that such a user may be able to assume another catalog identity and receive its access and permissions.

2

Does a missing email_verified claim make a provider affected?

No. An absent email_verified claim alone is not considered an affected condition, because some providers intentionally omit the optional claim while using authoritative organizational provisioning.

3

What should operators do if they use email-based sign-in resolution?

Ensure the configured provider restricts sign-in to the intended user population and provides an authoritative email address. That address should come from provider verification or trusted immutable provisioning.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203