CVE-2026-44699: LibJWT Auth Bypass Vulnerability

CVE-2026-44699 Overview

CVE-2026-44699 is an algorithm confusion authentication bypass in LibJWT, a C library for JSON Web Tokens. The vulnerability affects versions 3.0.0 through 3.3.2. LibJWT accepts an RSA JSON Web Key (JWK) that omits the alg parameter as a verification key for HMAC-based tokens (HS256, HS384, HS512). In the OpenSSL backend, this triggers HMAC verification using a zero-length key. An attacker can forge a valid JWT without knowing any secret or RSA private key. The flaw is fixed in version 3.3.3.

Critical Impact

Attackers can forge arbitrary JWTs and bypass authentication on any service that loads RSA keys from a JWKS without an alg field and selects the verification algorithm from the JWT header.

Affected Products

• LibJWT 3.0.0 through 3.3.2
• Applications using LibJWT with the OpenSSL backend
• Services loading RSA keys from JWKS endpoints without an alg parameter

Discovery Timeline

• 2026-05-15 - CVE-2026-44699 published to NVD
• 2026-05-18 - Last updated in NVD database

Technical Details for CVE-2026-44699

Vulnerability Analysis

The vulnerability is a classic algorithm confusion flaw [CWE-327: Use of a Broken or Risky Cryptographic Algorithm]. LibJWT permits the verification algorithm to be selected from the attacker-controlled JWT header. When an application loads an RSA key from a JWKS and the JWK lacks an alg parameter, LibJWT does not bind the key to its intended asymmetric algorithm.

An attacker submits a token with a header specifying HS256, HS384, or HS512. The library then routes the RSA public key into the HMAC verification path. In the OpenSSL backend, the key material is converted in a way that yields a zero-length HMAC key. The attacker can compute the HMAC of any payload using an empty key and produce a signature that LibJWT accepts.

Omitting alg from a JWK is valid syntax under RFC 7517. Many production identity providers and JWKS endpoints emit keys without this field, making the exposure realistic rather than theoretical.

Root Cause

The root cause is the absence of algorithm-key binding during verification. LibJWT trusts the alg value supplied in the JWT header instead of constraining verification to the key type. When a kid lookup callback returns an RSA key for an HMAC-typed token, no type check rejects the mismatch, and the OpenSSL HMAC routine proceeds with an empty key.

Attack Vector

The attack is remote and unauthenticated. An attacker crafts a JWT with a header indicating an HMAC algorithm and a kid that resolves to an RSA key in the target's JWKS. The HMAC is computed over the header and payload using a zero-length key. Because the verifier reproduces the same empty-key HMAC, the forged token validates successfully.

The vulnerability mechanism is described in the GitHub Security Advisory GHSA-q843-6q5f-w55g. No verified proof-of-concept code is published in the references provided.

Detection Methods for CVE-2026-44699

Indicators of Compromise

• JWTs received with header alg set to HS256, HS384, or HS512 while the application is configured to accept RSA-signed tokens
• Authentication events tied to a kid that maps to an RSA key in the JWKS but arrives with an HMAC algorithm in the header
• Unexpected successful authentications from IP addresses not previously seen for a given account or service principal

Detection Strategies

• Inspect application and reverse-proxy logs for JWT headers whose algorithm does not match the key type referenced by the kid
• Add validation middleware that records algorithm-key mismatches as security events before downstream processing
• Audit dependency manifests for LibJWT versions between 3.0.0 and 3.3.2 across builds and containers

Monitoring Recommendations

• Alert on authentication tokens accepted with an empty or zero-length signing key path
• Monitor JWKS endpoints for keys missing the alg parameter and flag them for review
• Track outbound calls and privileged actions performed by sessions established through JWT-based authentication for anomalous post-auth behavior

How to Mitigate CVE-2026-44699

Immediate Actions Required

• Upgrade LibJWT to version 3.3.3 or later across all builds, containers, and packaged applications
• Reject any inbound JWT whose header alg does not match the key type expected for the referenced kid
• Populate alg on every JWK published in internal JWKS endpoints to remove the ambiguity exploited by this flaw

Patch Information

The maintainers fixed the vulnerability in LibJWT 3.3.3. The patch enforces algorithm-key binding so an RSA JWK cannot be used to verify an HMAC-signed token. Rebuild any application statically linked against LibJWT and redeploy dynamic library updates to all hosts. Refer to the GitHub Security Advisory GHSA-q843-6q5f-w55g for the upstream fix details.

Workarounds

• In the kid lookup callback, return the key only when the header algorithm matches the key's intended algorithm
• Maintain an allowlist of accepted JWT algorithms per endpoint and reject all others before signature verification
• Configure JWKS producers to always include the alg field for each published key

# Pin LibJWT to the patched release when building from source
git clone https://github.com/benmcollins/libjwt.git
cd libjwt
git checkout v3.3.3
cmake -S . -B build && cmake --build build