<?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, 01 Oct 2026 21:45:47 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-35030 — LiteLLM has an authentication bypass via OIDC userinfo cache key collision</title>
      <link>https://db.gcve.eu/vuln/cve-2026-35030</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; BerriAI litellm, Red Hat Ansible Automation Platform 2.6, Red Hat OpenShift AI 2.25, Red Hat OpenShift AI 3.3, Red Hat Lightspeed Core, Red Hat OpenShift AI (RHOAI)&lt;/p&gt;
&lt;p&gt;LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.0, when JWT authentication is enabled (enable_jwt_auth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. Most instances are not affected. An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user&amp;#39;s cached token. On cache hit, the attacker inherits the legitimate user&amp;#39;s identity and permissions. This affects deployments with JWT/OIDC authentication enabled. Fixed in v1.83.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; BerriAI litellm, Red Hat Ansible Automation Platform 2.6, Red Hat OpenShift AI 2.25, Red Hat OpenShift AI 3.3, Red Hat Lightspeed Core, Red Hat OpenShift AI (RHOAI)&lt;/p&gt;
&lt;p&gt;LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.0, when JWT authentication is enabled (enable_jwt_auth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. Most instances are not affected. An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user&amp;#39;s cached token. On cache hit, the attacker inherits the legitimate user&amp;#39;s identity and permissions. This affects deployments with JWT/OIDC authentication enabled. Fixed in v1.83.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-35030</guid>
    </item>
    <item>
      <title>GHSA-jjhc-v7c2-5hh6 — LiteLLM: Authentication bypass via OIDC userinfo cache key collision</title>
      <link>https://db.gcve.eu/vuln/ghsa-jjhc-v7c2-5hh6</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;###  Impact&lt;/p&gt;
&lt;p&gt;When JWT authentication is enabled (`enable_jwt_auth: true`), the OIDC userinfo cache uses `token[:20]` as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters.&lt;/p&gt;
&lt;p&gt;This configuration option is not enabled by default. **Most instances are not affected.**&lt;/p&gt;
&lt;p&gt;An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user&amp;#39;s cached token. On cache hit, the attacker inherits the legitimate user&amp;#39;s identity and permissions. This affects deployments with JWT/OIDC authentication enabled.&lt;/p&gt;
&lt;p&gt;###  Patches&lt;/p&gt;
&lt;p&gt;Fixed in v1.83.0. The cache key now uses the full hash of the JWT token.&lt;/p&gt;
&lt;p&gt;###  Workarounds&lt;/p&gt;
&lt;p&gt;Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;###  Impact&lt;/p&gt;
&lt;p&gt;When JWT authentication is enabled (`enable_jwt_auth: true`), the OIDC userinfo cache uses `token[:20]` as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters.&lt;/p&gt;
&lt;p&gt;This configuration option is not enabled by default. **Most instances are not affected.**&lt;/p&gt;
&lt;p&gt;An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user&amp;#39;s cached token. On cache hit, the attacker inherits the legitimate user&amp;#39;s identity and permissions. This affects deployments with JWT/OIDC authentication enabled.&lt;/p&gt;
&lt;p&gt;###  Patches&lt;/p&gt;
&lt;p&gt;Fixed in v1.83.0. The cache key now uses the full hash of the JWT token.&lt;/p&gt;
&lt;p&gt;###  Workarounds&lt;/p&gt;
&lt;p&gt;Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-jjhc-v7c2-5hh6</guid>
    </item>
    <item>
      <title>PYSEC-2026-390 — LiteLLM: Authentication bypass via OIDC userinfo cache key collision</title>
      <link>https://db.gcve.eu/vuln/pysec-2026-390</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;###  Impact&lt;/p&gt;
&lt;p&gt;When JWT authentication is enabled (`enable_jwt_auth: true`), the OIDC userinfo cache uses `token[:20]` as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters.&lt;/p&gt;
&lt;p&gt;This configuration option is not enabled by default. **Most instances are not affected.**&lt;/p&gt;
&lt;p&gt;An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user&amp;#39;s cached token. On cache hit, the attacker inherits the legitimate user&amp;#39;s identity and permissions. This affects deployments with JWT/OIDC authentication enabled.&lt;/p&gt;
&lt;p&gt;###  Patches
 
Fixed in v1.83.0. The cache key now uses the full hash of the JWT token.&lt;/p&gt;
&lt;p&gt;###  Workarounds&lt;/p&gt;
&lt;p&gt;Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;###  Impact&lt;/p&gt;
&lt;p&gt;When JWT authentication is enabled (`enable_jwt_auth: true`), the OIDC userinfo cache uses `token[:20]` as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters.&lt;/p&gt;
&lt;p&gt;This configuration option is not enabled by default. **Most instances are not affected.**&lt;/p&gt;
&lt;p&gt;An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user&amp;#39;s cached token. On cache hit, the attacker inherits the legitimate user&amp;#39;s identity and permissions. This affects deployments with JWT/OIDC authentication enabled.&lt;/p&gt;
&lt;p&gt;###  Patches
 
Fixed in v1.83.0. The cache key now uses the full hash of the JWT token.&lt;/p&gt;
&lt;p&gt;###  Workarounds&lt;/p&gt;
&lt;p&gt;Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/pysec-2026-390</guid>
    </item>
  </channel>
</rss>
