Summary

Lemur: JWT verifier honors attacker-supplied alg, enabling ATO

Severity

medium

CVSS

4.8

EPSS

0.2% (p5)

CWE

CWE-347

Also known as

GHSA-r9gp-7f88-9r54

Published

2026-06-25

Updated

2026-06-25

Advisory details

Lemur 1.9.0: JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure

Vulnerability Summary

Executive Summary

The Lemur JWT verifier reads the alg header field from the unverified token and passes it straight into pyjwt.decode(..., algorithms=[header['alg']]). This is a classic JWT antipattern: the server is supposed to pin the algorithm, not the attacker. PyJWT 2.x's default config rejects alg=none, 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 alg=HS256 and forge tokens using the public key as the HMAC secret — the legacy "RS256→HS256 confusion" trick. Second, the audit-log surface that records alg 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.

Walkthrough: https://asciinema.org/a/2Blv9r4DoOleUk7a

Description

lemur/lemur/auth/service.py:130-137:

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

fetch_token_header decodes the JWT's first segment (base64-decoded JSON, no signature check) and returns the header object. header_data["alg"] is whatever the bearer of the token put there. That value is then handed to decode_with_multiple_secrets, which calls pyjwt.decode(..., algorithms=[<attacker_value>]). The algorithms 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.

Why this is MEDIUM and not CRITICAL today: PyJWT 2.x's decode() rejects alg=none regardless of the algorithms parameter (PyJWT enforces this in jwt.algorithms.NoneAlgorithm.verify). I confirmed this in the lab — a forged alg=none token comes back as HTTP 403 {"error":"When alg = \"none\", key value must be None.","message":"Failed to decode token"}. The classic single-request alg=none ATO is closed by the library, not by Lemur.

Why this still matters:

1. Algorithm confusion is exactly what algorithms= is supposed to prevent. The widely-cited "RS256→HS256 confusion" attack works by pinning alg=HS256 and using the RS256 public key as the HMAC secret. The fix everyone teaches for that attack is "server pins the algorithm". Lemur doesn't, so the protection has a hole the moment the deployment moves to asymmetric signing.
2. The PyJWT 2.x mitigation is a library default, not a Lemur design choice. A future PyJWT major that loosens the none check, or a downgrade to a vulnerable PyJWT for any reason, re-opens single-request ATO. Defense-in-depth means not relying on library defaults to backstop the framework's own validation.
3. Audit blindness. Logging tooling that consumes alg to detect "this token claims an algorithm we don't issue" sees only what the attacker put in the header. A real HS256 token forged by an attacker who pins alg=ES256 (or any garbage that survives decode) bypasses naive alg-based anomaly heuristics.
4. The chain to single-request ATO is short. Any separate disclosure issue that leaks LEMUR_TOKEN_SECRET (a debug page, an unguarded /metrics, an SSRF-to-config, an S3 backup leak, a git history accident) immediately turns into HS256 forgery — and the alg-from-header sink leaves the verifier downgradeable even after an operator migrates to RS256 later.

I'm framing this as a hardening defect at MEDIUM 4.8 because that's what the evidence supports. The chain step (config disclosure → forge admin) is demonstrated in the lab as a clear "what happens if this chain links" walk-through, not as a primary claim.

Proof of Concept & Steps to Reproduce

Walkthrough: https://asciinema.org/a/2Blv9r4DoOleUk7a. Offline cast: lemur_jwt_alg_hardening.cast. Harness: lemur_jwt_alg_hardening/support/ (lemur_jwt_mock.py mirrors lemur/auth/service.py:130-137 line-for-line).

Prerequisites: Docker, curl, jq, python3 with PyJWT.

Run

cd lemur_jwt_alg_hardening/
EXPLOIT_FAST=1 ./exploit_code.sh

Step 1 — Baseline legitimate login

curl -sS -X POST http://127.0.0.1:18001/api/1/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"operator@netflix.example"}'

Response (evidence/03_login_response.json):

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....",
 "user":{"active":true,"email":"operator@netflix.example","id":1,"role":"operator"}}

/api/1/users/me with that token returns 200 — baseline auth path works.

Step 2 — Confirm the antipattern in source

docker exec lemur-jwt-alg-hardening-harness cat /app/evidence-src/jwt_sink.txt

Output is the verbatim Lemur block:

# lemur/lemur/auth/service.py:130-137
try:
    header_data = fetch_token_header(token)
    payload = decode_with_multiple_secrets(
        token, token_secrets, algorithms=[header_data["alg"]]   # <-- antipattern
    )
except jwt.DecodeError:
    return dict(message="Token is invalid"), 403

The mock applies the same code path. No transformation, no allowlist, no server pin.

Step 3 — Forge alg=none (PyJWT 2.x rejects)