PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-44699 benmcollins CVE debrief

LibJWT versions 3.0.0 through 3.3.2 contain a critical algorithm confusion vulnerability that enables authentication bypass. The library accepts RSA JWKs lacking an `alg` parameter as verification keys for HMAC-signed tokens (HS256/HS384/HS512). When this occurs with the OpenSSL backend, HMAC verification executes with a zero-length key, allowing attackers to forge valid JWTs without possessing any secret or private key material. This affects applications that load RSA keys from JWKS endpoints where `alg` is omitted—a valid and common JWK configuration—and dynamically select verification algorithms from JWT headers, such as during `kid`-based key lookup callbacks. The vulnerability was disclosed on 2026-05-15 and last modified on 2026-05-18.

Vendor
benmcollins
Product
libjwt
CVSS
CRITICAL 9.1
CISA KEV
Not listed in stored evidence
Original CVE published
2026-05-15
Original CVE updated
2026-05-18
Advisory published
2026-05-15
Advisory updated
2026-05-18

Who should care

Organizations using LibJWT for JWT verification in applications that consume JWKS from external identity providers or key management services; security teams responsible for authentication and authorization infrastructure; developers implementing JWT validation with dynamic key resolution; DevSecOps teams managing C/C++ dependencies with cryptographic functions

Technical summary

The vulnerability stems from missing algorithm validation when mapping JWK key types to verification operations. When an RSA public key JWK without an `alg` field is supplied for token verification, and the token header specifies an HMAC algorithm (HS256/HS384/HS512), LibJWT incorrectly uses the RSA key material for HMAC operations. In the OpenSSL backend implementation, this results in HMAC verification with a zero-length key, making signature validation trivially bypassable. The attack requires: (1) application loads RSA keys from a JWKS where `alg` is omitted; (2) application selects verification algorithm from JWT header rather than enforcing expected algorithms; (3) attacker presents a forged JWT with HMAC algorithm and valid `kid` pointing to the RSA key. This is a classic algorithm confusion (JWS algorithm substitution) attack with severe impact due to the zero-length key condition.

Defensive priority

critical

Recommended defensive actions

  • Upgrade LibJWT to version 3.3.3 or later to remediate this vulnerability
  • Audit application code for JWT verification patterns that load RSA keys from JWKS endpoints without explicit algorithm validation
  • Ensure verification algorithms are not selected solely from JWT headers when using keys from external JWKS sources
  • Validate that JWK entries contain explicit `alg` parameters before use in cryptographic operations
  • Review and test JWT validation logic to confirm HMAC verification does not proceed with insufficient key material
  • Implement defense-in-depth by enforcing expected algorithm constraints independently of token header claims

Evidence notes

Vulnerability confirmed through GitHub Security Advisory GHSA-q843-6q5f-w55g. Affects LibJWT 3.0.0-3.3.2. Fixed in 3.3.3. CVSS 4.0 vector: AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. CWE-327 (Use of Broken or Risky Cryptographic Algorithm) and CWE-347 (Improper Verification of Cryptographic Signature) identified.

Official resources

2026-05-15