<?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://vulnerability.circl.lu</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:33:46 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-102268 — PyJWT: Asymmetric-PEM detection bypass: whitespace/line-ending-mutated public keys skip the HS/asymmetric confusion gua…</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-102268</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; jpadilla pyjwt&lt;/p&gt;
&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. 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; jpadilla pyjwt&lt;/p&gt;
&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-102268</guid>
    </item>
    <item>
      <title>GHSA-ffc3-869f-jxw9 — PyJWT: Asymmetric-PEM detection bypass: whitespace/line-ending-mutated public keys skip the HS/asymmetric confusion gua…</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-ffc3-869f-jxw9</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: PyJWT&lt;/p&gt;
&lt;p&gt;**Prerequisites** (both conditions must hold; both are deployment properties, not attacker-controlled at request time):&lt;/p&gt;
&lt;p&gt;- The `jwt.decode` allow-list mixes an HMAC algorithm with an asymmetric one, e.g. `algorithms=[&amp;#34;ES256&amp;#34;, &amp;#34;HS256&amp;#34;]` (the RFC 8725 footgun the guard exists to backstop).
- The verification key is passed as raw PEM text/bytes on the non-`PyJWK` path, in a byte-form that `cryptography`&amp;#39;s loader accepts but PyJWT&amp;#39;s `is_pem_format` regex does not recognize (marker-adjacent whitespace/indentation, CR-only line terminators, or the PEM folded to a single line). Such forms arise naturally from an indented YAML/JSON block, a single-line environment variable or JSON string, or a CR/LF round-trip through config tooling.&lt;/p&gt;
&lt;p&gt;The attacker additionally needs the public verification key, which is public by definition, and `cryptography` must be installed.&lt;/p&gt;
&lt;p&gt;The fix for CVE-2022-29217 rejects an asymmetric key handed to an HMAC algorithm, but only when `is_pem_format()` recognizes the key as PEM. That recognizer accepts strictly fewer byte-forms than the loader that later parses the key, so a PEM the guard misses still loads as a valid public key and is then used as an HMAC secret. This is an incomplete-guard bypass of the CVE-2022-29217 family.&lt;/p&gt;
&lt;p&gt;### Summary
A PEM public key with marker-adjacent whitespace, CR-only line terminators, or folded to a single line makes PyJWT&amp;#39;s `is_pem_format()` return `False` while `cryptography.load_pem_public_key()` accepts the identical bytes. T…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: PyJWT&lt;/p&gt;
&lt;p&gt;**Prerequisites** (both conditions must hold; both are deployment properties, not attacker-controlled at request time):&lt;/p&gt;
&lt;p&gt;- The `jwt.decode` allow-list mixes an HMAC algorithm with an asymmetric one, e.g. `algorithms=[&amp;#34;ES256&amp;#34;, &amp;#34;HS256&amp;#34;]` (the RFC 8725 footgun the guard exists to backstop).
- The verification key is passed as raw PEM text/bytes on the non-`PyJWK` path, in a byte-form that `cryptography`&amp;#39;s loader accepts but PyJWT&amp;#39;s `is_pem_format` regex does not recognize (marker-adjacent whitespace/indentation, CR-only line terminators, or the PEM folded to a single line). Such forms arise naturally from an indented YAML/JSON block, a single-line environment variable or JSON string, or a CR/LF round-trip through config tooling.&lt;/p&gt;
&lt;p&gt;The attacker additionally needs the public verification key, which is public by definition, and `cryptography` must be installed.&lt;/p&gt;
&lt;p&gt;The fix for CVE-2022-29217 rejects an asymmetric key handed to an HMAC algorithm, but only when `is_pem_format()` recognizes the key as PEM. That recognizer accepts strictly fewer byte-forms than the loader that later parses the key, so a PEM the guard misses still loads as a valid public key and is then used as an HMAC secret. This is an incomplete-guard bypass of the CVE-2022-29217 family.&lt;/p&gt;
&lt;p&gt;### Summary
A PEM public key with marker-adjacent whitespace, CR-only line terminators, or folded to a single line makes PyJWT&amp;#39;s `is_pem_format()` return `False` while `cryptography.load_pem_public_key()` accepts the identical bytes. T…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-ffc3-869f-jxw9</guid>
    </item>
  </channel>
</rss>
