CVE-2026-55165

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.

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.

<!-- obsidian --><h1 data-heading="Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure">Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure</h1>

<h2 data-heading="Vulnerability Summary">Vulnerability Summary</h2>

Field | Value -- | -- Title | Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure Component | lemur/lemur/auth/service.py:130-137 CWE | CWE-347 (Improper Verification of Cryptographic Signature) Attack Prerequisite | Defense-in-depth gap on its own — no single-request exploit against PyJWT 2.x. Single-request ATO requires a separate disclosure issue that leaks LEMUR_TOKEN_SECRET, or a future migration to asymmetric signing without fixing this sink. Affected Versions | github.com/Netflix/lemur version = "1.9.0". Same code present in every prior release that has the auth/service.py:130 block.

<h2 data-heading="Executive Summary">Executive Summary</h2> <p>The Lemur JWT verifier reads the <code>alg</code> header field from the <em>unverified</em> token and passes it straight into <code>pyjwt.decode(..., algorithms=[header['alg']])</code>. This is a classic JWT antipattern: the server is supposed to pin the algorithm, not the attacker. PyJWT 2.x's default config rejects <code>alg=none</code>, so this is not a single-request ATO today — I want to be precise about that. The bug is a hardening gap with two real consequences. First, if the deployment ever migrates to asymmetric signing (RS256/ES256), an attacker can pin <code>alg=HS256</code> and forge tokens using the public key as the HMAC secret — the legacy "RS256→HS256 confusion" trick. Second, the audit-log surface that records <code>alg</code> to flag anomalous tokens is filled in from the attacker's header, so anomaly detection is blinded. I'm submitting this honestly at MEDIUM 4.8 (defense-in-depth) rather than inflating it; the chain to single-request ATO is documented but it depends on a separate disclosure bug.</p> <p>Walkthrough: <a href="https://asciinema.org/a/2Blv9r4DoOleUk7a" class="external-link" target="_blank" rel="noopener nofollow">https://asciinema.org/a/2Blv9r4DoOleUk7a</a><br> <hr> <h2 data-heading="Description">Description</h2> <p><code>lemur/lemur/auth/service.py:130-137</code>:</p> <pre><code class="language-python">try: header_data = fetch_token_header(token) payload = decode_with_multiple_secrets( token, token_secrets, algorithms=[header_data["alg"]] ) except jwt.DecodeError: return dict(message="Token is invalid"), 403 </code></pre> <p><code>fetch_token_header</code> decodes the JWT's first segment (base64-decoded JSON, no signature check) and returns the header object. <code>header_data["alg"]</code> is whatever the bearer of the token put there. That value is then handed to <code>decode_with_multiple_secrets</code>, which calls <code>pyjwt.decode(..., algorithms=[&#x3C;attacker_value>])</code>. The <code>algorithms</code> parameter is meant to be the server's pinned allowlist of acceptable signing algorithms — the line that says "I will accept HS256 and nothing else". By reading it from the token, Lemur asks the attacker which algorithm to trust.</p> <p>Why this is MEDIUM and not CRITICAL today: PyJWT 2.x's <code>decode()</code> rejects <code>alg=none</code> regardless of the <code>algorithms</code> parameter (PyJWT enforces this in <code>jwt.algorithms.NoneAlgorithm.verify</code>). I confirmed this in the lab — a forged <code>alg=none</code> token comes back as <code>HTTP 403 {"error":"When alg = \"none\", key value must be None.","message":"Failed to decode token"}</code>. The classic single-request <code>alg=none</code> ATO is closed by the library, not by Lemur.</p> <p>Why this still matters:</p> <ol> <li><strong>Algorithm confusion…

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.

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.

<!-- obsidian --><h1 data-heading="Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure">Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure</h1>

<h2 data-heading="Vulnerability Summary">Vulnerability Summary</h2>

Field | Value -- | -- Title | Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure Component | lemur/lemur/auth/service.py:130-137 CWE | CWE-347 (Improper Verification of Cryptographic Signature) Attack Prerequisite | Defense-in-depth gap on its own — no single-request exploit against PyJWT 2.x. Single-request ATO requires a separate disclosure issue that leaks LEMUR_TOKEN_SECRET, or a future migration to asymmetric signing without fixing this sink. Affected Versions | github.com/Netflix/lemur version = "1.9.0". Same code present in every prior release that has the auth/service.py:130 block.

<h2 data-heading="Executive Summary">Executive Summary</h2> <p>The Lemur JWT verifier reads the <code>alg</code> header field from the <em>unverified</em> token and passes it straight into <code>pyjwt.decode(..., algorithms=[header['alg']])</code>. This is a classic JWT antipattern: the server is supposed to pin the algorithm, not the attacker. PyJWT 2.x's default config rejects <code>alg=none</code>, so this is not a single-request ATO today — I want to be precise about that. The bug is a hardening gap with two real consequences. First, if the deployment ever migrates to asymmetric signing (RS256/ES256), an attacker can pin <code>alg=HS256</code> and forge tokens using the public key as the HMAC secret — the legacy "RS256→HS256 confusion" trick. Second, the audit-log surface that records <code>alg</code> to flag anomalous tokens is filled in from the attacker's header, so anomaly detection is blinded. I'm submitting this honestly at MEDIUM 4.8 (defense-in-depth) rather than inflating it; the chain to single-request ATO is documented but it depends on a separate disclosure bug.</p> <p>Walkthrough: <a href="https://asciinema.org/a/2Blv9r4DoOleUk7a" class="external-link" target="_blank" rel="noopener nofollow">https://asciinema.org/a/2Blv9r4DoOleUk7a</a><br> <hr> <h2 data-heading="Description">Description</h2> <p><code>lemur/lemur/auth/service.py:130-137</code>:</p> <pre><code class="language-python">try: header_data = fetch_token_header(token) payload = decode_with_multiple_secrets( token, token_secrets, algorithms=[header_data["alg"]] ) except jwt.DecodeError: return dict(message="Token is invalid"), 403 </code></pre> <p><code>fetch_token_header</code> decodes the JWT's first segment (base64-decoded JSON, no signature check) and returns the header object. <code>header_data["alg"]</code> is whatever the bearer of the token put there. That value is then handed to <code>decode_with_multiple_secrets</code>, which calls <code>pyjwt.decode(..., algorithms=[&#x3C;attacker_value>])</code>. The <code>algorithms</code> parameter is meant to be the server's pinned allowlist of acceptable signing algorithms — the line that says "I will accept HS256 and nothing else". By reading it from the token, Lemur asks the attacker which algorithm to trust.</p> <p>Why this is MEDIUM and not CRITICAL today: PyJWT 2.x's <code>decode()</code> rejects <code>alg=none</code> regardless of the <code>algorithms</code> parameter (PyJWT enforces this in <code>jwt.algorithms.NoneAlgorithm.verify</code>). I confirmed this in the lab — a forged <code>alg=none</code> token comes back as <code>HTTP 403 {"error":"When alg = \"none\", key value must be None.","message":"Failed to decode token"}</code>. The classic single-request <code>alg=none</code> ATO is closed by the library, not by Lemur.</p> <p>Why this still matters:</p> <ol> <li><strong>Algorithm confusion…

<!-- obsidian --><h1 data-heading="Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure">Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure</h1>

<h2 data-heading="Vulnerability Summary">Vulnerability Summary</h2>

Field | Value -- | -- Title | Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure Component | lemur/lemur/auth/service.py:130-137 CWE | CWE-347 (Improper Verification of Cryptographic Signature) Attack Prerequisite | Defense-in-depth gap on its own — no single-request exploit against PyJWT 2.x. Single-request ATO requires a separate disclosure issue that leaks LEMUR_TOKEN_SECRET, or a future migration to asymmetric signing without fixing this sink. Affected Versions | github.com/Netflix/lemur version = "1.9.0". Same code present in every prior release that has the auth/service.py:130 block.

<h2 data-heading="Executive Summary">Executive Summary</h2> <p>The Lemur JWT verifier reads the <code>alg</code> header field from the <em>unverified</em> token and passes it straight into <code>pyjwt.decode(..., algorithms=[header['alg']])</code>. This is a classic JWT antipattern: the server is supposed to pin the algorithm, not the attacker. PyJWT 2.x's default config rejects <code>alg=none</code>, so this is not a single-request ATO today — I want to be precise about that. The bug is a hardening gap with two real consequences. First, if the deployment ever migrates to asymmetric signing (RS256/ES256), an attacker can pin <code>alg=HS256</code> and forge tokens using the public key as the HMAC secret — the legacy "RS256→HS256 confusion" trick. Second, the audit-log surface that records <code>alg</code> to flag anomalous tokens is filled in from the attacker's header, so anomaly detection is blinded. I'm submitting this honestly at MEDIUM 4.8 (defense-in-depth) rather than inflating it; the chain to single-request ATO is documented but it depends on a separate disclosure bug.</p> <p>Walkthrough: <a href="https://asciinema.org/a/2Blv9r4DoOleUk7a" class="external-link" target="_blank" rel="noopener nofollow">https://asciinema.org/a/2Blv9r4DoOleUk7a</a><br> <hr> <h2 data-heading="Description">Description</h2> <p><code>lemur/lemur/auth/service.py:130-137</code>:</p> <pre><code class="language-python">try: header_data = fetch_token_header(token) payload = decode_with_multiple_secrets( token, token_secrets, algorithms=[header_data["alg"]] ) except jwt.DecodeError: return dict(message="Token is invalid"), 403 </code></pre> <p><code>fetch_token_header</code> decodes the JWT's first segment (base64-decoded JSON, no signature check) and returns the header object. <code>header_data["alg"]</code> is whatever the bearer of the token put there. That value is then handed to <code>decode_with_multiple_secrets</code>, which calls <code>pyjwt.decode(..., algorithms=[&#x3C;attacker_value>])</code>. The <code>algorithms</code> parameter is meant to be the server's pinned allowlist of acceptable signing algorithms — the line that says "I will accept HS256 and nothing else". By reading it from the token, Lemur asks the attacker which algorithm to trust.</p> <p>Why this is MEDIUM and not CRITICAL today: PyJWT 2.x's <code>decode()</code> rejects <code>alg=none</code> regardless of the <code>algorithms</code> parameter (PyJWT enforces this in <code>jwt.algorithms.NoneAlgorithm.verify</code>). I confirmed this in the lab — a forged <code>alg=none</code> token comes back as <code>HTTP 403 {"error":"When alg = \"none\", key value must be None.","message":"Failed to decode token"}</code>. The classic single-request <code>alg=none</code> ATO is closed by the library, not by Lemur.</p> <p>Why this still matters:</p> <ol> <li><strong>Algorithm confusion…