CVE-2024-37568

Root

Cause

The vulnerability in lepture Authlib versions prior to 1.3.1 lies in the jwt.decode method. When the algorithm parameter is not explicitly specified, the library permits HMAC-based signature verification (HS256, HS384, HS512) using any asymmetric public key provided by the caller [2]. This is a classic algorithm confusion flaw, similar to CVE-2022-29217 and CVE-2024-33663, but with broader applicability as it affects all verification with asymmetric keys regardless of format [2].

Exploitation

An attacker can exploit this by presenting a valid-looking JWT signed with a symmetric HMAC key, then using any asymmetric public key (e.g., from the legitimate service) to fool the library into accepting the token as valid [2]. No authentication is required; the attacker only needs to provide a public key that the application trusts for asymmetric verification. The library fails to check whether the supplied key is actually asymmetric (e.g., PEM or SSH-encoded) before proceeding with HMAC verification [2].

Impact

Successful exploitation allows an attacker to forge arbitrary JWTs that pass signature validation, leading to unauthorized access, privilege escalation, or impersonation of legitimate users. The impact is heightened because the default code example in Authlib documentation is itself vulnerable, potentially leading developers to unknowingly deploy insecure authentication [2].

Mitigation

The vulnerability is fixed in Authlib version 1.3.1 [1][4]. Users should upgrade immediately. As a workaround, always explicitly specify the algorithm parameter in jwt.decode calls, ensuring only expected asymmetric algorithms are accepted. The fix mirrors the solution for previous CVEs: before using HMAC verification, the library must verify that the provided key is not an asymmetric public key [2].