Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2024-54150

CVE-2024-54150: cjwt JWT Auth Bypass Vulnerability

CVE-2024-54150 is an authentication bypass flaw in cjwt, a C JSON Web Token library, caused by algorithm confusion that allows attackers to forge tokens. This article covers the technical details, affected versions, and mitigation.

Published:

CVE-2024-54150 Overview

CVE-2024-54150 is an Authentication Bypass vulnerability affecting cjwt, a C JSON Web Token (JWT) implementation developed by xmidt-org. The vulnerability stems from algorithm confusion, which occurs when the system improperly verifies the type of signature used during JWT validation. This allows attackers to exploit the lack of distinction between symmetric and asymmetric signing methods, potentially bypassing authentication mechanisms entirely.

Critical Impact

Attackers can craft malicious JWTs that bypass signature verification by exploiting algorithm confusion, leading to unauthorized access to protected resources and potential full authentication bypass.

Affected Products

  • cjwt versions prior to 2.3.0
  • Applications using cjwt for JWT verification with asymmetric algorithms (RS256, ES256, PS256)
  • Systems that do not explicitly restrict algorithm types during token verification

Discovery Timeline

  • December 19, 2024 - CVE-2024-54150 published to NVD
  • December 20, 2024 - Last updated in NVD database

Technical Details for CVE-2024-54150

Vulnerability Analysis

The algorithm confusion vulnerability in cjwt arises from the library's failure to properly differentiate between HMAC-signed tokens (symmetric) and RSA/EC/PS-signed tokens (asymmetric) during the verification process. When an application expects asymmetric algorithm tokens (such as RS256), an attacker can craft a token with the alg header field set to HS256. The vulnerable library then mistakenly uses the public key—which is often publicly available—as the HMAC secret key for verification.

This attack is particularly dangerous because for RSA-based systems, the key can be computed from a few signatures. For Elliptic Curve (EC) implementations, two potential keys can be recovered from just one signature. This makes the attack highly practical in real-world scenarios where public keys are exposed through JWKS endpoints or embedded in application configurations.

Root Cause

The root cause is classified under CWE-347 (Improper Verification of Cryptographic Signature). The cjwt library did not enforce algorithm type restrictions during JWT verification, allowing tokens signed with symmetric algorithms to be verified against asymmetric key material. The library lacked a mechanism to explicitly specify which algorithm families were permitted, enabling the algorithm substitution attack.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can execute this attack by:

  1. Obtaining the target application's public key (often publicly available via JWKS endpoints)
  2. Crafting a JWT with the alg header set to HS256 instead of the expected asymmetric algorithm
  3. Signing the forged JWT using the public key as the HMAC secret
  4. Submitting the malicious token to the application, which incorrectly validates it

The following code shows the security patch that introduces the OPT_ALLOW_ONLY_HS_ALG flag to mitigate this vulnerability:

c
  */
 #define OPT_ALLOW_ANY_TYP (1 << 2)
 
+/* If you specify OPT_ALLOW_ONLY_HS_ALG as part of the options bitmask you
+ * are allowing only the use of HMAC-SHA algorithms (HS256, HS384, HS512).
+ * Otherwise only public key algorithms are allowed.
+ *
+ * Symmetric algorithms and the unknown key type passed in pose a security
+ * risk since an attacker can treate the provided public key as the secret
+ * key and sign their own JWTs with the public key as a symmetric key.
+ */
+#define OPT_ALLOW_ONLY_HS_ALG (1 << 3)
 
 /*----------------------------------------------------------------------------*/
 /*                               Data Structures                              */

Source: GitHub Commit Details

Detection Methods for CVE-2024-54150

Indicators of Compromise

  • JWT tokens with mismatched algorithm headers (e.g., HS256 tokens submitted to endpoints expecting RS256)
  • Authentication logs showing successful validation of tokens with unexpected algorithm types
  • Anomalous access patterns from users with tokens that should have failed signature verification

Detection Strategies

  • Implement logging to capture the alg header value of all incoming JWT tokens and alert on unexpected algorithm types
  • Monitor for authentication events where token algorithm differs from the configured expected algorithm
  • Deploy application-layer inspection to detect JWT manipulation attempts at the network perimeter
  • Review audit logs for successful authentications with unusual token characteristics

Monitoring Recommendations

  • Enable verbose JWT validation logging in applications using cjwt to capture algorithm metadata
  • Set up alerts for any JWT verification attempts using symmetric algorithms when asymmetric algorithms are expected
  • Monitor JWKS endpoint access patterns for reconnaissance activity that may precede exploitation

How to Mitigate CVE-2024-54150

Immediate Actions Required

  • Upgrade cjwt to version 2.3.0 or later immediately
  • Audit all applications using cjwt to identify exposure to this vulnerability
  • Review authentication logs for signs of exploitation attempts
  • Implement additional validation layers to verify expected algorithm types before token processing

Patch Information

The vulnerability has been addressed in cjwt version 2.3.0. The fix introduces the OPT_ALLOW_ONLY_HS_ALG option flag that explicitly controls which algorithm families are permitted during JWT verification. When this flag is not set, only public key algorithms are allowed, preventing the algorithm confusion attack. The security patch is available via the GitHub commit. Additional details are available in the GitHub Security Advisory.

Workarounds

  • There are no known workarounds for this vulnerability; upgrading to version 2.3.0 is the only remediation
  • As a defense-in-depth measure, implement application-level algorithm validation before passing tokens to cjwt
  • Consider implementing additional authentication factors while upgrade is pending
  • Restrict network access to affected services until patching is complete
bash
# Update cjwt to the patched version
# Using package manager or building from source
git clone https://github.com/xmidt-org/cjwt.git
cd cjwt
git checkout v2.3.0
mkdir build && cd build
cmake ..
make && sudo make install

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.