彙總 pyjwt_project 相關全部產品的 CVE 與安全漏洞情報，包括 CVSS、EPSS、公開時間與漏洞情報資料。
歷史漏洞主要涉及 SSRF 等安全問題，並影響 生產負載與軟體部署 相關場景。
相關漏洞資料主要來源於公開漏洞披露與安全公告，可用於評估歷史漏洞暴露面與修補優先順序。
| CVE | 摘要 | 來源 | 最高 CVSS | EPSS % | 公開時間 | 更新時間 |
|---|---|---|---|---|---|---|
| CVE-2026-48526 | 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. | [email protected] | 7.4 | 0.02% | 2026-05-28 | 2026-06-01 |
| 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 | [email protected] | 5.3 | 0.05% | 2026-05-28 | 2026-06-01 |
| CVE-2026-48524 | 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 be | [email protected] | 3.7 | 0.06% | 2026-05-28 | 2026-06-01 |
| CVE-2026-48523 | 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, adv | [email protected] | 5.4 | 0.02% | 2026-05-28 | 2026-06-01 |
| CVE-2026-48522 | 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 parame | [email protected] | 4.2 | 0.03% | 2026-05-28 | 2026-06-02 |
| CVE-2026-32597 | PyJWT is a JSON Web Token implementation in Python. Prior to 2.12.0, PyJWT does not validate the crit (Critical) Header Parameter defined in RFC 7515 §4.1.11. When a JWS token contains a crit array listing extensions that PyJWT does not understand, the library accepts the token instead of rejecting it. This violates the MUST requirement in the RFC. This vulnerability is fixed in 2.12.0. | [email protected] | 7.5 | 0.01% | 2026-03-13 | 2026-05-05 |
| CVE-2025-45768 | pyjwt v2.10.1 was discovered to contain weak encryption. NOTE: this is disputed by the Supplier because the key length is chosen by the application that uses the library (admittedly, library users may benefit from a minimum value and a mechanism for opting in to strict enforcement). | [email protected] | 7.0 | 0.16% | 2025-07-31 | 2025-09-12 |
| CVE-2024-53861 | pyjwt is a JSON Web Token implementation in Python. An incorrect string comparison is run for `iss` checking, resulting in `"acb"` being accepted for `"_abc_"`. This is a bug introduced in version 2.10.0: checking the "iss" claim changed from `isinstance(issuer, list)` to `isinstance(issuer, Sequence)`. Since str is a Sequnce, but not a list, `in` is also used for string comparison. This results in `if "abc" not in "__abcd__":` being checked instead of `if "abc" != "__abc__":`. Signature checks | [email protected] | 2.2 | 1.02% | 2024-11-29 | 2025-09-22 |
| CVE-2022-29217 | PyJWT is a Python implementation of RFC 7519. PyJWT supports multiple different JWT signing algorithms. With JWT, an attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify `jwt.algorithms.get_default_algorithms()` to get support for all algorithms, or specify a single algorithm. The issue is not that big as `algorithms=jwt.algorithms.get_default_algorithms()` has t | [email protected] | 7.4 | 0.42% | 2022-05-24 | 2024-11-21 |
| CVE-2017-11424 | In PyJWT 1.5.0 and below the `invalid_strings` check in `HMACAlgorithm.prepare_key` does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string `-----BEGIN RSA PUBLIC KEY-----` which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch. | [email protected] | 7.5 | 0.19% | 2017-08-24 | 2026-05-13 |