CVE-2026-55165: Lemur Auth Bypass Vulnerability

CVE-2026-55165 Overview

CVE-2026-55165 is a JWT algorithm confusion vulnerability in Netflix Lemur, an open-source tool that manages TLS certificate creation. Versions prior to 1.9.2 allow the JWT verifier in lemur/auth/service.py to read the alg header from an unverified token and pass that attacker-controlled value to the token decoder. The flaw represents a defense-in-depth gap rather than a direct authentication bypass in the shipped configuration, because PyJWT 2.x rejects alg=none with the configured symmetric key. The issue is fixed in Lemur 1.9.2, which introduces a server-controlled LEMUR_TOKEN_ALGORITHMS allowlist defaulting to HS256. This weakness is classified under [CWE-347] Improper Verification of Cryptographic Signature.

Critical Impact
The unpinned JWT algorithm could become exploitable after an asymmetric-signing migration through algorithm confusion, and it weakens algorithm-based anomaly detection because the token itself chooses the recorded algorithm value.

Affected Products

Netflix Lemur versions prior to 1.9.2
Deployments using the vulnerable fetch_token_header code path in lemur/auth/service.py:130-137
Environments planning migration from HS256 to asymmetric signing algorithms

Discovery Timeline

2026-08-18 - CVE-2026-55165 published to NVD
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-55165

Vulnerability Analysis

The vulnerability resides in Lemur's JWT verification logic. The verifier called fetch_token_header on an unverified token to extract header_data["alg"], then passed that attacker-controlled algorithm identifier directly into decode_with_multiple_secrets. This pattern violates the principle that JWT signing algorithms must be pinned server-side rather than trusted from the untrusted token header.

In the shipped configuration, PyJWT 2.x prevents the most direct exploitation path. The library rejects alg=none when a signing key is configured, blocking trivial token forgery. However, the design remains fragile. An operator migrating Lemur to an asymmetric signing algorithm such as RS256 would expose the deployment to classic HS256/RS256 confusion attacks, where an attacker signs a forged HS256 token using the public key material.

A secondary risk exists if LEMUR_TOKEN_SECRET is disclosed independently. An attacker holding that secret could forge HS256 tokens, though secret disclosure is a separate prerequisite outside the scope of this specific flaw.

Root Cause

The root cause is trust in attacker-controlled input for a security-critical decision. The verifier used the algorithm name embedded in the token to select the verification algorithm, allowing the token itself to dictate how it is validated. Correct JWT verification requires the server to maintain an allowlist of accepted algorithms and reject any token whose header specifies something outside that list.

Attack Vector

Exploitation requires network access to the Lemur authentication endpoint. In the default HS256-only configuration, direct exploitation is blocked by PyJWT. Exploitation becomes practical when the deployment adds asymmetric algorithms or when the token secret is otherwise compromised, enabling algorithm confusion or forged token acceptance.

text

// Patch excerpt from CHANGELOG.rst — Lemur 1.9.2
1.9.2 - `2026-06-02`
~~~~~~~~~~~~~~~~~~~~
- Fixed JWT algorithm confusion vulnerability (GHSA-r9gp-7f88-9r54) where the JWT verifier accepted the
  algorithm name from the unverified token header instead of pinning it server-side. The server now reads
  the accepted algorithm list from ``LEMUR_TOKEN_ALGORITHMS`` (defaults to ``["HS256"]``, which is the only
  algorithm Lemur has ever used to issue tokens). Deployments that have not changed the default are fully
  backward-compatible with no config change required.

Source: Netflix Lemur commit 89898e6

Detection Methods for CVE-2026-55165

Indicators of Compromise

JWT tokens presented to Lemur with alg header values other than HS256 in default deployments
Authentication log entries showing successful token validation using unexpected algorithms such as RS256, ES256, or none
Anomalous algorithm distributions in authentication telemetry that no longer match issued tokens

Detection Strategies

Inspect Lemur authentication logs for JWT header values and compare against the algorithms Lemur is configured to issue
Alert on any token verification event where the recorded algorithm differs from the server's issuing algorithm
Correlate authentication events with user session origin to identify token replay from unusual network locations

Monitoring Recommendations

Ingest Lemur application logs into a central analytics platform and parse the JWT algorithm field
Monitor for repeated authentication failures followed by successes that could indicate algorithm probing
Track Lemur version inventory across environments to ensure no instance remains below 1.9.2

How to Mitigate CVE-2026-55165

Immediate Actions Required

Upgrade all Lemur deployments to version 1.9.2 or later
Verify that LEMUR_TOKEN_ALGORITHMS is unset or set to ["HS256"] in production configuration
Rotate LEMUR_TOKEN_SECRET if there is any suspicion of prior disclosure
Review authentication logs for anomalous JWT algorithm values prior to patching

Patch Information

The fix is available in Lemur release v1.9.2. The patch introduces the server-controlled LEMUR_TOKEN_ALGORITHMS allowlist, defaulting to ["HS256"], so existing deployments require no configuration change. Full technical details are published in GitHub Security Advisory GHSA-r9gp-7f88-9r54.

Workarounds

No official workaround exists short of upgrading; apply version 1.9.2 as the primary remediation
If upgrading is delayed, restrict network access to the Lemur API to trusted administrative networks
Ensure LEMUR_TOKEN_SECRET has high entropy and is stored in a secrets manager to reduce forgery risk

bash

# Post-upgrade configuration example for Lemur 1.9.2
LEMUR_TOKEN_ALGORITHMS = ["HS256"]         # default, no change needed

# During migration to a new signing algorithm only:
LEMUR_TOKEN_ALGORITHMS = ["HS256", "RS256"] # transition window

# After all HS256 tokens have expired, remove the old value:
LEMUR_TOKEN_ALGORITHMS = ["RS256"]