GHSA-vm9r-h74p-hg97 CVE-2026-34240
jose vulnerable to untrusted JWK header key acceptance during signature verification
- Severity
- 7.5 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.14%
- Chance of exploitation in the next 30 days. Higher than 2.96% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-347 Improper Verification of Cryptographic Signature
- Fix
0.3.5+1- Upgrade jose to this version or later
Description
Impact
A vulnerability in jose versions up to and including 0.3.5 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.
Patches
Upgrade to 0.3.5+1 or later.
Workarounds
Reject tokens where header jwk is present unless that jwk matches a key already present in the application's trusted key store.
Resources
Fix commit: fix: improved key resolution in JsonWebKeyStore
Affected versions
Pub
| Package | Vulnerable | Fixed in |
|---|---|---|
| jose | < 0.3.5+1 |
0.3.5+1 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
jose Pub → 0.3.5+1
- dart
dart pub add jose:^0.3.5+1
Severity breakdown
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- High
- Availability
- None
Weakness
CWE-347: Improper Verification of Cryptographic Signature
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| EEF-CVE-2026-65632 ECDSA signature length is not validated in jose, allowing signature malleability | Not rated yet | Same weakness, CWE-347 |
| GHSA-pxh4-856f-4h89 PyJWT: HS256/384/512 verify accepts empty HMAC key via oct JWK (PyJWK/PyJWKClient) enabling token forgery | High | Same weakness, CWE-347 |
| GHSA-j7h2-66j4-ghjf A russh SSH server accepts a publickey authentication whose signature uses a different algorithm than the one named in the request | Low | Same weakness, CWE-347 |
| GHSA-w2cx-738m-mc7w PyJWT accepts public JWK containers as HMAC secrets | High | Same weakness, CWE-347 |
| GHSA-r6x4-923q-g947 PyJWT BOM Bypass | High | Same weakness, CWE-347 |
| GHSA-p4g4-x82p-q773 PyJWT: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard | High | Same weakness, CWE-347 |
| GHSA-ffc3-869f-jxw9 PyJWT: Asymmetric-PEM detection bypass: whitespace/line-ending-mutated public keys skip the HS/asymmetric confusion guard | Critical | Same weakness, CWE-347 |
| GHSA-9j54-fg26-wv3r PyJWT: PyJWK accepts empty HMAC keys, bypassing PyJWT's empty-key validation | Critical | Same weakness, CWE-347 |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor