<?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>Wed, 30 Sep 2026 23:57:01 +0000</lastBuildDate>
    <item>
      <title>BREW-azure-cli-CVE-2026-102266 — PyJWT: PyJWK accepts empty HMAC keys, bypassing PyJWT's empty-key validation</title>
      <link>https://db.gcve.eu/vuln/brew-azure-cli-cve-2026-102266</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: azure-cli&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A service that verifies HS256 tokens using an empty oct JWK through PyJWK, including a PyJWK obtained from PyJWKSet, can therefore accept attacker-generated tokens as authenticated.&lt;/p&gt;
&lt;p&gt;PyJWT 2.13.0 rejects an empty HMAC key when it is supplied through the raw `str`/`bytes` key path, but accepts the same zero-length key when it is supplied as a symmetric `PyJWK`.&lt;/p&gt;
&lt;p&gt;An `oct` JWK containing an empty Base64URL key value:&lt;/p&gt;
&lt;p&gt;```json
{&amp;#34;kty&amp;#34;:&amp;#34;oct&amp;#34;,&amp;#34;k&amp;#34;:&amp;#34;&amp;#34;}
```&lt;/p&gt;
&lt;p&gt;is decoded to `b&amp;#34;&amp;#34;`. During signature verification, the `PyJWK` path uses this decoded value directly and does not invoke the empty-key validation in `HMACAlgorithm.prepare_key`. With the default `enforce_minimum_key_length=False`, PyJWT emits a warning and proceeds with HMAC verification using the zero-length key.&lt;/p&gt;
&lt;p&gt;An attacker can independently calculate `HMAC-SHA256(b&amp;#34;&amp;#34;, signing_input)` and create valid HS256 JWTs with arbitrary claims. A service that verifies HS256 tokens using an empty `oct` JWK through `PyJWK` or `PyJWKSet` can therefore accept attacker-generated tokens as authenticated.&lt;/p&gt;
&lt;p&gt;The application must already contain an empty HMAC JWK, for example because a missing Base64URL configuration or secret-manager value was serialized as `&amp;#34;k&amp;#34;: &amp;#34;&amp;#34;`. The attacker does not need control of the JWK/JWKS source, a signing oracle, a private key, or a mixed algorithm allow-list.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The vulnerability is caused by inconsistent validation of the same HMAC key material depending on whether it enters PyJWT as a raw…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: azure-cli&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A service that verifies HS256 tokens using an empty oct JWK through PyJWK, including a PyJWK obtained from PyJWKSet, can therefore accept attacker-generated tokens as authenticated.&lt;/p&gt;
&lt;p&gt;PyJWT 2.13.0 rejects an empty HMAC key when it is supplied through the raw `str`/`bytes` key path, but accepts the same zero-length key when it is supplied as a symmetric `PyJWK`.&lt;/p&gt;
&lt;p&gt;An `oct` JWK containing an empty Base64URL key value:&lt;/p&gt;
&lt;p&gt;```json
{&amp;#34;kty&amp;#34;:&amp;#34;oct&amp;#34;,&amp;#34;k&amp;#34;:&amp;#34;&amp;#34;}
```&lt;/p&gt;
&lt;p&gt;is decoded to `b&amp;#34;&amp;#34;`. During signature verification, the `PyJWK` path uses this decoded value directly and does not invoke the empty-key validation in `HMACAlgorithm.prepare_key`. With the default `enforce_minimum_key_length=False`, PyJWT emits a warning and proceeds with HMAC verification using the zero-length key.&lt;/p&gt;
&lt;p&gt;An attacker can independently calculate `HMAC-SHA256(b&amp;#34;&amp;#34;, signing_input)` and create valid HS256 JWTs with arbitrary claims. A service that verifies HS256 tokens using an empty `oct` JWK through `PyJWK` or `PyJWKSet` can therefore accept attacker-generated tokens as authenticated.&lt;/p&gt;
&lt;p&gt;The application must already contain an empty HMAC JWK, for example because a missing Base64URL configuration or secret-manager value was serialized as `&amp;#34;k&amp;#34;: &amp;#34;&amp;#34;`. The attacker does not need control of the JWK/JWKS source, a signing oracle, a private key, or a mixed algorithm allow-list.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The vulnerability is caused by inconsistent validation of the same HMAC key material depending on whether it enters PyJWT as a raw…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/brew-azure-cli-cve-2026-102266</guid>
    </item>
    <item>
      <title>fkie_cve-2026-102266</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-102266</link>
      <description>&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.from_jwk is affected because PyJWK verification path used the decoded key without applying prepare_key validation. This occurs when a trusted JWK Set contains an oct entry with an empty k value. As a result, an attacker signs an HMAC token with the same zero-length key accepted by PyJWT. Consequently, forged token can carry arbitrary authenticated claims. This issue is fixed in version 2.14.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.from_jwk is affected because PyJWK verification path used the decoded key without applying prepare_key validation. This occurs when a trusted JWK Set contains an oct entry with an empty k value. As a result, an attacker signs an HMAC token with the same zero-length key accepted by PyJWT. Consequently, forged token can carry arbitrary authenticated claims. This issue is fixed in version 2.14.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-102266</guid>
    </item>
    <item>
      <title>GHSA-9j54-fg26-wv3r — PyJWT: PyJWK accepts empty HMAC keys, bypassing PyJWT's empty-key validation</title>
      <link>https://db.gcve.eu/vuln/ghsa-9j54-fg26-wv3r</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: PyJWT&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A service that verifies HS256 tokens using an empty oct JWK through PyJWK, including a PyJWK obtained from PyJWKSet, can therefore accept attacker-generated tokens as authenticated.&lt;/p&gt;
&lt;p&gt;PyJWT 2.13.0 rejects an empty HMAC key when it is supplied through the raw `str`/`bytes` key path, but accepts the same zero-length key when it is supplied as a symmetric `PyJWK`.&lt;/p&gt;
&lt;p&gt;An `oct` JWK containing an empty Base64URL key value:&lt;/p&gt;
&lt;p&gt;```json
{&amp;#34;kty&amp;#34;:&amp;#34;oct&amp;#34;,&amp;#34;k&amp;#34;:&amp;#34;&amp;#34;}
```&lt;/p&gt;
&lt;p&gt;is decoded to `b&amp;#34;&amp;#34;`. During signature verification, the `PyJWK` path uses this decoded value directly and does not invoke the empty-key validation in `HMACAlgorithm.prepare_key`. With the default `enforce_minimum_key_length=False`, PyJWT emits a warning and proceeds with HMAC verification using the zero-length key.&lt;/p&gt;
&lt;p&gt;An attacker can independently calculate `HMAC-SHA256(b&amp;#34;&amp;#34;, signing_input)` and create valid HS256 JWTs with arbitrary claims. A service that verifies HS256 tokens using an empty `oct` JWK through `PyJWK` or `PyJWKSet` can therefore accept attacker-generated tokens as authenticated.&lt;/p&gt;
&lt;p&gt;The application must already contain an empty HMAC JWK, for example because a missing Base64URL configuration or secret-manager value was serialized as `&amp;#34;k&amp;#34;: &amp;#34;&amp;#34;`. The attacker does not need control of the JWK/JWKS source, a signing oracle, a private key, or a mixed algorithm allow-list.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The vulnerability is caused by inconsistent validation of the same HMAC key material depending on whether it enters PyJWT as a raw…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: PyJWT&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A service that verifies HS256 tokens using an empty oct JWK through PyJWK, including a PyJWK obtained from PyJWKSet, can therefore accept attacker-generated tokens as authenticated.&lt;/p&gt;
&lt;p&gt;PyJWT 2.13.0 rejects an empty HMAC key when it is supplied through the raw `str`/`bytes` key path, but accepts the same zero-length key when it is supplied as a symmetric `PyJWK`.&lt;/p&gt;
&lt;p&gt;An `oct` JWK containing an empty Base64URL key value:&lt;/p&gt;
&lt;p&gt;```json
{&amp;#34;kty&amp;#34;:&amp;#34;oct&amp;#34;,&amp;#34;k&amp;#34;:&amp;#34;&amp;#34;}
```&lt;/p&gt;
&lt;p&gt;is decoded to `b&amp;#34;&amp;#34;`. During signature verification, the `PyJWK` path uses this decoded value directly and does not invoke the empty-key validation in `HMACAlgorithm.prepare_key`. With the default `enforce_minimum_key_length=False`, PyJWT emits a warning and proceeds with HMAC verification using the zero-length key.&lt;/p&gt;
&lt;p&gt;An attacker can independently calculate `HMAC-SHA256(b&amp;#34;&amp;#34;, signing_input)` and create valid HS256 JWTs with arbitrary claims. A service that verifies HS256 tokens using an empty `oct` JWK through `PyJWK` or `PyJWKSet` can therefore accept attacker-generated tokens as authenticated.&lt;/p&gt;
&lt;p&gt;The application must already contain an empty HMAC JWK, for example because a missing Base64URL configuration or secret-manager value was serialized as `&amp;#34;k&amp;#34;: &amp;#34;&amp;#34;`. The attacker does not need control of the JWK/JWKS source, a signing oracle, a private key, or a mixed algorithm allow-list.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The vulnerability is caused by inconsistent validation of the same HMAC key material depending on whether it enters PyJWT as a raw…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-9j54-fg26-wv3r</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-102266</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-102266</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:16.04:LTS: pyjwt, Ubuntu:Pro:18.04:LTS: pyjwt, Ubuntu:Pro:20.04:LTS: pyjwt, Ubuntu:22.04:LTS: pyjwt, Ubuntu:24.04:LTS: pyjwt, Ubuntu:26.04:LTS: pyjwt&lt;/p&gt;
&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.from_jwk is affected because PyJWK verification path used the decoded key without applying prepare_key validation. This occurs when a trusted JWK Set contains an oct entry with an empty k value. As a result, an attacker signs an HMAC token with the same zero-length key accepted by PyJWT. Consequently, forged token can carry arbitrary authenticated claims. This issue is fixed in version 2.14.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:16.04:LTS: pyjwt, Ubuntu:Pro:18.04:LTS: pyjwt, Ubuntu:Pro:20.04:LTS: pyjwt, Ubuntu:22.04:LTS: pyjwt, Ubuntu:24.04:LTS: pyjwt, Ubuntu:26.04:LTS: pyjwt&lt;/p&gt;
&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.from_jwk is affected because PyJWK verification path used the decoded key without applying prepare_key validation. This occurs when a trusted JWK Set contains an oct entry with an empty k value. As a result, an attacker signs an HMAC token with the same zero-length key accepted by PyJWT. Consequently, forged token can carry arbitrary authenticated claims. This issue is fixed in version 2.14.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-102266</guid>
    </item>
  </channel>
</rss>
