<?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:48:53 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-48526 — PyJWT: Public-key JWK accepted as HMAC secret enables forged HS256 tokens when mixed families are allowed</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-48526</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; jpadilla pyjwt, Red Hat Ansible Automation Platform 2.5 for RHEL 8, Red Hat Ansible Automation Platform 2.5 for RHEL 9, Red Hat Ansible Automation Platform 2.6 for RHEL 9, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions, Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions, Red Hat Enterprise Linux 9.6 Extended Update Support and 30 more&lt;/p&gt;
&lt;p&gt;PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; jpadilla pyjwt, Red Hat Ansible Automation Platform 2.5 for RHEL 8, Red Hat Ansible Automation Platform 2.5 for RHEL 9, Red Hat Ansible Automation Platform 2.6 for RHEL 9, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions, Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions, Red Hat Enterprise Linux 9.6 Extended Update Support and 30 more&lt;/p&gt;
&lt;p&gt;PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-48526</guid>
    </item>
    <item>
      <title>GHSA-xgmm-8j9v-c9wx — PyJWT: Public-key JWK accepted as HMAC secret enables forged HS256 tokens when mixed families are allowed</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-xgmm-8j9v-c9wx</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pyjwt&lt;/p&gt;
&lt;p&gt;&amp;gt; [!NOTE]
&amp;gt; Exploitation requires a verifier configured with both symmetric and asymmetric algorithms in `algorithms=[…]` and a raw-JSON JWK as the `key=` argument, both contrary to documented usage, hence the High attack-complexity rating.&lt;/p&gt;
&lt;p&gt;### Summary
When the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm.&lt;/p&gt;
&lt;p&gt;### Details
In JWT algorithm confusion attack, the verifier is mistakenly use of public key to be used as the shared secret in symmetric algorithms.
In pyjwt case, when the verifier is supporting both HMAC with other asymmetric algorithm and mistakenly using the public key of the issuer to verify the token as demonstrated in the following example:
  
`jws.decode(token, key=rsa_jwk_json, algorithms=[&amp;#34;HS256&amp;#34;,&amp;#34;RS256&amp;#34;])) `&lt;/p&gt;
&lt;p&gt;An attacker who specifies in the token header to use HMAC, will cause the verifier to accept the JWK as the secret key in HMAC algorithm. 
The attacker will be able to forge JWT signed with the public key of the issuer to impersonate any user.&lt;/p&gt;
&lt;p&gt;If we look on current protections implemented in the library, at class HMACAlgorithm:&lt;/p&gt;
&lt;p&gt;```
  def prepare_key(self, key: str | bytes) -&amp;gt; bytes:
        key_bytes = force_bytes(key)&lt;/p&gt;
&lt;p&gt;if is_pem_format(key_bytes) or is_ssh_key(key_bytes):
            raise InvalidKeyError(
                &amp;#34;The specified key is…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pyjwt&lt;/p&gt;
&lt;p&gt;&amp;gt; [!NOTE]
&amp;gt; Exploitation requires a verifier configured with both symmetric and asymmetric algorithms in `algorithms=[…]` and a raw-JSON JWK as the `key=` argument, both contrary to documented usage, hence the High attack-complexity rating.&lt;/p&gt;
&lt;p&gt;### Summary
When the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm.&lt;/p&gt;
&lt;p&gt;### Details
In JWT algorithm confusion attack, the verifier is mistakenly use of public key to be used as the shared secret in symmetric algorithms.
In pyjwt case, when the verifier is supporting both HMAC with other asymmetric algorithm and mistakenly using the public key of the issuer to verify the token as demonstrated in the following example:
  
`jws.decode(token, key=rsa_jwk_json, algorithms=[&amp;#34;HS256&amp;#34;,&amp;#34;RS256&amp;#34;])) `&lt;/p&gt;
&lt;p&gt;An attacker who specifies in the token header to use HMAC, will cause the verifier to accept the JWK as the secret key in HMAC algorithm. 
The attacker will be able to forge JWT signed with the public key of the issuer to impersonate any user.&lt;/p&gt;
&lt;p&gt;If we look on current protections implemented in the library, at class HMACAlgorithm:&lt;/p&gt;
&lt;p&gt;```
  def prepare_key(self, key: str | bytes) -&amp;gt; bytes:
        key_bytes = force_bytes(key)&lt;/p&gt;
&lt;p&gt;if is_pem_format(key_bytes) or is_ssh_key(key_bytes):
            raise InvalidKeyError(
                &amp;#34;The specified key is…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-xgmm-8j9v-c9wx</guid>
    </item>
    <item>
      <title>PYSEC-2026-179</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-179</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pyjwt&lt;/p&gt;
&lt;p&gt;PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pyjwt&lt;/p&gt;
&lt;p&gt;PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-179</guid>
    </item>
  </channel>
</rss>
