Исследователь Скотт Хелме обнаружил, что у центра сертификации eMudhra восемь закрытых ключей можно восстановить за доли секунды, используя только общедоступные сертификаты. Один из ключей оказался равен числу 4, другой — 56, третий — 115. Для взлома не требовались суперкомпьютеры или сложные криптографические атаки; каждый ключ был подобран на обычном ноутбуке менее чем за секунду. Проблема затронула шесть промежуточных центров выдачи TLS-сертификатов и два центра подписи программного кода. Промежуточный центр получает полномочия от корневого удостоверяющего центра и может самостоятельно подписывать сертификаты сайтов, поэтому знание его закрытого ключа позволяет выпускать поддельные документы, которые некоторые приложения будут считать настоящими.
В ходе эксперимента Хелме создал поддельный сертификат для платёжного API api.stripe.com и поднял тестовый сервер. Утилита curl успешно проверила сертификат, Python установил защищённое соединение, а Node.js подтвердил подлинность сервера. Аналогичные результаты были получены на системах Linux и macOS. Эксперимент показал, что если злоумышленник перехватит или перенаправит сетевое соединение, поддельный сертификат позволит выдать подконтрольный сервер за настоящий. Уязвимое приложение может передать атакующему пароли, токены доступа и другие конфиденциальные сведения. Причина слабости ключей заключалась в том, что вместо полноценного случайного значения система создала ключи, содержавшие всего один ненулевой байт. Для восстановления каждого секрета достаточно было проверить не более 255 вариантов. Все восемь слабых ключей появились 30 апреля 2025 года, и возможность их восстановления сохранялась около 17 месяцев.
Первые защитные меры были приняты 17 октября 2026 года после обращения исследователя. Google заблокировала опасные ключи в Chrome через механизм CRLSet, а Mozilla распространила блокировку через OneCRL. Пользователям с обычными настройками не понадобилось перезапускать браузеры. Аналогичную защиту для Android Google начала распространять через сервисы Google Play 19 октября. Дополнительным барьером стала система Certificate Transparency, которая требует публично регистрировать сертификаты. Google не обнаружила в журналах ни одного TLS-сертификата, выпущенного проблемными центрами до их блокировки, поэтому поддельные сертификаты не могли пройти стандартную проверку Chrome. Однако далеко не все программы используют этот механизм. Основной риск связан с приложениями, которые проверяют сертификаты иначе, чем современные браузеры: серверные API, автоматические установщики программ, системы CI/CD, облачные инструменты и пакетные менеджеры часто полагаются на локальное хранилище доверия и не проверяют отзыв сертификатов. Особенно сложная ситуация складывается с маршрутизаторами, камерами и промышленными контроллерами, которые редко получают обновления и используют встроенные в прошивку наборы доверенных сертификатов. Для части затронутых сертификатов срок действия истекает только в июле 2039 года.
Отдельную опасность представляют два скомпрометированных центра подписи программного кода. Их ключи позволяют создавать цифровые подписи, которые могут выглядеть действительными для систем Windows. При отсутствии проверки отзыва злоумышленники способны использовать такие подписи для вредоносных программ, маскируя их происхождение. Mozilla 20 октября выпустила Firefox 158.0.1 и обновления веток ESR 115.43.1 и 153.5.1, а также NSS 3.131.1 с удалением доверия к корневому сертификату emSign ECC Root CA - G3. Google исключила соответствующий корневой сертификат из Chrome Root Store, массовое распространение изменения запланировано на 27 октября. Владельцам сайтов, использующим затронутую корневую цепочку, потребуется заменить сертификаты. Cloudflare проверила свою инфраструктуру и не обнаружила признаков эксплуатации проблемы, обновив клиенты WARP и Cloudflare Tunnel.
Компания eMudhra объяснила произошедшее предварительными результатами внутреннего расследования. Во время создания ключей специалисты использовали аппаратные криптографические модули Ultimaco HSM. В сценарий генерации внесли изменения для проверки операций экспорта ключей, после чего программная ошибка привела к появлению дополнительных слабых ключевых пар. Из-за похожих обозначений сотрудники выбрали неправильные ключи для запросов на выпуск сертификатов. По версии eMudhra, первоначально оборудование создало полноценные криптографические ключи, но при дальнейшей работе сотрудники использовали слабые дубликаты. Ошибочные запросы подписали собственным корневым центром, а затем передали Sectigo для дополнительной подписи. Разработчик считает, что аппаратные модули не были непосредственной причиной проблемы, однако расследование продолжается. Компания признала несколько человеческих ошибок на разных этапах процедуры. В ходе разбирательства Mozilla обнаружила ещё одну деталь: в мае 2025 года те же промежуточные центры фигурировали в инциденте с некорректными подписями списков отозванных сертификатов. Представители eMudhra пояснили, что первоначально такие списки подписывали правильными ключами, а после обнаружения несовпадений повторно подписали ошибочными. eMudhra утверждает, что семь проблемных промежуточных центров вообще не использовались в рабочей инфраструктуре, а восьмой не выпустил ни одного конечного сертификата. Подтверждённых случаев злонамеренного применения восстановленных ключей пока нет, но отсутствие записей в публичных журналах не исключает атак на программы, которые не используют Certificate Transparency. Инцидент показал, что даже правильно работающие криптографические алгоритмы не спасают систему, если удостоверяющий центр допускает ошибку при генерации ключей, а приложения годами продолжают доверять скомпрометированным сертификатам.
