CVE-2026-44699: LibJWT Algorithm Confusion Authentication Bypass via RSA JWK Without alg
LibJWT versions 3.0.0 through 3.3.2 can accept an RSA JWK without an alg parameter as the key for HMAC-based JWT verification, which allows token forgery in the OpenSSL backend. GitHub's CNA field assigns a 9.1 score under CVSS 4.0, and the fix is available in 3.3.3. The CVE is not listed in CISA KEV, and no confirmed exploitation appears in the sources consulted.
Overview
LibJWT is a C library for JSON Web Tokens. According to the GitHub Security Advisory GHSA-q843-6q5f-w55g, versions from 3.0.0 through 3.3.2 accept an RSA JWK that has no alg parameter as the verification key for HS256, HS384 and HS512 tokens. The weakness is classified as CWE-327, Use of a Broken or Risky Cryptographic Algorithm.
Impact
- In the OpenSSL backend, HMAC verification runs with a zero-length key in this scenario.
- An attacker may be able to produce a token that the library accepts as valid, without knowing a shared secret or an RSA private key.
- The description characterizes this as an authentication bypass. The recorded CVSS 4.0 vector marks the attack vector as network, privileges and user interaction as none, attack requirements as present, and high impact on confidentiality and integrity, with no availability impact.
Affected products and versions
- Affected range: LibJWT 3.0.0 through 3.3.2, as stated in the description.
- Fixed version: 3.3.3.
- Exposure pattern: applications that load RSA keys from JWKS where alg is omitted, and that select the verification algorithm from the JWT header, for example in a kid lookup callback.
- The record contains no structured affected or fixed product entries, so this information comes only from the description text.
Exploitation status
The CISA KEV catalog entry in the record shows this CVE as not listed. No confirmed active exploitation or exploitation in the wild appears in the sources consulted. The EPSS probability in the record is 0.00352, with a percentile of 0.26996.
Remediation and mitigation
- Upgrade LibJWT to version 3.3.3 or later.
- Do not let the token header alone determine the verification algorithm. Bind each verification key to an expected algorithm in application configuration.
- Ensure that keys loaded from JWKS without an alg parameter are assigned an explicit, intended algorithm, and that asymmetric keys are never accepted for symmetric HMAC verification.
- If an upgrade is delayed, review which services rely on JWKS-based verification with dynamic algorithm selection and prioritize them.
Detection guidance
- Review authentication logs for tokens whose header declares an HMAC algorithm on services that are configured with asymmetric key material.
- Look for unexpected token acceptance patterns after changes to JWKS handling or to the LibJWT version in use.
- Monitor authentication success rates on JWKS-dependent services for anomalies that do not match normal user activity.
Limitations of the available information
- The record does not provide the commit, patch diff or list of distribution packages that include the fix.
- The description limits the zero-length key behavior to the OpenSSL backend. The behavior of other backends is unknown from the record.
- Whether a particular application is exposed depends on its key loading and algorithm selection code, which is not present in the record.
- The CVSS data and EPSS values are taken as recorded and were not independently verified.
Frequently asked questions
Which LibJWT versions are affected by CVE-2026-44699?
The description states that versions from 3.0.0 through 3.3.2 are affected. The fix is available in version 3.3.3.
Does this CVE affect every application that uses LibJWT?
The description says exposure depends on loading RSA keys from JWKS without an alg parameter and selecting the verification algorithm from the JWT header. Applications without that pattern are not described as affected, but this is an inference from the description.
This analysis was drafted with AI assistance from verified source data and automatically checked against it.