Certyfikaty eMudhra skompromitowane: co zrobić z serwerami i obrazami

Klucze prywatne 8 certyfikatów pośrednich urzędu certyfikacji eMudhra zostały skompromitowane. Według Mozilli (2026) 6 z nich służy do TLS, a 2 do podpisywania kodu. Kto ma taki klucz, może wystawić ważny certyfikat dla dowolnej domeny, podszyć się pod dowolną stronę i podsłuchać albo zmienić ruch. Według analizy Aikido (2026) każdy z tych kluczy jest mniejszy niż 256, a jeden z nich to liczba 4.

Przeglądarki zablokowały te certyfikaty same. Serwery, kontenery, narzędzia z wiersza poleceń i środowiska takie jak Go, Node.js, Java czy Python nadal im ufają, dopóki ktoś ich nie zaktualizuje.

Krótka odpowiedź: co zrobić po wycieku kluczy eMudhra

1. Zaktualizuj system operacyjny i przeglądarki. To chroni większość użytkowników.
2. Zaktualizuj paczkę ca-certificates na serwerach i maszynach wirtualnych.
3. Przebuduj obrazy kontenerów na świeżym obrazie bazowym i wdroż je ponownie.
4. Zaktualizuj środowiska z własną listą certyfikatów: Go, Node.js, Java, Python certifi, Rust webpki-roots.
5. Zrestartuj usługi, które działają długo, żeby wczytały nową listę.
6. Sprawdź każdą usługę testem z jej własnej ścieżki TLS.

eMudhra w liczbach: statystyki 2026

Dane sprawdziliśmy 23 października 2026 r.

• Według Mozilli (2026) skompromitowanych jest 8 certyfikatów pośrednich eMudhra, w tym 6 do TLS i 2 do podpisywania kodu.
• Według analizy Aikido (2026) atakujący potrzebował najwyżej 256 prób, żeby odgadnąć każdy z kluczy, a poprawnie wygenerowany klucz tego typu wymaga około 10^115 prób.
• Według strony incydentu (2026) Firefox i Chrome blokują te certyfikaty od 17 października 2026 r., a urządzenia Apple od 22 października.
• Według Mozilli (2026) eMudhra unieważniła certyfikaty 18 października, a Sectigo 19 października 2026 r.
• Według Cloudflare (2026) firma wdrożyła poprawki w CDN i Zero Trust w niecałe 27 godzin od zgłoszenia, które dostała 19 października o 17:00 UTC.

Źródła: strona incydentu eMudhra, komunikat Mozilli na oss-security, Aikido, Cloudflare.

Kogo dotyczy wyciek kluczy eMudhra

Przeglądarki mają własne mechanizmy, którymi szybko wyłączają zaufanie do złego certyfikatu. Większość innych programów ich nie ma. Mają listę zaufanych certyfikatów głównych i akceptują wszystko, co do nich prowadzi. Jedyny sposób to wgrać nową listę.

Zagrożone są:

• narzędzia z wiersza poleceń: curl, git, python3, openssl, także wbudowane w macOS, które czytają plik /etc/ssl/cert.pem;
• kontenery i CI: obraz ma listę certyfikatów z dnia, w którym go zbudowano;
• środowiska uruchomieniowe z własną listą: Go, Java, Node.js, Python certifi, Rust webpki-roots;
• urządzenia IoT, które mają certyfikaty w oprogramowaniu i rzadko dostają aktualizacje;
• podpisywanie kodu: 2 z 8 certyfikatów pozwalały podpisać program dowolną nazwą wydawcy. Microsoft blokuje je od 20 października.

Do użycia podrobionego certyfikatu atakujący musi być na drodze ruchu, na przykład w obcej sieci Wi-Fi albo na przejętym routerze. Według strony incydentu certyfikaty nie trafiły do publicznych rejestrów Certificate Transparency, więc przeglądarki, które tego wymagają, nie mogły zostać zaatakowane. Programy, które tych rejestrów nie sprawdzają, mogły, a strona incydentu nie wie, czy ktoś to wykorzystał.

Jak groźny jest wyciek kluczy eMudhra: przykłady

Certyfikat to dowód tożsamości serwera. Gdy program ufa podrobionemu certyfikatowi, rozmawia z przestępcą, przekonany, że rozmawia z bankiem, dostawcą płatności czy własnym API. Szyfrowanie nadal działa, tyle że z niewłaściwą osobą. Mozilla napisała do opiekunów list certyfikatów, że nadużycie tych kluczy jest prawdopodobne w najbliższym czasie.

Wyciek danych osobowych ma skutki prawne. Według RODO (2016) firma ma 72 godziny od wykrycia naruszenia na zgłoszenie go organowi nadzorczemu, w Polsce UODO. Według RODO (2016) za naruszenie obowiązków bezpieczeństwa i zgłaszania grozi kara do 10 mln euro albo do 2% całkowitego rocznego obrotu, zależnie od tego, która kwota jest wyższa. Źródło: RODO, rozporządzenie 2016/679, art. 33 i art. 83 ust. 4.

Wersje z poprawką: systemy i środowiska

Pełną listę, z wersjami, które jeszcze czekają, prowadzi strona incydentu. Status zmienia się codziennie. Dla Go piszemy osobno o poprawce GO-2026-6809 w crypto/x509.

Wersję ca-certificates sprawdzisz tak:

dpkg -s ca-certificates | grep Version   # Debian, Ubuntu
apk info ca-certificates                 # Alpine
rpm -q ca-certificates                   # Fedora, RHEL

Jak sprawdzić, czy serwer nadal ufa certyfikatom eMudhra

Strona incydentu udostępnia dwa adresy testowe. Uruchom polecenia z serwera albo z wnętrza kontenera:

curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-emudhra.we-have-a-problem.com/
curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Błąd SSL i wynik HTTP 000 to wynik, którego chcesz. Wynik 200 oznacza, że ten klient nadal ufa skompromitowanym certyfikatom.

Cloudflare przypomina o ważnej granicy tego testu. Udany test w przeglądarce nie dowodzi, że usługa w tle jest chroniona. Test curl też nie, jeśli aplikacja sprawdza certyfikaty innym mechanizmem, na przykład biblioteką HTTP albo środowiskiem Go czy Javy. Każdą usługę trzeba sprawdzić jej własną drogą.

Czego nie robić po aktualizacji

Po aktualizacji mogą pojawić się błędy certyfikatów w logach i panelach. Cloudflare ostrzega, żeby nie usuwać ich przez wyłączenie weryfikacji certyfikatów. To zdejmuje całą ochronę, którą aktualizacja miała przywrócić. Błąd trzeba wyjaśnić: albo serwer po drugiej stronie używa certyfikatu z zablokowanego łańcucha, albo usługa ma własny, nieaktualny magazyn certyfikatów.

Użytkownicy Cloudflare mają dodatkowe kroki. Cloudflare Tunnel trzeba podnieść do wersji 2026.10.2, klienta Cloudflare One i aplikację 1.1.1.1 do wersji z komunikatu. Trzeba też przejrzeć zaufane urzędy w ustawieniach mutual TLS i certyfikaty serwerów źródłowych.

Jak Syntalith pomaga po wycieku kluczy eMudhra

Ten problem rzadko siedzi w jednym miejscu. Lista certyfikatów jest w systemie, w każdym obrazie, w każdym środowisku Go, Javy czy Pythona i w urządzeniach, o których nikt nie pamięta. Możemy zrobić to za Was, od początku do końca.

Najpierw szukamy wszystkich miejsc, w których Wasze usługi sprawdzają certyfikaty: serwerów, obrazów, CI, środowisk uruchomieniowych, bibliotek HTTP i urządzeń. Potem podnosimy ca-certificates, środowiska i biblioteki z własną listą, przebudowujemy obrazy na świeżych obrazach bazowych, restartujemy usługi, które trzymają starą listę w pamięci, i wdrażamy wszystko ponownie. Każdą usługę testujemy jej własną ścieżką TLS, z włączoną weryfikacją certyfikatów. Dostajecie raport na piśmie: co ufało skompromitowanym certyfikatom, co poprawiliśmy i co wymaga Waszej decyzji, na przykład urządzenia bez aktualizacji. Pracujemy na Waszej infrastrukturze, z dostępami tylko na czas zadania.

Te same kroki zrobiliśmy u siebie. 23 października przenieśliśmy stronę, system rezerwacji i serwer MCP na Node.js 24.22.1, który ma już nową listę certyfikatów.

Zacznij od bezpłatnej, 30-minutowej rozmowy z inżynierem. Powiedz, na czym działają Wasze usługi, a my powiemy, od czego zacząć. Umów rozmowę.

W tym samym tygodniu pojawiły się też luka Node2Shell w Node.js i luki PHP2Shell w PHP.