CVE-2026-62162
WysokieCVSS 8.2Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 31 - wyżej niż 31% wszystkich znanych CVE
Streszczenie
W Hydra (warstwa skalowalności L2 dla Cardano) przed wersją 2.1.0 gałąź Claim w walidatorze depozytu sprawdza jedynie zgodność datum.head_id z kontrolowanym przez atakującego redeemer.currencySymbol oraz ważność transakcji przed terminem depozytu. Nie wymaga wydania UTxO tokena stanu Head w tej samej transakcji ani nie ogranicza wyjść, więc po potwierdzeniu depozytu przez POST /commit dowolna strona trzecia może przejąć oczekujące UTxO depozytu i przekierować środki na dowolny adres.
Ocena ryzyka
Atakujący może przechwycić oczekujące depozyty i przekierować aktywa na własny adres, co prowadzi do bezpośredniej utraty środków użytkowników. Luka dotyczy depozytów oczekujących przed terminem (domyślnie trzykrotność depositPeriod).
Rekomendacja
Zaktualizuj Hydra do wersji 2.1.0 lub nowszej. Do czasu aktualizacji unikaj przyjmowania depozytów lub ogranicz ich kwoty i monitoruj oczekujące UTxO.
Inne podatności w Hydra
Zobacz wszystkie- CVE-2026-106442Wysokie
Hydra w wersjach od 1.3.4 do 1.3.6 oraz 1.4.0.dev9 ma niekompletną czarną listę celów dla instantiate(), która nie sprawdza w pełni efektywnego wywoływanego obiektu. Obejścia takie jak timeit.timeit, deserializacja pickle.loads, aliasy, pomocnicy zwracający callable, ogólne dispatch i odroczone wywołania mogą ukryć lub opóźnić efektywny cel i obejść autoryzację opartą na nazwie.
- CVE-2026-106441Wysokie
Hydra przed wersjami 1.3.6 i 1.4.0.dev9 przekazuje konfigurację logowania Pythona do logging.config.dictConfig() bez stosowania polityki celów Hydra do wartości klas handlerów oraz fabryk formatterów, filtrów, handlerów, kolejek i listenerów. Atakujący kontrolujący konfigurację logowania Hydra może wybrać importowalną klasę lub fabrykę i wywołać ją z uprawnieniami aplikacji.
- CVE-2026-106440Wysokie
Hydra od wersji 1.2.0 do 1.3.0 i 1.4.0.dev10 w pakiecie hydra-optuna-sweeper akceptuje sterowaną konfiguracją ścieżkę kropkową w hydra.sweeper.custom_search_space, rozwiązuje ją za pomocą hydra.utils.get_method() i później wywołuje zwrócony callable w procesie kontrolera Hydra. Ponieważ get_method() nie stosuje polityki wykonawczej używanej przez instantiate(), atakujący kontrolujący konfigurację Optuna lub nadpisania wiersza poleceń może wybrać importowalny kod Pythona do wykonania z uprawnieniami aplikacji.
- CVE-2026-106439Wysokie
Hydra od wersji 1.3.4 do 1.3.7 i 1.4.0.dev10 przechowuje listy blokowane celów instantiate i powiązane kolekcje polityki wykonawczej w mutowalnym stanie na poziomie modułu. Atakujący kontrolujący wiele wpisów docelowych może rozwiązać hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard przez instantiate(), usunąć zabroniony cel, a następnie wywołać ten cel, ponieważ węzły rodzeństwa są przetwarzane w kolejności wstawiania względem tej samej zmodyfikowanej polityki.
- CVE-2026-68508Wysokie
Hydra przed wersją 1.3.4 ma podatność umożliwiającą wykonanie dowolnego kodu. Funkcja hydra.utils.instantiate() rozwiązuje i wywołuje obiekty Pythona wybrane przez konfigurację, co pozwala atakującemu na wywołanie niebezpiecznych funkcji.
- CVE-2026-56766Wysokie
Podatność w Hydra do wersji 9.7 (załatana w commicie 9cc84c2) powoduje przepełnienie bufora stosu w modułach NTLM dla SMTP, POP3, IMAP, NNTP, HTTP, HTTP-Proxy i HTTP-Proxy-Urlenum podczas przetwarzania złośliwych wyzwań NTLM Type-2. Zdalny serwer może wysłać spreparowane wyzwanie z nadmiernie długim ciągiem domeny, powodując przepełnienie 500-bajtowego bufora stosu o 18 do 330 bajtów, co umożliwia zdalne wykonanie kodu na systemach bez ochrony stosu.
Oryginalny opis (angielski, źródło NVD)
Hydra is a layer-two scalability solution for Cardano. Prior to 2.1.0, the `Claim` branch in `hydra-plutus/validators/deposit.ak` checks only that `datum.head_id` matches the attacker-controlled `redeemer.currencySymbol` and that the transaction is valid before the deposit deadline. It neither requires spending the Head state-token UTxO in the same transaction nor constrains outputs. After a deposit made through `POST /commit` is confirmed, any third party able to build a Cardano transaction can observe and consume the pending deposit UTxO before its deadline and redirect the assets to an arbitrary address. A standalone deposit spend invokes no Head validator, bypassing its safety checks; historical head-ID binding and the Aiken rewrite retained this missing invariant. The default deadline is three times depositPeriod, so the described attack applies to pending deposits before that deadline. This issue is fixed in version 2.1.0.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS