EUVD-2026-30560Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
4DescriptionGitHub Advisory
LibJWT is a C JSON Web Token Library. From 3.0.0 to 3.3.2, libjwt accepts an RSA JWK that does not contain an alg parameter as the verification key for an HS256/HS384/HS512 token. In the OpenSSL backend, this causes HMAC verification to run with a zero-length key, so an attacker can forge a valid JWT without knowing any secret or RSA private key. This is an algorithm-confusion authentication bypass. It affects applications that load RSA keys from JWKS where alg is omitted, which is valid JWK syntax and common in real deployments, and then choose the verification algorithm from the JWT header, for example in a kid lookup callback. This vulnerability is fixed in 3.3.3.
AnalysisAI
Algorithm confusion in LibJWT 3.0.0 through 3.3.2 allows authentication bypass when RSA JWKs lack the 'alg' parameter. The OpenSSL backend incorrectly processes HMAC verification with a zero-length key when an RSA key without 'alg' is used to verify HS256/HS384/HS512 tokens, enabling attackers to forge valid JWTs without knowing any secret. Public exploit code exists (SSVC), making this a critical authentication bypass affecting applications using JWKS-based key lookup.
Technical ContextAI
LibJWT is a C library for creating and verifying JSON Web Tokens (JWTs). The vulnerability stems from improper cryptographic algorithm selection (CWE-327) when loading RSA keys from JSON Web Key Sets (JWKS). When an RSA JWK omits the optional 'alg' parameter - which is valid per RFC 7517 and common in production deployments - and the application determines the verification algorithm from the JWT header, LibJWT's OpenSSL backend fails to reject the algorithm mismatch between RSA keys and HMAC algorithms (HS256/HS384/HS512). This results in HMAC verification running with an empty key, always producing the same signature regardless of input.
RemediationAI
Vendor-released patch: upgrade to LibJWT version 3.3.3 or later, which properly validates algorithm compatibility between keys and tokens. Full details available in GitHub Security Advisory GHSA-q843-6q5f-w55g at https://github.com/benmcollins/libjwt/security/advisories/GHSA-q843-6q5f-w55g. For applications that cannot immediately upgrade, implement application-level validation to ensure RSA keys are only used with RS256/RS384/RS512 algorithms and HMAC keys only with HS256/HS384/HS512. Explicitly set the 'alg' parameter in all JWKs to prevent algorithm confusion. As a defense-in-depth measure, consider pinning expected algorithms per key ID rather than accepting the algorithm from untrusted JWT headers.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this
A denial of service flaw was found in OpenSSL 0.9.8, 1.0.1, 1.0.2 through 1.0.2h, and 1.1.0 in the way the TLS/SSL proto
Same technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: CriticalShare
External POC / Exploit Code
Leaving vuln.today