CVE-2026-34240: JOSE Library Auth Bypass Vulnerability

CVE-2026-34240 Overview

A critical authentication bypass vulnerability has been identified in the JOSE (Javascript Object Signing and Encryption) library for Dart. Prior to version 0.3.5+1, the library contains a flaw that allows unauthenticated, remote attackers to forge valid JWS (JSON Web Signature) and JWT (JSON Web Token) tokens by exploiting improper key selection during signature verification.

Critical Impact

Attackers can forge valid authentication tokens, potentially gaining unauthorized access to protected resources and impersonating legitimate users across any application relying on this library for token verification.

Affected Products

• JOSE Dart library versions prior to 0.3.5+1
• Applications using affected JOSE versions for JWT/JWS token verification
• Systems relying on header-embedded JWK for cryptographic operations

Discovery Timeline

• 2026-03-31 - CVE CVE-2026-34240 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-34240

Vulnerability Analysis

This vulnerability stems from improper verification of cryptographic signatures (CWE-347) in the JOSE library's token validation process. The core issue lies in how the library handles the jwk (JSON Web Key) parameter embedded within JOSE headers during signature verification.

When processing a signed token, the library's key selection mechanism incorrectly treats a jwk value present in the token header as a valid verification candidate, even when that specific key does not exist in the application's configured trusted key store. Since JOSE headers are considered untrusted input by design, this behavior creates a significant security gap that undermines the entire trust model of JWT-based authentication.

The vulnerability allows network-based exploitation without requiring any authentication or user interaction. The impact is primarily to integrity, as attackers can forge tokens that applications will accept as legitimate.

Root Cause

The root cause is a flawed key selection algorithm in the JOSE library's verification logic. The library fails to enforce a critical security boundary: the distinction between keys provided by the application's trusted key store and keys embedded in the untrusted token header itself.

Specifically, when the verification routine encounters a jwk parameter in the header, it erroneously adds this attacker-controllable key to the pool of candidate verification keys. This design flaw violates the fundamental principle that cryptographic keys used for verification must originate from a trusted source controlled by the application, not from the data being verified.

Attack Vector

An attacker can exploit this vulnerability through the following attack pattern:

1. Token Payload Construction: The attacker crafts a malicious JWT payload containing claims that grant unauthorized access or elevated privileges
2. Key Generation: The attacker generates their own RSA or EC key pair
3. Header Manipulation: The attacker embeds their public key in the JWT header using the jwk parameter
4. Token Signing: The attacker signs the token using their own private key
5. Token Submission: The forged token is submitted to the target application

The vulnerable JOSE library will verify the signature using the attacker-provided public key from the header, treating it as a legitimate verification key. Since the signature is mathematically valid (signed with the matching private key), verification succeeds, and the application accepts the forged token as authentic.

This attack requires no prior access to the target system's cryptographic keys and can be executed entirely remotely over the network.

Detection Methods for CVE-2026-34240

Indicators of Compromise

• JWT/JWS tokens containing jwk header parameters that do not match keys in the application's trusted key store
• Unexpected or anomalous authentication events from previously unknown key identifiers
• Tokens with claims granting elevated privileges that were not issued by legitimate identity providers
• Authentication logs showing successful verification of tokens with unrecognized key fingerprints

Detection Strategies

• Implement logging and alerting for any token that contains a jwk header parameter during verification
• Monitor for authentication patterns where the verifying key does not match any pre-registered trusted keys
• Deploy application-level detection to flag tokens where the header-embedded key differs from expected key material
• Review audit logs for privilege escalation patterns following JWT-based authentication

Monitoring Recommendations

• Enable verbose logging in authentication middleware to capture full token header details
• Implement real-time alerting for tokens verified with non-trusted key sources
• Establish baseline metrics for normal authentication patterns and alert on deviations
• Correlate authentication events across services to identify potential token forgery campaigns

How to Mitigate CVE-2026-34240

Immediate Actions Required

• Upgrade the JOSE Dart library to version 0.3.5+1 or later immediately
• Audit application code to identify all instances where the JOSE library is used for token verification
• Review authentication logs for any evidence of exploitation using header-embedded keys
• Implement the recommended workaround if immediate patching is not possible

Patch Information

The vulnerability has been addressed in JOSE library version 0.3.5+1. The fix ensures that header-provided jwk values are no longer automatically considered as verification candidates unless explicitly allowed and validated against the trusted key store.

For detailed patch changes, refer to the GitHub Commit Changes. Additional context and security guidance is available in the GitHub Security Advisory.

Workarounds

• Implement pre-verification checks to reject any tokens where the jwk header parameter is present
• Validate that any jwk in the header exactly matches a key already present in the application's trusted key store before proceeding with verification
• Add custom token validation middleware that strips or blocks untrusted header parameters before passing tokens to the JOSE library
• Consider implementing an allowlist of acceptable key identifiers (kid) and reject tokens with unknown key references

# Configuration example
# Update pubspec.yaml to use patched version
# Ensure JOSE library is at minimum version 0.3.5+1
dependencies:
  jose: ^0.3.5+1

# Run dependency update
dart pub upgrade jose

# Verify installed version
dart pub deps | grep jose