<?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, 29 Sep 2026 20:19:01 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-48525 — PyJWT: Unauthenticated DoS via unbounded Base64URL decoding of unused payload segment in b64=false detached JWS</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-48525</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; jpadilla pyjwt&lt;/p&gt;
&lt;p&gt;PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (&amp;#34;b64&amp;#34;: false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. 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&lt;/p&gt;
&lt;p&gt;PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (&amp;#34;b64&amp;#34;: false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-48525</guid>
    </item>
    <item>
      <title>GHSA-w7vc-732c-9m39 — PyJWT: Unauthenticated DoS via unbounded Base64URL decoding of unused payload segment in b64=false detached JWS</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-w7vc-732c-9m39</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; Practical impact depends on whether request body-size limits are enforced upstream (proxy/web-server/framework). Deployments with typical body-size caps (≤2 MB) bound the amplifier significantly; deployments accepting larger token inputs are more exposed.&lt;/p&gt;
&lt;p&gt;When verifying detached JWS tokens using the unencoded-payload option (`&amp;#34;b64&amp;#34;: false`, RFC 7797), PyJWT performs **Base64URL decoding of the compact-serialization payload segment** *before* enforcing the detached-payload rules.&lt;/p&gt;
&lt;p&gt;For `b64=false`, PyJWT later **discards** that decoded payload and replaces it with the caller-provided `detached_payload`. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces **CPU work + memory allocations** even if the signature is invalid.&lt;/p&gt;
&lt;p&gt;This creates an **unauthenticated DoS** vector against any endpoint that verifies detached JWS using PyJWT.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Affected Component(s)&lt;/p&gt;
&lt;p&gt;* `jwt/api_jws.py`&lt;/p&gt;
&lt;p&gt;* `PyJWS.decode()` / `PyJWS.decode_complete()`
  * `_load()` (parsing and Base64URL decoding)&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Root Cause (exact logic flaw)&lt;/p&gt;
&lt;p&gt;### What happens in the code&lt;/p&gt;
&lt;p&gt;In `jwt/api_jws.py`, `decode_complete()` does the following (order matters):&lt;/p&gt;
&lt;p&gt;* Calls `_load(jwt)` first, which decodes the token segments
* Only after that, checks `header.get(&amp;#34;b64&amp;#34;)` and if `False`, it replaces `payload = detached_payload` and rebuilds the signing input&lt;/p&gt;
&lt;p&gt;This behavior is visible in `deco…&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; Practical impact depends on whether request body-size limits are enforced upstream (proxy/web-server/framework). Deployments with typical body-size caps (≤2 MB) bound the amplifier significantly; deployments accepting larger token inputs are more exposed.&lt;/p&gt;
&lt;p&gt;When verifying detached JWS tokens using the unencoded-payload option (`&amp;#34;b64&amp;#34;: false`, RFC 7797), PyJWT performs **Base64URL decoding of the compact-serialization payload segment** *before* enforcing the detached-payload rules.&lt;/p&gt;
&lt;p&gt;For `b64=false`, PyJWT later **discards** that decoded payload and replaces it with the caller-provided `detached_payload`. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces **CPU work + memory allocations** even if the signature is invalid.&lt;/p&gt;
&lt;p&gt;This creates an **unauthenticated DoS** vector against any endpoint that verifies detached JWS using PyJWT.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Affected Component(s)&lt;/p&gt;
&lt;p&gt;* `jwt/api_jws.py`&lt;/p&gt;
&lt;p&gt;* `PyJWS.decode()` / `PyJWS.decode_complete()`
  * `_load()` (parsing and Base64URL decoding)&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Root Cause (exact logic flaw)&lt;/p&gt;
&lt;p&gt;### What happens in the code&lt;/p&gt;
&lt;p&gt;In `jwt/api_jws.py`, `decode_complete()` does the following (order matters):&lt;/p&gt;
&lt;p&gt;* Calls `_load(jwt)` first, which decodes the token segments
* Only after that, checks `header.get(&amp;#34;b64&amp;#34;)` and if `False`, it replaces `payload = detached_payload` and rebuilds the signing input&lt;/p&gt;
&lt;p&gt;This behavior is visible in `deco…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-w7vc-732c-9m39</guid>
    </item>
    <item>
      <title>PYSEC-2026-178</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-178</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. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (&amp;#34;b64&amp;#34;: false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. 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. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (&amp;#34;b64&amp;#34;: false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-178</guid>
    </item>
  </channel>
</rss>
