Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft JWT token with attacker public key in jwk header
-
DeliverySign token with matching private key
-
ExploitSubmit forged token to vulnerable application
-
ExecutionApplication accepts token using untrusted jwk header key
-
ImpactAttacker bypasses authentication and authorization
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
|
| Exploitation Conditions | Remote unauthenticated attacker exploiting JOSE library versions prior to 0.3.5+1 when application accepts jwk header parameter for key selection without validating against trusted keystore. No user interaction required. |
| Impact | This vulnerability presents HIGH real-world risk despite moderate CVSS 7.5 scoring. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms network-exploitable attacks with low complexity requiring no authentication or user interaction, though impact is limited to integrity (I:H) rather than confidentiality or availability. The exploitation scenario is straightforward: attackers generate their own RSA/EC key pair, embed the public key in the 'jwk' header, sign malicious claims (e.g., admin privileges, altered user IDs), and the vulnerable library accepts it as valid. No specialized tools are required beyond standard JWT libraries. The authentication bypass impact is severe for applications using this library for access control, session management, or API authorization. While no CISA KEV listing or public exploit code exists, the technical barrier is extremely low-any developer familiar with JWT structure can exploit this. The GitHub commit fix (b07799aac1f56a9a21483feac026272aab30cc5d) confirms vendor acknowledgment and remediation, reducing ongoing risk for patched systems. |
| Exploit ScenarioDerived | An attacker targeting a Dart-based API uses a JWT manipulation tool to craft a malicious access token. They generate a fresh RSA-2048 key pair, create a JWT payload claiming admin privileges (e.g., {"sub":"attacker","role":"admin"}), embed their public key in the JOSE header as {"alg":"RS256","jwk":{"kty":"RSA","n":"[modulus]","e":"AQAB"}}, and sign with their private key. When submitted to the vulnerable API endpoint, the jose library extracts the attacker's public key from the header and successfully validates the self-signed token, granting unauthorized administrative access. The attack requires no prior authentication, leaves minimal forensic traces in standard logs, and can be automated against multiple applications using the vulnerable library version. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Mar 31, 2026
JWT token forgery in appsup-dart/jose library (versions prior to 0.3.5+1) enables remote attackers to bypass authentication by embedding attacker-controlled public keys in JOSE headers. The library incorrectly accepts header-supplied 'jwk' parameters as trusted verification keys without validating they exist in the application's trusted keystore, allowing unauthenticated attackers to sign arbitrary tokens with their own key pairs. EPSS data not available; no public exploit identified at time of analysis, though exploitation requires only standard JWT manipulation tools.
RemediationAI
Upgrade to appsup-dart/jose version 0.3.5+1 or later, which implements proper key validation to reject header-supplied jwk parameters that do not match trusted keystore entries. The fix is available via the GitHub commit at https://github.com/appsup-dart/jose/commit/b07799aac1f56a9a21483feac026272aab30cc5d. For environments unable to immediately upgrade, implement application-layer validation to reject any JWT tokens containing a 'jwk' parameter in the JOSE header, or verify that any header-supplied jwk cryptographically matches a key already present in your application's trusted key configuration. Review authentication logs for anomalous token validations that may indicate exploitation attempts prior to patching.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
JOSE (JavaScript Object Signing and Encryption) libraries implement RFC 7515-7518 standards for JWT token verification. This vulnerability (CWE-347: Improper Verification of Cryptographic Signature) affects the appsup-dart/jose Dart implementation. During JWS/JWT signature verification, the library's key selection logic improperly treats the 'jwk' (JSON Web Key) parameter in the JOSE header as a valid verification candidate. JOSE headers are user-controlled input transmitted with each token, making them untrusted data. The library fails to enforce a critical security boundary: verification keys must come exclusively from the application's pre-configured trusted keystore, never from token headers. This allows algorithmic confusion where the attacker dictates which key verifies their signature, fundamentally breaking the trust model of asymmetric cryptography in authentication systems.
Know when Jose gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Primary rating from Vendor (GitHub_M) · only source for this CVE.
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
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.
Executive ViewAI
The appsup-dart/jose library (versions before 0.3.5+1) contains a JWT token forgery vulnerability that allows unauthenticated attackers to bypass authentication by injecting malicious public keys into token headers. Any application using this library to validate JWT tokens is at risk of complete authentication bypass, potentially exposing all API endpoints and protected resources to unauthorized access.
Apply vendor patch: upgrade to appsup-dart/jose version 0.3.5+1 or later. Interim mitigations pending patch deployment: implement additional validation to reject JOSE headers containing embedded 'jwk' parameters and enforce token validation exclusively against a hardened, application-managed trusted keystore rather than accepting key material from token headers.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
JOSE is "JSON Web Almost Everything" - JWA, JWS, JWE, JWT, JWK, JWKS with no dependencies using runtime's native crypto
Signature verification bypass in the OCaml jose library (ulrikstrid/ocaml-jose) before 0.11.0 lets attackers forge valid
Password-protected private-key exports produced by the Erlang/Elixir `jose` library between 1.10.0 and 1.11.12 are encry
Memory-exhaustion denial of service in the erlang-jose JOSE/JWE library for Erlang and Elixir (versions 1.0.0 through 1.
CPU-exhaustion denial of service in the erlang-jose library (versions 1.7.7 through 1.11.12) lets remote attackers who c
jose is an npm library providing a number of cryptographic operations. Rated medium severity (CVSS 5.9), this vulnerabil
Recovery of a long-term X25519 private key is possible in erlang-jose 1.10.0 through 1.11.12 whenever the pure-Erlang Cu
The Erlang/Elixir JOSE library (potatosalad/erlang-jose) can be driven into an unbounded tail-recursive loop through JOS
Authentication-tag forgery in the Erlang JOSE library (jose 1.2.0 through 1.11.12) lets an unauthenticated remote attack
Bleichenbacher padding-oracle weakness in erlang-jose's pure-Erlang RSAES-PKCS1-v1_5 decryption (jose 1.3.0 through befo
jose is JavaScript module for JSON Object Signing and Encryption, providing support for JSON Web Tokens (JWT), JSON Web
ECDSA JWS signature malleability in erlang-jose (potatosalad:jose) 1.0.0 through 1.11.12 lets anyone holding a single le
EUVD-2026-17498
GHSA-vm9r-h74p-hg97
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB