Your message dated Thu, 2 Jul 2026 21:48:21 +0200
with message-id <[email protected]>
and subject line Re: Accepted pyjwt 2.13.0-1 (source) into unstable
has caused the Debian Bug report #1138191,
regarding pyjwt: CVE-2026-48522 CVE-2026-48523 CVE-2026-48524 CVE-2026-48525
CVE-2026-48526
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1138191: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1138191
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Source; pyjwt
Source-Version: 2.13.0-1)
On Wed, Jul 01, 2026 at 08:37:01PM +0000, Debian FTP Masters wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Format: 1.8
> Date: Wed, 01 Jul 2026 17:01:04 +0200
> Source: pyjwt
> Architecture: source
> Version: 2.13.0-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Python Team <[email protected]>
> Changed-By: Carsten Schoenert <[email protected]>
> Changes:
> pyjwt (2.13.0-1) unstable; urgency=medium
> .
> * Team upload
> * [0cbf1ea] New upstream version 2.13.0
> Checksums-Sha1:
> 7098182c8bee9c2c4a117e5d0f225bc63a3d2178 2404 pyjwt_2.13.0-1.dsc
> 5d5c0a17a6f5b2b1fb0862572e6537f615715b5b 107143 pyjwt_2.13.0.orig.tar.gz
> 10692cdc290b7a225473bb98b93446343ef03470 72228 pyjwt_2.13.0-1.debian.tar.xz
> 912a90d533f3ac7bddc070a403efb28224d05add 8960 pyjwt_2.13.0-1_amd64.buildinfo
> Checksums-Sha256:
> a02d3b97a7a306c3aea3ba8efde36098a21a49f4598301ae53255c5e79c422d6 2404
> pyjwt_2.13.0-1.dsc
> e091acfa88c7413955c47c131a78bb2667495d2fe2fb48a50c183830a4c7812a 107143
> pyjwt_2.13.0.orig.tar.gz
> fa86e60639fb297aee1b6555587a0157f3e681373e630449f0e7feb95494a4f2 72228
> pyjwt_2.13.0-1.debian.tar.xz
> 6326b45e5b8591b877abf82a499bda8290e3436613588ef670a09b22f2b25312 8960
> pyjwt_2.13.0-1_amd64.buildinfo
> Files:
> 37fd50cdf020a13749281e1edc00c416 2404 python optional pyjwt_2.13.0-1.dsc
> 3b212dd66d3c7eff0ead55c102a6191c 107143 python optional
> pyjwt_2.13.0.orig.tar.gz
> e060230625db2abd4a25ed9146a4a058 72228 python optional
> pyjwt_2.13.0-1.debian.tar.xz
> 210f7cd3306781c0268da73d8fb4792c 8960 python optional
> pyjwt_2.13.0-1_amd64.buildinfo
>
> -----BEGIN PGP SIGNATURE-----
>
> iQJMBAEBCgA2FiEEtw38bxNP7PwBHmKqgwFgFCUdHbAFAmpFbtUYHGMuc2Nob2Vu
> ZXJ0QHQtb25saW5lLmRlAAoJEIMBYBQlHR2wAIcP/2jzeP/pW7e4l2WwygCQxQcp
> wq3Zqgh8B027p3ZT5p8g/0pUAUdIev4ETUSVvbKj8NEL3bhTWQ1a6Ue84Fjp2qFI
> mcF7YgyrqTvn/IjOFLiDz+nWmDcVJoqa+4LoC/G4P+NCCeabr8/4+YXpZyesUqwq
> 2D9EmdzNXmPgegCZRvFQbiUQN0nrf3EaivfifAyNsvfsHYcE/SpbVD7fk0mHZwAT
> KfnSAvW1/iAz+Ni4J7wfFOT3nT7Xsy3aE8LnePjmBJoZddr8pncw8TG0o/JMrjBS
> IOhT1rIAi0tkSaS68oo5gR03DYasZPQ1+vWH4cHqKMxXQZ9KaLzw73MllttxK7I2
> 3BTLi7oR1jfOhS4ue8aEMQgkhHUMc5MW7L3wpSLxK+IjFh3u0fyum/vowSjpmc5j
> 70efxUCykAjCCRP4WgNZYZRYNuhLAKlmMgT2vsjaikeE5IFUNgr4UQ123O70e+wH
> q9z2Ahc6R1B1wj4sCBSpfprDRCtFSxEO//eKzV1H3QS/UES6HH3kHsOoP+f9tpUs
> gJFL20dCVv9B4cPdjw8/AIb4BiNYPu9F/XZwg1tM81jyn4RCvEGHFyCoGL7R+BPh
> JKqp8wZUqog5JF4Y0TOGfCkWLUt/UEbu4N1+HMOrcuuotdp3/F/qxZR4AECTDa6v
> 43tkpo3kO7rRuGNp64Ir
> =DTA8
> -----END PGP SIGNATURE-----
--- End Message ---
