Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify service verifying JWS via ocaml-jose
-
DeliveryForge JWT with attacker payload
-
ExploitAttach PKCS#1-decodable signature blob
-
ExecutionSubmit token to verify endpoint
-
PersistVerification skips public-key check
-
ImpactToken accepted, impersonate any principal
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
|
| Exploitation Conditions | Exploitation requires that the target application uses ocaml-jose before 0.11.0 to verify RSA-signed (RSASSA-PKCS1, e.g. RS256) JWS/JWT tokens and trusts the verification result for authentication or authorization; the attacker must be able to submit a token to that verification path (typical for any network-facing token-accepting endpoint). No valid signature, private key, credentials, or user interaction is needed - the attacker only needs to produce a token whose signature block is PKCS #1-decodable. Limiting factors are deployment-specific: applications using HMAC/EC algorithms via other code paths, or not relying on ocaml-jose's RSA verification, are not exposed, and the overall attack surface is bounded by the library's niche OCaml user base. |
| Impact | This is a genuine high-priority cryptographic defect rather than an inflated high-CVSS score: the CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N describes remote, unauthenticated, low-complexity exploitation with high confidentiality and integrity impact, and the code diff confirms the verification step was entirely absent, so the vector is consistent with the evidence. Because a forged token is accepted as authentic, this collapses whatever authentication or authorization any consuming application built on top of JWS - the practical impact is full authentication bypass and impersonation of any principal, which is why even a mid-sized municipal IT team in mielec running an OCaml service that trusts these tokens should treat patching as urgent. No EPSS score, KEV listing, or public POC is provided, so there is no evidence of active exploitation yet; the risk is driven by exploit simplicity and the severity of consequence rather than by observed attacks. The only mitigating factor is deployment footprint: ocaml-jose is a niche library, so exposure is limited to the specific OCaml applications that use it for token verification. |
| Exploit ScenarioDerived | An attacker crafts a JWT with a chosen payload (for example, an admin identity or elevated scopes) and attaches a signature blob that merely decodes under PKCS #1 rather than one produced with the legitimate private key. A service using ocaml-jose before 0.11.0 accepts the token as valid because it never runs the RSA public-key check, granting the attacker authenticated access. No credentials or user interaction are required, and no public POC has been published. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 10, 2026
Signature verification bypass in the OCaml jose library (ulrikstrid/ocaml-jose) before 0.11.0 lets attackers forge valid RSA-signed JWS/JWT tokens. The RSA verify path in Jws.ml only confirmed that PKCS #1 decoding succeeded and then returned success, never performing the RSA public-key operation that actually authenticates the signature. Any attacker can craft a token with an arbitrary payload and a syntactically well-formed but cryptographically meaningless signature and have it accepted as valid; no public exploit identified at time of analysis, but the flaw is trivially exploitable once understood.
RemediationAI
Upgrade ocaml-jose to version 0.11.0 or later, which adds the missing RSA public-key verification (Vendor-released patch: 0.11.0; see the fix commit cf17d991 and OSEC-2026-19). Rebuild and redeploy all downstream OCaml services and opam dependencies that pin an earlier version, since the vulnerable code path is in the library itself. Until the upgrade is deployed, treat all RSA-signed tokens verified by the affected code as untrustworthy: where feasible, disable acceptance of externally supplied JWS/JWT for authentication, or add an independent verification step that performs the RSA public-key check before honoring a token - accepting the trade-off of added integration work and possible rejection of legitimate tokens if algorithm handling differs. Because the patched verify uses a permissive hash predicate (hashp accepts any hash), also enforce an explicit expected-algorithm allowlist in application code to prevent algorithm-confusion abuse.
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
The library implements JSON Web Signature (JWS) verification for JSON Web Tokens (CPE cpe:2.3:a:ocaml:jose). The root cause is CWE-347 (Improper Verification of Cryptographic Signature): for RSA (RS256-style) tokens, the code decoded the PKCS #1 signature block and, if decoding produced a message, declared the token valid without ever running the RSA public-key verification that ties the signature to the signer's key. The fix commit (cf17d991) introduces verify_rsa, which calls Mirage_crypto_pk.Rsa.PKCS1.verify with the JWK's public key against the signing input before returning Ok, and otherwise returns 'payload does not match'. Notably the fix uses hashp:(fun _ -> true), meaning it validates the RSA operation but does not itself constrain the hash algorithm, so callers must still enforce expected algorithms.
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:H/I:H/A:N
Remote unauthenticated token forgery with no user interaction; forged tokens bypass auth, yielding high confidentiality and integrity impact but no availability impact.
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
2DescriptionCVE.org
In the jose package before 0.11.0 for OCaml, library calls to validate an RSA signature only confirm that PKCS #1 decoding succeeds, and proceed to declare the signature valid without the required steps that involve the public key.
Executive ViewAI
The ocaml-jose cryptographic library contains a critical signature verification bypass that allows attackers to forge valid authentication tokens, creating a direct authentication bypass for any system using this library to validate user access. This vulnerability affects APIs, microservices, and enterprise applications relying on JWT or JWS token validation, exposing the organization to unauthorized access, data breach, and account compromise. Leadership must prioritize immediate patching of this library across all systems.
Apply vendor patch by upgrading ocaml-jose to version 0.11.0 or later.
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
JWT token forgery in appsup-dart/jose library (versions prior to 0.3.5+1) enables remote attackers to bypass authenticat
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-75708
GHSA-9r5j-37q2-cffw
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB