CVE-2026-55165 in Lemur
Summary
by MITRE • 08/18/2026
Lemur manages TLS certificate creation. Prior to 1.9.2, the JWT verifier in lemur/auth/service.py:130-137 used fetch_token_header to read header_data["alg"] from an unverified token and passed that attacker-controlled value to decode_with_multiple_secrets. PyJWT 2.x rejects alg=none with the configured key, so the flaw is a defense-in-depth gap rather than a direct authentication bypass in the shipped configuration. The unpinned algorithm can become exploitable after an asymmetric-signing migration through algorithm confusion, and it weakens algorithm-based anomaly detection because the token chooses the recorded value. A separate disclosure of LEMUR_TOKEN_SECRET would also permit forged HS256 tokens, although that disclosure is an independent prerequisite. The fix introduces the server-controlled LEMUR_TOKEN_ALGORITHMS allowlist and defaults it to HS256. This issue is fixed in version 1.9.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Lemur prior to version 1.9.2 centers on a critical flaw within its JSON Web Token verification logic, specifically located in the authentication service module at lemur/auth/service.py lines 130 through 137. The core technical deficiency lies in how the system handles the algorithm parameter embedded within JWT headers during token validation. Specifically, the function fetch_token_header extracts the alg value from an unverified token header and passes this attacker-controlled input directly to the decode_with_multiple_secrets method without prior verification or restriction. This behavior creates a classic defense-in-depth gap where the application relies on external library constraints rather than enforcing its own security policies at the point of ingestion. By trusting the algorithm specified by the client, Lemur fails to validate that the requested signing mechanism is appropriate for the keys currently configured in the environment, thereby exposing the system to potential cryptographic confusion attacks if the underlying configuration changes or if specific key types are introduced later.
In its default shipped configuration utilizing PyJWT version 2.x and standard symmetric secret configurations, this flaw does not result in a direct authentication bypass because the library explicitly rejects tokens requesting alg=none when a signing key is present. However, the absence of an explicit allowlist for acceptable algorithms represents a significant architectural weakness that weakens algorithm-based anomaly detection mechanisms. The token itself dictates which cryptographic operation should be performed, allowing an attacker to influence the verification process by manipulating header fields. This lack of server-side control over the algorithm selection means that if the deployment environment undergoes an asymmetric-signing migration or introduces public key infrastructure changes, the vulnerability could become immediately exploitable through algorithm confusion attacks. In such scenarios, an attacker might craft a token using a different algorithm and signature scheme to bypass verification checks intended for symmetric keys, effectively undermining the integrity of the authentication flow even if the secret remains secure in its current state.
The operational impact of this vulnerability extends beyond immediate access control failures to include long-term security posture degradation. By allowing the client to determine the signing algorithm, Lemur inadvertently facilitates potential side-channel attacks or misconfiguration exploits that could compromise token integrity over time. Furthermore, while a separate disclosure of the LEMUR_TOKEN_SECRET would independently permit an attacker to forge valid HS256 tokens regardless of this flaw, the presence of this vulnerability compounds the risk profile by removing a layer of defense against algorithm manipulation. This dual-layer weakness means that even if secret keys are rotated or managed securely, the application remains susceptible to attacks targeting the logic flow and cryptographic assumptions rather than just key secrecy. The reliance on implicit library behavior rather than explicit configuration enforcement creates a fragile security boundary that is prone to failure under evolving threat models or infrastructure changes.
To mitigate this vulnerability, it is imperative to upgrade Lemur to version 1.9.2 or later, where the developers have implemented a server-controlled LEMUR_TOKEN_ALGORITHMS allowlist. This fix enforces strict validation by defaulting to HS256 and restricting token verification to only explicitly permitted algorithms, thereby eliminating the possibility of algorithm confusion attacks. Administrators should ensure that this configuration variable is properly set in their deployment environments to maintain consistent security policies across all authentication requests. Additionally, organizations should review their JWT handling practices against industry standards such as CWE-347 which addresses Improper Verification of Cryptographic Signature, and align with MITRE ATT&CK techniques related to Token Manipulation or Defense Evasion via algorithm confusion. Regular audits of cryptographic configurations and adherence to the principle of least privilege in token validation logic are essential for maintaining robust authentication security in modern web applications.