CVE-2026-85394
Description
A flaw was found in python-jose. A remote attacker who obtains the service's public key can exploit an algorithm confusion vulnerability when signature verification algorithms are not strictly restricted. By utilizing a specifically formatted public key as a shared secret key, the attacker can forge valid JSON Web Tokens (JWTs). This flaw allows an attacker to bypass authentication and gain unauthorized access or elevate privileges within the application.
Statement
Attack complexity is higher than AC:L suggests: While the CVSS vector claims AC:L, successful exploitation requires:
- The service must accept multiple signature algorithms (RS256 + HS256) during JWT verification, either explicitly via
algorithms=['RS256', 'HS256']or implicitly viaalgorithms=None(the dangerous default) - The attacker must obtain the service's public key (often available, but not always trivial)
- The attacker must convert the key to DER format
This is more nuanced than "any unauthenticated user can exploit with no special conditions."
- The service must accept multiple signature algorithms (RS256 + HS256) during JWT verification, either explicitly via
The vulnerability is an authentication bypass, not RCE: The direct impact is forging authentication tokens (e.g., elevating to admin). While this could lead to RCE if the compromised service has code execution features (admin panels, file upload, etc.), the vulnerability itself does not execute code.
Mitigation
This flaw can be mitigated by strictly restricting the signature algorithms accepted during JWT verification. Applications using python-jose should always pass an explicit allow-list containing only the intended asymmetric algorithms (for example, algorithms=["RS256"]) when calling jose.jwt.decode(), must not include HMAC algorithms such as HS256 in that list, and must not rely on the default algorithms=None behavior, which permits multiple algorithms. The algorithm-confusion attack requires that HMAC verification be accepted alongside public-key verification, so removing HMAC algorithms from the accepted set prevents an attacker from using the service's public key as an HMAC shared secret to forge tokens. No fixed upstream release is currently available: OSV upstream data lists 3.5.0 as the last affected version with no fixed version, so algorithm restriction remains the available protection.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.4 | N/A | 9.1 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | High | N/A | Low |
| Privileges Required | None | N/A | None |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | High | N/A | High |
| Integrity Impact | High | N/A | High |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
cve.org: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Understanding the Weakness (CWE)
Access Control,Integrity,Confidentiality
Technical Impact: Gain Privileges or Assume Identity; Modify Application Data; Execute Unauthorized Code or Commands
An attacker could gain access to sensitive data and possibly execute unauthorized code.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
