<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 08 Oct 2026 22:44:58 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-106460</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-106460</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-106460</guid>
    </item>
    <item>
      <title>GHSA-xm5q-p7w3-x6cp — Backstage: Explicit negative email verification can be ignored during shared OAuth profile normalization</title>
      <link>https://db.gcve.eu/vuln/ghsa-xm5q-p7w3-x6cp</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @backstage/plugin-auth-node&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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 diffe…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @backstage/plugin-auth-node&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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 diffe…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-xm5q-p7w3-x6cp</guid>
    </item>
  </channel>
</rss>
