Klienci Ethereum Teku i Besu wydają pilne poprawki po błędzie certyfikatu eMudhra
Najważniejsze informacje
- •Błąd kryptograficzny w kwietniu 2025 roku doprowadził eMudhra do wygenerowania ośmiu kluczy pośredniego urzędu certyfikacji z odzyskiwalnymi kluczami prywatnymi — słabość pozostawała niewykryta przez około 18 miesięcy, aż niezależny badacz odkrył ją 17 października 2026 roku.
- •Teku wydał wersję 26.10.3 27 października, a Besu wydał wersję 26.10.2 26 października, usuwając zaufanie do dotkniętych urzędów certyfikacji ze swoich dystrybucji Docker.
- •W pewnych konfiguracjach atakujący typu man-in-the-middle mogliby teoretycznie manipulować komunikacją między walidatorami a zewnętrznymi usługami podpisującymi, potencjalnie przekierowując nagrody z opłat za bloki na adresy kontrolowane przez atakujących.
- •Domyślne konfiguracje głównej sieci Ethereum nie zostały dotknięte, a deweloperzy nie odnotowali potwierdzonego wykorzystania luki w narażonych instalacjach Teku.
- •Administratorzy uruchamiający Teku lub Besu bezpośrednio na serwerach muszą osobno sprawdzić swoje instalacje Java oraz magazyny zaufania certyfikatów, ponieważ sama aktualizacja klienta Ethereum może nie wyeliminować podatności.

Deweloperzy klientów Ethereum wydali awaryjne aktualizacje zabezpieczeń dla Teku i Besu po błędzie kryptograficznym w indyjskim urzędzie certyfikacji eMudhra, który naraził pewne konfiguracje węzłów na potencjalne ataki. Wada mogła pozwolić atakującym na sfałszowanie zaufanych certyfikatów i przechwycenie komunikacji między komponentami infrastruktury Ethereum, choć deweloperzy potwierdzili, że domyślne konfiguracje głównej sieci Ethereum nie zostały dotknięte.
Oba klienty, na których opierają się operacje blockchainu i infrastruktura walidatorów, otrzymały pilne poprawki. Teku pełni rolę klienta warstwy konsensusu, a Besu klienta warstwy wykonania, oba są napisane w Javie — szczegół, który wpływa na sposób dotarcia poprawki do różnych konfiguracji operatorów. Badacze zidentyfikowali potencjalnie poważne scenariusze ataków, ale deweloperzy nie odnotowali potwierdzonego wykorzystania luki w dotkniętych instalacjach Teku.
Jak błąd certyfikatu eMudhra stworzył zagrożenia bezpieczeństwa
Incydent sięga błędu kryptograficznego w procesie generowania certyfikatów eMudhra w kwietniu 2025 roku. Firma wygenerowała osiem kluczy pośredniego urzędu certyfikacji o niewystarczającej sile kryptograficznej, przez co ich klucze prywatne były możliwe do odzyskania.
Urzędy certyfikacji stanowią fundament modelu zaufania HTTPS: aplikacje opierają się na ich podpisach, aby potwierdzić, że serwery, z którymi się łączą, są autentyczne. Niezależny badacz odkrył słabość 17 października 2026 roku. Umożliwiała ona atakującym tworzenie fałszywych certyfikatów, które podatne aplikacje mogły uznać za legalne. Problem pozostawał niewykryty przez około 18 miesięcy mimo niezależnych audytów bezpieczeństwa.
eMudhra następnie odwołała dotknięte certyfikaty i przyznała, że błąd skryptu doprowadził do wygenerowania słabych kluczy kryptograficznych. Reuters poinformował, że incydent skłonił również firmę do wycofania się z globalnego biznesu certyfikatów zabezpieczeń stron internetowych, choć eMudhra utrzymywała, że jej infrastruktura i dane klientów nie zostały naruszone.
Teku i Besu wydają awaryjne aktualizacje zabezpieczeń
W odpowiedzi deweloperzy klientów Ethereum usunęli zaufanie do dotkniętych urzędów certyfikacji ze swoich dystrybucji Docker. Teku wydał wersję 26.10.3 27 października, a Besu wydał wersję 26.10.2 26 października.
Poprawki dotyczą ryzyka związanego z połączeniami HTTPS opartymi na naruszonych łańcuchach certyfikatów. W pewnych konfiguracjach atakujący przeprowadzający ataki typu man-in-the-middle — po cichu przekazujący i modyfikujący ruch między dwiema stronami — mogliby potencjalnie manipulować komunikacją między walidatorami a zewnętrznymi usługami podpisującymi. Takie ataki mogłyby teoretycznie przekierować nagrody z opłat za bloki na adresy kontrolowane przez atakujących.
Wykorzystanie tego scenariusza wymagałoby jednak określonych warunków, w tym podatnych konfiguracji oraz możliwości przechwycenia odpowiedniego ruchu sieciowego. Domyślne węzły głównej sieci Ethereum bez dotkniętych połączeń HTTPS nie znalazły się w zidentyfikowanym zakresie zagrożenia.
Dodatkowe kontrole Java dla operatorów Ethereum
Operatorzy korzystający ze zaktualizowanych obrazów Docker otrzymują odpowiednie zmiany zaufania certyfikatów poprzez swoje kontenery, ponieważ obrazy są dostarczane z własnym środowiskiem uruchomieniowym. Administratorzy uruchamiający Teku lub Besu bezpośrednio na serwerach muszą jednak osobno sprawdzić swoje instalacje Java oraz magazyny zaufania certyfikatów. Sama aktualizacja klienta Ethereum może nie wyeliminować podatności, jeśli bazowe środowisko Java nadal ufa dotkniętym certyfikatom.
Incydent pokazuje, jak słabości w zewnętrznej infrastrukturze bezpieczeństwa mogą stwarzać ryzyko dla aplikacji blockchainowych bez naruszania samego protokołu blockchain. Dla walidatorów Ethereum utrzymanie bezpiecznego oprogramowania klienta i konfiguracji certyfikatów pozostaje kluczowe dla ochrony infrastruktury operacyjnej i potencjalnych nagród.