CVE-2026-34240
Received Received - Intake
JWT Forgery via Header Key Injection in JOSE Library

Publication date: 2026-03-31

Last updated on: 2026-04-06

Assigner: GitHub, Inc.

Description
JOSE is a Javascript Object Signing and Encryption (JOSE) library. Prior to version 0.3.5+1, a vulnerability in jose could allow an unauthenticated, remote attacker to forge valid JWS/JWT tokens by using a key embedded in the JOSE header (jwk). The vulnerability exists because key selection could treat header-provided jwk as a verification candidate even when that key was not present in the trusted key store. Since JOSE headers are untrusted input, an attacker could exploit this by creating a token payload, embedding an attacker-controlled public key in the header, and signing with the matching private key. Applications using affected versions for token verification are impacted. This issue has been patched in version 0.3.5+1. A workaround for this issue involves rejecting tokens where header jwk is present unless that jwk matches a key already present in the application's trusted key store.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-31
Last Modified
2026-04-06
Generated
2026-05-07
AI Q&A
2026-03-31
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
appsup-dart jose to 0.3.5+1 (exc)
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?

The vulnerability exists in the JOSE Javascript Object Signing and Encryption library versions prior to 0.3.5+1. It allows an unauthenticated remote attacker to forge valid JWS/JWT tokens by exploiting the way the library selects keys for verification.

Specifically, the key selection process mistakenly treats a JSON Web Key (JWK) embedded in the untrusted JOSE header as a valid verification key, even if that key is not present in the application's trusted key store. Since JOSE headers are untrusted input, an attacker can create a token with a malicious public key in the header and sign it with the matching private key, bypassing verification controls.

This flaw allows attackers to forge tokens that appear valid to the application using the affected library.


How can this vulnerability impact me? :

This vulnerability can impact you by allowing attackers to forge valid JWS/JWT tokens without authentication. This means an attacker can impersonate users or services by creating tokens that the application will accept as legitimate.

The impact is primarily on the integrity of the system, as attackers can bypass signature verification and potentially gain unauthorized access or perform actions with elevated privileges.

There is no impact on confidentiality or availability, but the integrity compromise can lead to serious security breaches.


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

This vulnerability can be detected by inspecting JWT tokens used in your system to see if they contain a JSON Web Key (jwk) in the JOSE header that is not part of your trusted key store.

You can check logs or token verification failures where tokens with header jwk keys that do not match trusted keys are accepted or rejected.

Since the vulnerability involves accepting untrusted keys from JWT headers, you can use application-level logging or debugging to identify tokens with embedded jwk headers.

There are no specific network commands provided in the resources, but you can use tools like 'jwt-cli' or custom scripts to decode JWT tokens and inspect their headers for the presence of jwk fields.

  • Use a JWT decoding tool or command to inspect tokens, for example: jwt decode <token>
  • Search application logs for tokens containing 'jwk' in the header.
  • Monitor token verification failures related to key mismatches.

What immediate steps should I take to mitigate this vulnerability?

The primary mitigation is to upgrade the jose library to version 0.3.5+1 or later, where the key resolution logic has been improved to prevent acceptance of untrusted keys embedded in JWT headers.

As an immediate workaround, configure your application to reject any tokens that contain a jwk field in the header unless that jwk matches a key already present in your trusted key store.

This prevents attackers from forging tokens by embedding malicious keys in the header.


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

This vulnerability allows an unauthenticated remote attacker to forge valid JWS/JWT tokens by exploiting improper verification of cryptographic signatures. Such token forgery can lead to unauthorized access or actions within applications relying on these tokens for authentication and authorization.

Because the integrity of token verification is compromised, applications affected by this vulnerability may fail to enforce proper access controls, potentially leading to violations of security requirements mandated by common standards and regulations such as GDPR and HIPAA.

Specifically, the high integrity impact (CVSS 7.5) indicates that attackers can manipulate data or authentication states, which could result in unauthorized data access or modification, thereby risking non-compliance with data protection and privacy regulations.

Mitigation by upgrading to a patched version or rejecting tokens with untrusted header keys is essential to maintain compliance and secure handling of sensitive data.


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