Błąd generowania kluczy w CA eMudhra umożliwił fałszowanie zaufanych certyfikatów TLS i podpisywania kodu
W skrócie: Cisco Talos ujawniło, że osiem certyfikatów pośrednich wydanych przez centrum certyfikacji eMudhra zostało wygenerowanych z krytycznie słabymi kluczami prywatnymi podczas ceremonii generowania kluczy w kwietniu 2025 r. — niektóre miały zaledwie 3-8 bitów entropii zamiast wymaganych 384. Umożliwiło to trywialne odzyskanie kluczy prywatnych, pozwalając atakującemu podszyć się pod dowolną witrynę TLS lub sfałszować certyfikaty podpisywania kodu. Chrome, Mozilla i Apple zablokowały już sześć dotkniętych certyfikatów TLS; Microsoft zablokował dwa certyfikaty podpisywania kodu. eMudhra unieważniła certyfikaty i wstrzymała wydawanie nowych w ramach swojego rootu G3, a zespół Go wydał Go 1.27.3 i 1.26.10 (CVE-2026-111943), ponieważ Go posiada własną logikę walidacji certyfikatów niezależną od systemu.
To podsumowanie zostało automatycznie przygotowane przez sztuczną inteligencję na podstawie publikacji „Cisco Talos”. To nasz tekst, nie kopia oryginału — fakty, liczby i cytaty należą do źródła, do którego link znajduje się powyżej i poniżej.
Co się zmieniło?
- 1Osiem certyfikatów pośrednich CA eMudhra (6 TLS, 2 do podpisywania kodu) miało krytycznie słabe klucze prywatne (3-8 bitów entropii zamiast 384)
- 2Błąd wynikał z ceremonii generowania kluczy z 30 kwietnia 2025 r. dla 24 podrzędnych CA w ramach emSign Root TLS CA - G3
- 3Chrome, Mozilla, Apple zablokowały sześć certyfikatów TLS; Microsoft zablokował dwa certyfikaty podpisywania kodu
- 4eMudhra unieważniła skompromitowane certyfikaty i wstrzymała wydawanie nowych w ramach rootu G3
- 5Go przypisało CVE-2026-111943 i wydało Go 1.27.3 oraz 1.26.10, które filtrują łańcuchy na podstawie skrótów SPKI ośmiu skompromitowanych certyfikatów
- 6Brak potwierdzonych przypadków wykorzystania w praktyce do 21 października 2026, 14:00 UTC
Dlaczego to ważne?
Ponieważ zaufanie do tych certyfikatów rozprzestrzenia się w dół łańcucha, każdy system, który nadal im ufa i nie sprawdza prawidłowo unieważnień — bramy VPN, serwery proxy, load balancery, urządzenia wbudowane/IoT, pipeline'y CI/CD, środowiska kontenerowe — pozostaje narażony na ataki typu MITM nawet po zablokowaniu kluczy przez dostawców przeglądarek. Infrastruktura oparta na Go (Docker, Kubernetes, Terraform, Prometheus) wymagała osobnej poprawki, ponieważ Go implementuje własną walidację certyfikatów niezależnie od magazynów zaufania systemu operacyjnego.
Co to oznacza dla agentów AI i contact center?
Warto sprawdzić wszelkie oprogramowanie po stronie serwera lub obsługujące agentów, które terminuje TLS przez SIP/VoIP, bramy API, VPN, odwrotne proxy lub narzędzia oparte na Go w infrastrukturze, pod kątem dotkniętych certyfikatów pośrednich eMudhra i zaktualizować magazyny zaufania lub środowisko uruchomieniowe Go (1.27.3/1.26.10); szczególną uwagę warto zwrócić na urządzenia z wbudowanymi magazynami CA, które nie otrzymują automatycznych aktualizacji unieważnień.
Źródła
- Cisco TalosOficjalneŹródło pierwotneOryginalny artykuł →„Compromised eMudhra intermediate certificates“21 paź 2026, 23:43
- Data publikacji źródła
- 21 paź 2026, 23:43
- Znalezione przez nasz system
- 21 paź 2026, 23:55
- Podsumowanie wygenerowano
- 21 paź 2026, 23:56
Artykuł napisała AI na podstawie oryginalnego źródła. Fakty, liczby i ceny pochodzą ze źródła; brakujące wartości oznaczono „Brak oficjalnych danych”. Informacje prawne, prawa autorskie i prywatność