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:
- Obtaining the target application's public key (often publicly available via JWKS endpoints)
- Crafting a JWT with the alg header set to HS256 instead of the expected asymmetric algorithm
- Signing the forged JWT using the public key as the HMAC secret
- 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:
*/
#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
# 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.


