CVE-2026-48523
Received Received - Intake
Algorithm Allow-List Bypass in PyJWT

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: GitHub, Inc.

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
pyjwt pyjwt From 2.9.0 (inc) to 2.13.0 (exc)
pyjwt pyjwt to 2.13.0 (exc)
pyjwt pyjwt 2.13.0
pyjwt pyjwt From 2.9.0 (inc) to 2.12.1 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-347 The product does not verify, or incorrectly verifies, the cryptographic signature for data.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-48523 is a vulnerability in PyJWT versions 2.9.0 through 2.12.1 that allows an algorithm allow-list bypass when decoding JSON Web Tokens (JWTs) using PyJWK or PyJWKClient keys.

The problem occurs because the verification process checks the JWT header's algorithm against the allowed algorithms list provided by the caller, but the actual signature verification uses the algorithm bound to the PyJWK object instead of the algorithm specified in the JWT header.

This means an attacker who controls a registered JWK/JWKS private key can sign a token with a disallowed algorithm but claim an allowed algorithm in the JWT header, causing the token to be accepted despite violating the algorithm policy.

The vulnerability affects the documented PyJWKClient.get_signing_key_from_jwt() flow and was fixed in PyJWT version 2.13.0.


How can this vulnerability impact me? :

This vulnerability can allow attackers to bypass server-side algorithm restrictions when verifying JWTs, potentially enabling them to use deprecated or disallowed algorithms for signing tokens.

In environments where external parties control signing keys, such as OAuth client assertions, multi-tenant systems, or federation models, attackers can authenticate successfully despite failing algorithm checks.

However, the vulnerability does not allow token forgery without a valid signing key, so the attacker must control a registered private key to exploit this issue.

Overall, this can lead to unauthorized access or privilege escalation by bypassing intended security policies.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves an algorithm allow-list bypass in PyJWT versions 2.9.0 through 2.12.1 when decoding JWTs with PyJWK or PyJWKClient keys. Detection involves identifying usage of these PyJWT versions and verifying if the application uses the PyJWKClient.get_signing_key_from_jwt() flow.

To detect exploitation attempts on your system or network, you can monitor JWT decoding logs for tokens where the header algorithm differs from the algorithm bound to the PyJWK object used for verification.

Specific commands depend on your environment, but general approaches include:

  • Checking the installed PyJWT version: `pip show pyjwt` or `pip freeze | grep pyjwt`
  • Reviewing application logs for JWT decode errors or suspicious tokens.
  • Using network monitoring tools (e.g., Wireshark, tcpdump) to capture JWT tokens and inspecting their headers and signature algorithms.
  • Writing custom scripts to decode JWT tokens and compare the header algorithm against the algorithm used for signature verification if accessible.

What immediate steps should I take to mitigate this vulnerability?

The primary mitigation step is to upgrade PyJWT to version 2.13.0 or later, where this vulnerability is fixed.

Additionally, review your JWT verification logic to ensure that the algorithm used for signature verification matches the algorithm specified in the JWT header and that the allow-list is properly enforced.

If upgrading immediately is not possible, consider restricting or auditing the set of signing keys and algorithms allowed, especially in environments where external parties control signing keys.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows an attacker who controls a registered JWK/JWKS private key to bypass algorithm allow-list checks during JWT verification. This can lead to the acceptance of tokens signed with disallowed or deprecated algorithms, potentially undermining the integrity and authenticity of authentication tokens.

Such a weakness in token verification could impact compliance with common security standards and regulations like GDPR and HIPAA, which require strong authentication and data protection measures. By bypassing algorithm restrictions, the vulnerability may allow unauthorized access or authentication failures, thereby increasing the risk of data breaches or unauthorized data processing.

Therefore, organizations relying on PyJWT versions 2.9.0 to 2.12.1 in environments where external parties control signing keys should consider this vulnerability a risk to their compliance posture until they upgrade to version 2.13.0 or later.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart