Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.8",
  "pubDate": "2026-08-18T19:16:58.647Z",
  "pubdate": "2026-08-18T19:16:58.647Z",
  "executiveSummary": "An unpinned algorithm vulnerability exists in the JWT verifier of Lemur prior to version 1.9.2, specifically within lemur/auth/service.py:130-137. The vulnerability arises because the application reads the alg parameter directly from an unverified token using fetch_token_header and passes this attacker-controlled value into decode_with_multiple_secrets without enforcing a server-controlled allowlist.\nWhile PyJWT 2.x natively rejects alg=none when evaluated against a configured key, this design introduces a defense-in-depth gap. The lack of algorithm restriction creates significant risk implications, as the unpinned algorithm can become directly exploitable following an asymmetric-signing migration via algorithm confusion attacks. Furthermore, it undermines security auditing and anomaly detection mechanisms by allowing the token itself to dictate the recorded algorithm value. An attacker capable of exploiting this could manipulate token validation if additional prerequisites are met, such as a separate disclosure of LEMUR_TOKEN_SECRET to forge valid HS256 tokens.\nThe affected product is Lemur in versions prior to 1.9.2. Remediation requires updating to version 1.9.2 or later, which introduces a server-controlled LEMUR_TOKEN_ALGORITHMS allowlist defaulting strictly to HS256.",
  "technicalDetails": "The vulnerability is located in the JWT validation logic implemented in lemur/auth/service.py between lines 130 and 137. The root cause of the issue is the dynamic retrieval of the cryptographic algorithm from incoming JSON Web Tokens. Specifically, the function utilizes fetch_token_header to extract the header_data['alg'] value directly from the unverified payload header rather than enforcing a strict, server-side algorithm policy.\nThis attacker-controlled algorithm value is subsequently passed directly into the decode_with_multiple_secrets function. In the context of PyJWT 2.x, explicit requests for the none algorithm are rejected when a secret key is configured, preventing a trivial direct authentication bypass in the default shipping configuration. However, this represents a severe defense-in-depth vulnerability.\nThe step-by-step attack flow and mechanism of exposure involve several critical factors. First, if the application undergoes an asymmetric-signing migration (such as transitioning from HS256 to RS256), an unpinned algorithm implementation can be leveraged by an attacker to execute algorithm confusion attacks. By forcing the verification engine to process an asymmetric public key as a symmetric shared secret, an attacker can bypass signature checks entirely. Second, allowing the token to define its own processing algorithm degrades algorithm-based anomaly detection systems, as the recorded telemetry values can be falsified by malicious inputs. Finally, exploitation relies on independent prerequisites, such as the separate disclosure of the LEMUR_TOKEN_SECRET, which would enable an attacker to forge valid HS256 tokens processed by the vulnerable decoding pipeline.\nThe vulnerable component is the JWT validation service handling authentication tokens within Lemur. The affected versions include all releases prior to 1.9.2. Network exposure encompasses any interface exposed by Lemur that accepts and processes JWT-based authentication headers."
}