CVE-2026-55165
ŚrednieCVSS 4.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 3 - wyżej niż 3% wszystkich znanych CVE
Streszczenie
Lemur przed wersją 1.9.2 ma podatność w weryfikatorze JWT, który używa niezweryfikowanego algorytmu z nagłówka tokena. W konfiguracji domyślnej PyJWT odrzuca alg=none, więc nie jest to bezpośrednie obejście uwierzytelniania, ale stanowi lukę w obronie warstwowej. Po migracji na podpisy asymetryczne może dojść do pomylenia algorytmów, a anomalie oparte na algorytmach są osłabione.
Ocena ryzyka
Podatność może zostać wykorzystana po migracji na podpisy asymetryczne do obejścia uwierzytelniania, a także osłabia wykrywanie anomalii, co zwiększa ryzyko nieautoryzowanego dostępu.
Rekomendacja
Zaktualizuj Lemur do wersji 1.9.2 lub nowszej, która wprowadza listę dozwolonych algorytmów LEMUR_TOKEN_ALGORITHMS z domyślnym HS256.
Oryginalny opis (angielski, źródło NVD)
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.