python-jose Algorithm Confusion / Key Type Confusion Token Forgery

Technical Analysis

The vulnerability stems from python-jose's HMAC key initialization logic improperly accepting DER-encoded asymmetric public keys as if they were symmetric HMAC secrets, without requiring PEM armor or SSH key prefixes to reject non-HMAC key material. An attacker who obtains a service's public RSA/EC key (often publicly distributed via JWKS endpoints, OIDC discovery, or embedded in client apps) can construct a token signed with HS256 using that public key as the HMAC secret; if the relying party's jose.jwt.decode() call does not pin algorithms=['RS256'] or equivalent, the forged signature validates successfully, granting the attacker arbitrary claims (e.g., admin roles, elevated scopes). This is a classic JWT algorithm confusion attack (RS256-to-HS256 downgrade), and CVE-2026-85394 represents an incomplete remediation of CVE-2024-33663, meaning prior patches did not fully close the key-type validation gap. CVSS 9.1 reflects the low attack complexity (public key is often trivially obtainable) combined with critical impact (full auth bypass, privilege escalation, potential lateral movement). For AI agent systems, this is highly consequential: many agent frameworks, RAG pipelines, and multi-tool orchestration platforms use python-jose to validate JWTs for API gateway auth, inter-agent service tokens, and MCP/tool-call authorization — a forged token could let an attacker impersonate a trusted agent or user, exfiltrate API keys/secrets managed by the agent, or trigger unauthorized tool execution with elevated privileges.

Affected Systems

Applications using python-jose library versions through 3.5.0 for JWT encoding/decoding, specifically services that do not explicitly enforce algorithms=['RS256'] (or equivalent asymmetric-only allowlist) in jwt.decode() calls; commonly affects Python-based API backends, OAuth2/OIDC relying parties, microservice authentication layers, and AI agent orchestration frameworks (e.g., LangChain-based services, custom MCP servers, FastAPI/Flask apps) that use python-jose for bearer token validation.

Indicators of Compromise

• N/A - this is a logic/design flaw in library code, not associated with known malware hashes, IPs, or domains.
• Detection focus: JWT tokens with alg=HS256 header presented to endpoints expecting RS256/ES256 verification
• Anomalous authentication events where HS256 tokens are accepted by services configured for asymmetric key verification

Remediation Steps

1. 1

   Upgrade python-jose

   Monitor for and apply the forthcoming patched release of python-jose that fully addresses key-type validation; track upstream GitHub advisories for the official fix beyond 3.5.0.

2. 2

   Explicitly restrict algorithms

   Update all jwt.decode() calls to pass an explicit algorithms parameter (e.g., algorithms=['RS256']) rather than relying on library defaults or accepting the algorithm from the token header.

3. 3

   Enforce key-type binding

   Bind each key to its expected algorithm family at the application layer (e.g., separate key stores for HMAC secrets vs. RSA/EC public keys) so a public key can never be used as an HMAC secret.

4. 4

   Consider library migration

   Evaluate migrating to actively maintained, security-hardened JWT libraries (e.g., PyJWT with strict algorithm enforcement, or authlib) if python-jose patch timelines are uncertain.

5. 5

   Audit agent and service authentication paths

   For AI agent deployments, audit all inter-service and tool-call authentication that relies on python-jose to confirm algorithm confusion is not exploitable, given the potential for agent impersonation or credential/API key exposure.

6. 6

   Rotate exposed keys and monitor

   Rotate signing keys where public keys have been broadly exposed, and add monitoring/alerting for JWTs with unexpected alg values reaching verification endpoints.