<?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>Tue, 06 Oct 2026 06:12:38 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-15803</title>
      <link>https://vulnerability.circl.lu/vuln/bdu:2026-15803</link>
      <description>bdu:2026-15803</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bdu:2026-15803</guid>
    </item>
    <item>
      <title>fkie_cve-2026-102275</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-102275</link>
      <description>&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in  jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in  jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-102275</guid>
    </item>
    <item>
      <title>GHSA-x33g-cr3x-6449 — PyJWT accepts inconsistent OKP x/d JWKs, causing public/private key identity confusion</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-x33g-cr3x-6449</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;PyJWT accepts internally inconsistent OKP private JWKs where the declared public key `x` does not correspond to the supplied private key `d`.&lt;/p&gt;
&lt;p&gt;When `d` is present, `OKPAlgorithm.from_jwk()` constructs the Ed25519/Ed448 private key from `d` without verifying that the public key derived from `d` matches `x`. As a result, the original JWK can contain one public key identity while PyJWT performs cryptographic operations using a different key.&lt;/p&gt;
&lt;p&gt;In affected DPoP integrations, this can allow a stolen sender-constrained access token to be used without possession of the legitimate holder&amp;#39;s private key.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The vulnerable logic is in `jwt/algorithms.py`:&lt;/p&gt;
&lt;p&gt;```python
if &amp;#34;x&amp;#34; not in obj:
    raise InvalidKeyError(&amp;#39;OKP should have &amp;#34;x&amp;#34; parameter&amp;#39;)&lt;/p&gt;
&lt;p&gt;x = base64url_decode(obj.get(&amp;#34;x&amp;#34;))&lt;/p&gt;
&lt;p&gt;if &amp;#34;d&amp;#34; not in obj:
    if curve == &amp;#34;Ed25519&amp;#34;:
        return Ed25519PublicKey.from_public_bytes(x)
    return Ed448PublicKey.from_public_bytes(x)&lt;/p&gt;
&lt;p&gt;d = base64url_decode(obj.get(&amp;#34;d&amp;#34;))&lt;/p&gt;
&lt;p&gt;if curve == &amp;#34;Ed25519&amp;#34;:
    return Ed25519PrivateKey.from_private_bytes(d)&lt;/p&gt;
&lt;p&gt;return Ed448PrivateKey.from_private_bytes(d)
```&lt;/p&gt;
&lt;p&gt;When `d` is present, `x` is parsed but never compared with the public key derived from `d`.&lt;/p&gt;
&lt;p&gt;For example, PyJWT accepts:&lt;/p&gt;
&lt;p&gt;```json
{
  &amp;#34;kty&amp;#34;: &amp;#34;OKP&amp;#34;,
  &amp;#34;crv&amp;#34;: &amp;#34;Ed25519&amp;#34;,
  &amp;#34;x&amp;#34;: &amp;#34;&amp;lt;legitimate-user-public-key&amp;gt;&amp;#34;,
  &amp;#34;d&amp;#34;: &amp;#34;&amp;lt;attacker-private-key&amp;gt;&amp;#34;
}
```&lt;/p&gt;
&lt;p&gt;even though `x` and `d` belong to different key pairs.&lt;/p&gt;
&lt;p&gt;The behavior has existed since OKP private-JWK import was introduced:&lt;/p&gt;
&lt;p&gt;* Ed25519: PyJWT…&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;PyJWT accepts internally inconsistent OKP private JWKs where the declared public key `x` does not correspond to the supplied private key `d`.&lt;/p&gt;
&lt;p&gt;When `d` is present, `OKPAlgorithm.from_jwk()` constructs the Ed25519/Ed448 private key from `d` without verifying that the public key derived from `d` matches `x`. As a result, the original JWK can contain one public key identity while PyJWT performs cryptographic operations using a different key.&lt;/p&gt;
&lt;p&gt;In affected DPoP integrations, this can allow a stolen sender-constrained access token to be used without possession of the legitimate holder&amp;#39;s private key.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The vulnerable logic is in `jwt/algorithms.py`:&lt;/p&gt;
&lt;p&gt;```python
if &amp;#34;x&amp;#34; not in obj:
    raise InvalidKeyError(&amp;#39;OKP should have &amp;#34;x&amp;#34; parameter&amp;#39;)&lt;/p&gt;
&lt;p&gt;x = base64url_decode(obj.get(&amp;#34;x&amp;#34;))&lt;/p&gt;
&lt;p&gt;if &amp;#34;d&amp;#34; not in obj:
    if curve == &amp;#34;Ed25519&amp;#34;:
        return Ed25519PublicKey.from_public_bytes(x)
    return Ed448PublicKey.from_public_bytes(x)&lt;/p&gt;
&lt;p&gt;d = base64url_decode(obj.get(&amp;#34;d&amp;#34;))&lt;/p&gt;
&lt;p&gt;if curve == &amp;#34;Ed25519&amp;#34;:
    return Ed25519PrivateKey.from_private_bytes(d)&lt;/p&gt;
&lt;p&gt;return Ed448PrivateKey.from_private_bytes(d)
```&lt;/p&gt;
&lt;p&gt;When `d` is present, `x` is parsed but never compared with the public key derived from `d`.&lt;/p&gt;
&lt;p&gt;For example, PyJWT accepts:&lt;/p&gt;
&lt;p&gt;```json
{
  &amp;#34;kty&amp;#34;: &amp;#34;OKP&amp;#34;,
  &amp;#34;crv&amp;#34;: &amp;#34;Ed25519&amp;#34;,
  &amp;#34;x&amp;#34;: &amp;#34;&amp;lt;legitimate-user-public-key&amp;gt;&amp;#34;,
  &amp;#34;d&amp;#34;: &amp;#34;&amp;lt;attacker-private-key&amp;gt;&amp;#34;
}
```&lt;/p&gt;
&lt;p&gt;even though `x` and `d` belong to different key pairs.&lt;/p&gt;
&lt;p&gt;The behavior has existed since OKP private-JWK import was introduced:&lt;/p&gt;
&lt;p&gt;* Ed25519: PyJWT…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-x33g-cr3x-6449</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11994-1 — python313-PyJWT-2.15.1-1.1 on GA media</title>
      <link>https://vulnerability.circl.lu/vuln/opensuse-su-2026:11994-1</link>
      <description>&lt;p&gt;python313-PyJWT-2.15.1-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;python313-PyJWT-2.15.1-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/opensuse-su-2026:11994-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-102275</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-102275</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.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in  jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.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.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in  jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-102275</guid>
    </item>
  </channel>
</rss>
