<?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://cve.radiocsirt.org</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>Wed, 07 Oct 2026 13:23:23 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-31813 — Supabase Auth has insecure Apple and Azure authentication with ID tokens</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-31813</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; supabase auth&lt;/p&gt;
&lt;p&gt;Supabase Auth is a JWT based API for managing users and issuing JWT tokens. Prior to 2.185.0, a vulnerability has been identified that allows an attacker to issue sessions for arbitrary users using specially crafted ID tokens when the Apple or Azure providers are enabled. The attacker issues a valid, asymmetrically signed ID token from their issuer for each victim email address, which then is sent to the Supabase Auth token endpoint using the ID token flow. If the ID token is OIDC compliant, the Auth server would validate it against the attacker-controlled issuer and link the existing OIDC identity (Apple or Azure) of the victim to an additional OIDC identity based on the ID token contents. The Auth server would then issue a valid user session (access and refresh tokens) at the AAL1 level to the attacker. This vulnerability is fixed in 2.185.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; supabase auth&lt;/p&gt;
&lt;p&gt;Supabase Auth is a JWT based API for managing users and issuing JWT tokens. Prior to 2.185.0, a vulnerability has been identified that allows an attacker to issue sessions for arbitrary users using specially crafted ID tokens when the Apple or Azure providers are enabled. The attacker issues a valid, asymmetrically signed ID token from their issuer for each victim email address, which then is sent to the Supabase Auth token endpoint using the ID token flow. If the ID token is OIDC compliant, the Auth server would validate it against the attacker-controlled issuer and link the existing OIDC identity (Apple or Azure) of the victim to an additional OIDC identity based on the ID token contents. The Auth server would then issue a valid user session (access and refresh tokens) at the AAL1 level to the attacker. This vulnerability is fixed in 2.185.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-31813</guid>
    </item>
  </channel>
</rss>
