<?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>Sat, 07 Nov 2026 05:00:16 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-96447 — Keycloak-services: keycloak-services: stateless token preferred_username fallback enables identity rebinding</title>
      <link>https://db.gcve.eu/vuln/cve-2026-96447</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Red Hat build of Keycloak 26.6, Red Hat build of Keycloak 26.6.8, Red Hat Single Sign-On 7&lt;/p&gt;
&lt;p&gt;A flaw was found in the TokenManager component of Keycloak, an open-source identity and access management solution. The issue occurs during the validation of stateless access tokens when the original user ID no longer exists. Keycloak incorrectly falls back to using the username to identify the user without verifying if the identity matches the original token subject. This could allow an attacker with an old token to gain access to a newly created service account if it shares the same client ID as a previously deleted one.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Red Hat build of Keycloak 26.6, Red Hat build of Keycloak 26.6.8, Red Hat Single Sign-On 7&lt;/p&gt;
&lt;p&gt;A flaw was found in the TokenManager component of Keycloak, an open-source identity and access management solution. The issue occurs during the validation of stateless access tokens when the original user ID no longer exists. Keycloak incorrectly falls back to using the username to identify the user without verifying if the identity matches the original token subject. This could allow an attacker with an old token to gain access to a newly created service account if it shares the same client ID as a previously deleted one.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-96447</guid>
    </item>
  </channel>
</rss>
