CVE-2025-59420
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-22

Last updated on: 2025-11-03

Assigner: GitHub, Inc.

Description
Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to version 1.6.4, Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (crit), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, bork or cnf) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation. This issue has been patched in version 1.6.4.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-22
Last Modified
2025-11-03
Generated
2026-05-07
AI Q&A
2025-09-22
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
authlib authlib to 1.6.4 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-863 The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
CWE-345 The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in Authlib versions prior to 1.6.4 involves improper handling of JSON Web Signature (JWS) tokens that contain unknown critical header parameters (the "crit" header). According to RFC 7515, recipients must understand and enforce every header parameter listed in "crit" or reject the token. However, Authlib incorrectly accepts tokens with unknown critical headers, such as "bork" or "cnf", which strict verifiers reject. This flaw allows attackers to craft signed tokens that bypass intended verification, leading to inconsistent token acceptance across different services (split-brain verification). This can result in authorization bypass, replay attacks, or privilege escalation. [1]


How can this vulnerability impact me? :

The vulnerability can impact you by allowing attackers to bypass security policies and authorization controls. Because Authlib accepts tokens with unknown critical headers that other strict verifiers reject, an attacker can exploit this to perform replay attacks, escalate privileges, or bypass intended access restrictions. This can lead to unauthorized access to protected resources or services in environments where Authlib is used for token verification, especially in mixed-language or heterogeneous systems. [1]


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

This vulnerability can be detected by analyzing JSON Web Tokens (JWTs) or JSON Web Signatures (JWS) processed by Authlib versions prior to 1.6.4 to check if tokens with unknown critical header parameters ("crit") are accepted. You can capture tokens in your system or network traffic and inspect their headers for unknown or unhandled critical parameters such as "bork" or "cnf". Since the vulnerability involves improper acceptance of such tokens, a practical detection method is to attempt to deserialize tokens with crafted critical headers using the vulnerable Authlib version and observe if they are accepted. Specific commands depend on your environment, but for example, in Python you could write a script using Authlib 1.6.3 to deserialize tokens with unknown "crit" headers and see if they are accepted. Additionally, monitoring logs for unexpected token acceptance or authorization bypass events may help. No explicit commands are provided in the resources. [1]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include upgrading Authlib to version 1.6.4 or later, where this vulnerability is patched. The patch enforces strict validation of the "crit" header by rejecting tokens with unknown or unprotected critical header parameters, ensuring compliance with RFC 7515 §4.1.11. If upgrading is not immediately possible, implement strict validation of JWT/JWS tokens in your application by rejecting tokens containing unknown critical headers or those with critical headers in unprotected segments. Enforce an allowlist of recognized critical headers and validate their semantics, for example, enforcing token binding when "cnf" is present. Monitoring and blocking tokens with suspicious critical headers can also help reduce risk until the patch is applied. [1, 2]


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