CVE-2026-48525

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 ("b64": 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.

[!NOTE] 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.

When verifying detached JWS tokens using the unencoded-payload option ("b64": 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.

Affected Component(s)

• jwt/api_jws.py

  • PyJWS.decode() / PyJWS.decode_complete()
  • _load() (parsing and Base64URL decoding)

Root Cause (exact logic flaw)

What happens in the code

In jwt/api_jws.py, decode_complete() does the following (order matters):

• Calls _load(jwt) first, which decodes the token segments
• Only after that, checks header.get("b64") and if False, it replaces payload = detached_payload and rebuilds the signing input

This behavior is visible in decode_complete():

• _load(jwt) happens before the b64=false handling
• then payload = detached_payload and signing_input = ... detached_payload happens afterward ([GitHub][1])

Inside _load(), PyJWT unconditionally performs:

• payload = base64url_decode(payload_segment) This is the expensive step the attacker can amplify ([GitHub][1])

Why this becomes a vulnerability

For b64=false detached JWS, the payload segment in compact form is effectively not needed for verification in PyJWT’s own logic (since the library uses detached_payload as the real payload). Yet PyJWT still decodes it first, meaning:

• cost is paid even when signature is invalid
• the decoded bytes are discarded
• attacker controls the size of this cost via token length

Impact (evidence-driven)

Security impact

• Unauthenticated remote DoS: decoding work happens before signature rejection → attacker does not need signing key.
• CPU amplification: Base64URL decode time scales linearly with payload segment size.
• Memory amplification: decoded output allocates large byte buffers (tens of MB per request).
• Operational impact: request queueing / worker starvation under modest concurrency bursts.

Standards context (RFC 7797)

RFC 7797 explicitly notes this option is used when payload is large and/or detached, and discusses interoperability requirements around marking it critical (“crit” with “b64”). ([IETF Datatracker][2]) (PyJWT supports crit validation, but the issue here is decode order / unbounded decode of an unused segment.)

Affected Versions

• Confirmed affected: PyJWT 2.12.1 (tested from your local editable install and repo).
• Likely affected: all versions that include detached payload support for JWS decoding, which was introduced in 2.4.0 (“Add detached payload support for JWS encoding and decoding”). ([pyjwt.readthedocs.io][3])

(For GHSA, this phrasing is strong: “confirmed” + “likely since feature introduction”.)

Threat Model

Typical real deployment

A service verifies signed HTTP requests or webhooks using detached JWS:

• token is provided in JSON body / query / header
• actual payload is the HTTP request body passed as detached_payload

Attacker

• remote unauthenticated client
• can send requests to verify endpoint
• does not need a valid signature (invalid signature still triggers the expensive decode path)

Attack…

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 ("b64": 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.

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 ("b64": 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.

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 ("b64": 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.

TuxCare rebuilt pyjwt to address 4 CVEs. Fixed in 2.10.1.post2+tuxcare.

TuxCare rebuilt pyjwt to address 3 CVEs. Fixed in 1.7.1.post3+tuxcare.

These are all security issues fixed in the python311-PyJWT-2.13.0-1.1 package on the GA media of openSUSE Tumbleweed.

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

Root has patched CVE-2026-48525 in the PyJWT package for Root:PyPI. Multiple fixed versions available.

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

It was discovered that PyJWT incorrectly handled certain URIs when using PyJWKClient. A remote attacker could possibly use this issue to perform server-side request forgery (SSRF) or expose sensitive local files. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS and Ubuntu 26.04 LTS. (CVE-2026-48522)

It was discovered that PyJWT incorrectly verified cryptographic signatures when decoding tokens with PyJWK keys. A remote attacker could possibly use this issue to bypass signature verification and forge valid JSON Web Tokens. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-48523)

It was discovered that PyJWT incorrectly handled unknown key identifiers in PyJWKClient. A remote attacker could possibly use this issue to cause PyJWT to make excessive network requests, resulting in a denial of service. This issue only affected Ubuntu 24.04 LTS and Ubuntu 26.04 LTS. (CVE-2026-48524)

It was discovered that PyJWT incorrectly handled payload decoding during detached JWS token verification. A remote attacker could possibly use this issue to cause PyJWT to consume excessive resources, resulting in a denial of service. This issue only affected Ubuntu 24.04 LTS and Ubuntu 26.04 LTS. (CVE-2026-48525)

It was discovered that PyJWT incorrectly validated JSON Web Keys when decoding tokens with both HMAC and asymmetric algorithms enabled. A remote attacker could possibly use this issue to forge valid tokens, resulting in an authentication bypass. (CVE-2026-48526)