CVE-2026-70667

Lemur w wersji 0.1.4 nie wykorzystuje wystarczającej entropii w wektora inicjalizacyjnego (IV) podczas szyfrowania AES w trybie CBC, co może prowadzić do osłabienia bezpieczeństwa danych.

Lemur przed wersją 1.9.2 ma podatność, która pozwala uwierzytelnionym użytkownikom wpływać na adres ACME authority (acme_url) bez skutecznego ograniczenia docelowego po stronie serwera, co umożliwia ataki SSRF na wewnętrzne usługi lub metadane chmury. Dodatkowo istnieje słabość autoryzacji, która może zachować dostęp do kluczy prywatnych po zmianie właściciela.

Lemur przed wersją 1.9.3 zawiera podatność w endpointach API, która pozwala nieuprzywilejowanemu użytkownikowi na utworzenie duplikatu certyfikatu bez wymaganych uprawnień, a następnie na jego unieważnienie, co może prowadzić do odmowy usługi dla wszystkich certyfikatów. Poprawka w wersji 1.9.3 odrzuca duplikaty i wymaga uprawnień do autorytetu.

Lemur przed wersją 1.9.3 ma podatność w funkcji CertificateExport, gdzie sprawdzenie własności CertificatePermission było wykonywane tylko w gałęzi plugin.requires_key. Plugin z requires_key false omijał to sprawdzenie, a handler nadal przekazywał klucz prywatny i rejestrował zdarzenie audytu key_view. Poprawka nie przekazuje klucza prywatnego pluginom, które go nie wymagają.

Lemur przed wersją 1.9.3 nie wymagał AuthorityPermission na nadrzędnym urzędzie certyfikacji przy tworzeniu sub-CA, gdy ADMIN_ONLY_AUTHORITY_CREATION było fałszywe. Uwierzytelniony użytkownik nie tylko do odczytu mógł utworzyć sub-CA i użyć klucza prywatnego nadrzędnego urzędu do podpisania nowego certyfikatu pośredniego, co pozwalało na wydawanie zaufanych certyfikatów poza normalnymi kontrolami.

Lemur do wersji 1.9.3 nie sprawdzał uprawnień CertificatePermission przy przypisywaniu identyfikatorów do pola replaces w żądaniach tworzenia, przesyłania i edycji certyfikatów. Umożliwiało to atakującemu z uprawnieniami nie tylko do odczytu wyłączenie powiadomień o ofierze i oznaczenie jej certyfikatu jako zastąpionego, co mogło prowadzić do wdrożenia atakującego certyfikatu na punktach końcowych ofiary. Problem naprawiono w wersji 1.9.3.

Lemur przed wersją 1.9.3 udostępniał endpointy GET /api/1/destinations i GET /api/1/destinations/ tylko z uwierzytelnieniem, bez wymogu uprawnień administratora, a odpowiedzi zawierały nieprzefiltrowane opcje, w tym hasła i klucze prywatne w postaci jawnego tekstu. Umożliwiało to użytkownikowi z uprawnieniami tylko do odczytu pobranie poświadczeń do zdalnych hostów wdrażania certyfikatów. Problem naprawiono w wersji 1.9.3.

Lemur przed wersją 1.9.3 nie sprawdzał listy dozwolonych hostów ACME przy aktualizacji acme_url przez PUT /api/1/authorities/, co pozwalało użytkownikowi z rolą authority na ustawienie adresu URL wewnętrznej usługi lub metadanych chmury (np. 169.254.169.254). Podczas kolejnej operacji wydawania certyfikatu Lemur wysyłał żądanie do tego adresu, co mogło ujawnić wewnętrzne usługi lub metadane chmury. Problem naprawiono w wersji 1.9.3.

Lemur przed wersją 1.9.3 pozwalał użytkownikowi z rolą authority na aktualizację acme_url bez ponownej walidacji i skierowanie klienta ACME do kontrolowanego przez atakującego serwera. Serwer ten mógł zwracać adresy URL (newNonce, newOrder, authorizations, finalize) wskazujące na wewnętrzne usługi lub metadane chmury, a Lemur podążał za nimi bez sprawdzania zgodności hosta. Problem naprawiono w wersji 1.9.3.

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.