CVE-2024-37568: Authlib Auth Bypass Vulnerability

CVE-2024-37568 Overview

CVE-2024-37568 is a cryptographic vulnerability affecting lepture Authlib before version 1.3.1. The vulnerability involves algorithm confusion with asymmetric public keys, where HMAC verification is incorrectly allowed with any asymmetric public key when an algorithm is not explicitly specified in a jwt.decode call. This flaw enables attackers to bypass JWT signature verification by exploiting the library's failure to properly validate the signing algorithm.

Critical Impact

Attackers can forge valid JWT tokens by exploiting algorithm confusion, potentially bypassing authentication and authorization mechanisms in applications using vulnerable Authlib versions.

Affected Products

• Authlib versions prior to 1.3.1
• Applications using jwt.decode without explicit algorithm specification
• Python applications relying on Authlib for JWT token validation

Discovery Timeline

• 2024-06-09 - CVE-2024-37568 published to NVD
• 2025-11-03 - Last updated in NVD database

Technical Details for CVE-2024-37568

Vulnerability Analysis

This vulnerability falls under the category of algorithm confusion attacks (CWE-347: Improper Verification of Cryptographic Signature, CWE-284: Improper Access Control). The issue is similar to previously identified vulnerabilities CVE-2022-29217 and CVE-2024-33663, indicating a recurring pattern in JWT library implementations.

The core problem lies in how Authlib handles JWT signature verification when the calling application does not explicitly specify which algorithm should be used for verification. In properly configured systems, JWT tokens signed with asymmetric algorithms (like RS256) should only be verified using the corresponding public key with that same algorithm. However, the vulnerable versions of Authlib allow HMAC-based verification using asymmetric public keys, creating a dangerous attack surface.

Root Cause

The root cause stems from insufficient algorithm validation during the JWT decode process. When jwt.decode is called without an explicit algorithms parameter, the library fails to enforce that the verification algorithm matches the intended signing mechanism. This allows an attacker who possesses the public key (which is often publicly available) to craft a token signed with HMAC using the public key as the secret, which the library will incorrectly accept as valid.

Attack Vector

The attack is network-based and requires no authentication or user interaction to exploit. An attacker with knowledge of the target application's public key can:

1. Create a malicious JWT payload with arbitrary claims
2. Set the token's alg header to an HMAC algorithm (e.g., HS256)
3. Sign the token using the public key as the HMAC secret
4. Submit the forged token to the vulnerable application
5. The application's jwt.decode call accepts the token as valid

This attack allows complete bypass of JWT-based authentication when the application uses asymmetric key algorithms but does not enforce algorithm restrictions during verification.

Detection Methods for CVE-2024-37568

Indicators of Compromise

• JWT tokens received with unexpected algorithm headers (e.g., HS256 when RS256 is expected)
• Authentication events with tokens containing unusual or elevated privilege claims
• Spike in authentication requests from unknown sources with valid-appearing tokens
• Application logs showing JWT decode operations with mismatched algorithm expectations

Detection Strategies

• Implement logging for JWT verification events, capturing the algorithm used in incoming tokens
• Monitor for tokens where the alg header differs from the expected signing algorithm configured for your application
• Deploy static code analysis tools to identify jwt.decode calls missing explicit algorithm parameters
• Audit authentication systems for unusual successful authentications that bypass normal verification paths

Monitoring Recommendations

• Configure alerting on authentication anomalies where JWT algorithm headers contain HMAC variants when asymmetric signing is expected
• Implement centralized logging for all JWT-related security events across affected applications
• Establish baseline metrics for normal authentication patterns to detect deviations indicative of token forgery

How to Mitigate CVE-2024-37568

Immediate Actions Required

• Upgrade Authlib to version 1.3.1 or later immediately
• Audit all jwt.decode calls in your codebase to ensure explicit algorithm specification
• Review authentication logs for signs of exploitation prior to patching
• Rotate asymmetric key pairs if there is suspicion of prior exploitation

Patch Information

The vulnerability is addressed in Authlib version 1.3.1. Security advisories have been issued by Fedora and Debian LTS. Additional technical details can be found in the GitHub Issue Discussion and the Vicarius Analysis.

Workarounds

• Always specify the expected algorithm explicitly when calling jwt.decode to prevent algorithm confusion
• Implement application-level validation to reject tokens with unexpected algorithm headers before passing to the library
• Use allowlisting for acceptable JWT algorithms and reject any tokens not matching the expected algorithm type

# Secure JWT decode configuration example
from authlib.jose import jwt

# Always explicitly specify the allowed algorithms
# Do NOT allow the token to dictate which algorithm to use
claims = jwt.decode(
    token,
    public_key,
    claims_options={
        "iss": {"essential": True, "value": "expected_issuer"}
    },
    # CRITICAL: Always specify algorithms explicitly
    algorithms=["RS256"]  # Only allow your expected asymmetric algorithm
)