Source: pyjwt
Version: 2.12.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi,
The following vulnerabilities were published for pyjwt.
CVE-2026-48522[0]:
| PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0,
| PyJWKClient passes its uri argument directly to
| urllib.request.urlopen() which uses Python stdlib's default
| OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler,
| FileHandler, and DataHandler. There is currently no documented
| option to restrict which schemes PyJWKClient will fetch. If an
| application's jku URL ingestion path accepts attacker-influenced
| URLs (e.g., from JWT header, configuration file, OAuth flow
| parameter), the attacker can cause PyJWKClient to read arbitrary
| local files via file:// (SSRF on local filesystem), cause
| PyJWKClient to attempt FTP / data-URI fetches (broader SSRF
| surface), or forge tokens that PyJWT verifies as valid. The library
| does not directly return non-HTTP(S) URI contents to the attacker;
| the chained "plant a JWKS to forge tokens" scenario described in the
| original report requires additional application-layer flaws
| (attacker write access to a filesystem path, untrusted jku
| derivation) that this fix does not address. This vulnerability is
| fixed in 2.13.0.
CVE-2026-48523[1]:
| PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to
| 2.12.1, there is a verifier-side algorithm allow-list bypass when
| jwt.decode() or jwt.decode_complete() are called with a PyJWK key.
| The token header alg is checked against the caller-supplied
| algorithms allow-list, but signature verification is performed with
| the algorithm bound to the PyJWK object instead of the header
| algorithm. An attacker who controls a registered JWK/JWKS private
| key can sign with a disallowed algorithm, advertise an allowed
| algorithm in the JWT header, and still be accepted. The issue
| affects the documented PyJWKClient.get_signing_key_from_jwt(...)
| flow. This vulnerability is fixed in 2.13.0.
CVE-2026-48524[2]:
| PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0,
| PyJWKClient.get_signing_key() forces a fresh HTTP request to the
| JWKS endpoint for every JWT with an unknown kid value, with no rate
| limiting. Since kid comes from the unverified token header, an
| attacker can trigger unlimited outbound requests. The vulnerability
| surfaces only when a JWKS fetch fails; an attacker can attempt to
| provoke that with sustained unknown-kid traffic, but the outcome
| depends on upstream JWKS-endpoint behavior (rate limiting, transient
| errors) which is beyond the attacker's control. This vulnerability
| is fixed in 2.13.0.
CVE-2026-48525[3]:
| 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.
CVE-2026-48526[4]:
| 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.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-48522
https://www.cve.org/CVERecord?id=CVE-2026-48522
[1] https://security-tracker.debian.org/tracker/CVE-2026-48523
https://www.cve.org/CVERecord?id=CVE-2026-48523
[2] https://security-tracker.debian.org/tracker/CVE-2026-48524
https://www.cve.org/CVERecord?id=CVE-2026-48524
[3] https://security-tracker.debian.org/tracker/CVE-2026-48525
https://www.cve.org/CVERecord?id=CVE-2026-48525
[4] https://security-tracker.debian.org/tracker/CVE-2026-48526
https://www.cve.org/CVERecord?id=CVE-2026-48526
Regards,
Salvatore
