Браузеры были защищены за несколько часов. А корпоративная Java? Как LOGIQ отреагировала на инцидент с сертификатами eMudhra

Браузеры заблокировали скомпрометированные промежуточные сертификаты eMudhra за часы, но у каждого JDK своё хранилище. Что выпустили Azul и BellSoft, что сделала LOGIQ.

Что произошло

В субботу, 17 октября 2026 года, в 20:06 UTC Mozilla получила сообщение о том, что закрытые ключи восьми промежуточных сертификатов eMudhra были скомпрометированы. Mozilla заблокировала эти восемь сертификатов в Firefox через OneCRL — свой централизованный список отзыва, и к 22:59 UTC, менее чем через три часа, обновление дошло до пользователей со стандартными настройками. Mozilla публично сообщила об инциденте 20 октября. Она также выпустила корректирующие версии Firefox для пользователей, у которых настройки блокировали обновление OneCRL, и удалила корневой сертификат, которым были подписаны промежуточные, из хранилища доверенных сертификатов NSS.

Риск — подделка сертификатов. Любой, у кого есть один из этих ключей, мог бы выпустить HTTPS-сертификат для сайта, который он не контролирует. Если бы ему также удалось встроиться между клиентом и этим сайтом, он мог бы выдавать себя за сайт и читать или изменять трафик.

Пока нет свидетельств того, что это произошло. В своём заявлении об инциденте eMudhra сообщает, что восемь промежуточных сертификатов были отозваны 18 октября, что ни один из них не выпускал сертификатов конечных субъектов и что ей «неизвестно о каких-либо свидетельствах того, что слабые ключи были восстановлены или использованы кем-либо до раскрытия проблемы». В качестве причины eMudhra называет слабые ключи, сгенерированные во время церемонии генерации ключей в 2025 году. По её словам, точная первопричина ещё не подтверждена, расследование продолжается. Корневые программы браузеров в качестве меры предосторожности прекратили доверие к корневому сертификату eMudhra, стоящему над этими промежуточными.

Таким образом, эта статья о том, как закрыть окно уязвимости, а не о подтверждённой атаке.

Почему Java нужно отдельное исправление

У браузеров и операционных систем есть автоматические механизмы, позволяющие перестать доверять удостоверяющему центру, и они быстро ими воспользовались. Согласно описанию инцидента от Azul, Chrome заблокировал сертификаты в тот же день, Apple — 19 октября, а Microsoft — 20 октября.

Java ничего из этого не наследует. JDK решает, каким сертификатам доверять, на основе собственных файлов:

• Собственное хранилище доверенных сертификатов. Каждый JDK поставляется со своим файлом cacerts. Обновление набора сертификатов операционной системы или перезапуск браузера его не меняет.
• По умолчанию отзыв не проверяется. Как сказано в документации Azul, Java доверяет корневым сертификатам, к которым ведут цепочки этих промежуточных, и «по умолчанию не проверяет отзыв». Сам по себе отзыв промежуточных сертификатов со стороны eMudhra не защищает Java-клиента.
• Множество копий. На одном сервере могут работать системный JDK, JDK, встроенный в приложение, среда выполнения, собранная с помощью jlink, и несколько образов контейнеров — каждый со своей копией хранилища доверенных сертификатов. Каждая копия остаётся уязвимой, пока её не обновят или не пересоберут.

Поэтому Java-сервис, устанавливающий исходящие TLS-соединения, может по-прежнему принять поддельный сертификат, даже когда все браузеры в здании уже защищены. Именно об этом разрыве и идёт речь в статье.

Два экстренных обновления от Azul

После своего ежеквартального октябрьского выпуска Azul выпустила два внеплановых обновления Azul Zulu:

• 21 октября: первое внеплановое обновление добавляет восемь скомпрометированных промежуточных сертификатов в список блокировки JDK (blocked.certs в JDK 11 и новее, blacklisted.certs в более старых версиях). Оно охватывает Zulu 27, 25, 21, 17, 11, 8, 7 и 6. В списке CVE Azul оно значится как CVE-2026-91403. Для сред выполнения, которые нельзя было обновить сразу, Azul также опубликовала ручное обходное решение, заменяющее файл списка блокировки.
• 24 октября: Azul обнаружила, что список блокировки не закрывает проблему полностью. Второе внеплановое обновление устраняет CVE-2026-114820 (JSSE, базовая оценка 9.1), полностью удаляя определённые сертификаты УЦ из cacerts. На момент написания статьи эти сборки доступны для линейки Azul CPU, содержащей только исправления безопасности, — как на базе CPU за октябрь 2026 года (например, Zulu 21.53.114, 17.69.114, 11.91.114 и 8.97.0.112), так и на базе CPU за июль 2026 года. По словам Azul, сборки PSU, «скорее всего», последуют в отдельном обновлении.

Обновление от 24 октября меняет рекомендации. На странице с обходным решением Azul теперь предупреждает, что оно «больше не решает проблему полностью», и Azul рекомендует всем клиентам обновиться до последнего выпуска. Если вы установили обновление от 21 октября или применили обходное решение, вам всё равно нужна сборка от 24 октября. В собственном разборе Azul сообщает, что от решения о пересборке до получения клиентами сборок с исправлениями безопасности прошло около 12 часов.

Что BellSoft выпустила для Liberica JDK

21 октября BellSoft опубликовала свой регулярный выпуск Liberica JDK за октябрь 2026 года. В этом ежеквартальном выпуске указаны 52 исправленные CVE, и он включает сборки CPU для Java 6 и 7 (6u521 и 7u521). Проблема eMudhra в примечаниях к выпуску не рассматривается.

BellSoft описывает ситуацию с eMudhra в отдельном руководстве «Distrusting compromised eMudhra intermediates in Java» (последнее обновление — 27 октября). В нём исправленными сборками названы Liberica JDK 8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5 и 27.0.1.0.3+5. Для систем, которые пока нельзя обновить, руководство предлагает временную меру: удалить затронутые корневые сертификаты из хранилища доверенных сертификатов. Оно предупреждает, что это может нарушить легитимные цепочки сертификатов и что такую меру нужно сначала протестировать.

При сравнении поставщиков важны два момента:

• Списки CVE не совпадают. Azul и BellSoft публикуют собственные списки CVE для октябрьского цикла, и количество, и примечания в них различаются. Два указанных выше идентификатора CVE от Azul взяты из записей Azul. В руководстве BellSoft они не упоминаются. Проверяйте примечания к выпуску своего поставщика, чтобы узнать точные исправления в вашей сборке, и не считайте, что список одного поставщика применим к JDK другого.
• Java 6 и 7 отсутствуют в списке BellSoft по eMudhra. Последние сборки BellSoft для Java 6 и 7 доступны, но список исправленных сборок в руководстве по eMudhra начинается с Java 8. Если вы используете Liberica 6 или 7, уточните, включает ли ваша сборка изменение хранилища доверенных сертификатов, прежде чем на неё полагаться, или примените меру, предложенную поставщиком. Azul указывает сборки от 24 октября для Zulu 6 и 7.

Как отреагировала LOGIQ

Мы распространяем сборки Java от BellSoft и Azul среди наших клиентов и помогаем им уйти со старых версий Oracle JDK. Ниже — что мы сделали, со статусом каждого пункта на момент написания статьи (29 октября).

Выполнено

• 21–22 октября: изучены уведомления поставщиков. Мы получили и изучили внеплановое уведомление Azul от 21 октября и уведомление BellSoft о выпуске за октябрь 2026 года. В тот же день мы открыли задачи на загрузку и размещение в репозитории для обоих поставщиков. Мы рассматривали два выпуска по отдельности и не исходили из того, что ежеквартальный выпуск BellSoft содержит такое же исправление для eMudhra, как у Azul.
• 23 октября: подготовлены ежеквартальные сборки Liberica. Мы загрузили сборки Liberica JDK за октябрь 2026 года с портала поддержки BellSoft и добавили их в репозиторий, из которого их скачивают наши клиенты.
• 24–25 октября: отслежено второе обновление Azul. Мы получили уведомление Azul от 24 октября, включая рекомендацию обновиться, даже если сборка от 21 октября уже установлена.
• 27–28 октября: исправленные сборки Liberica получены через BellSoft. В рамках коммерческой поддержки мы попросили BellSoft разместить новейшие сборки на нашем портале поддержки. BellSoft загрузила их 28 октября, включая исправленные сборки для Java 8, 11, 17, 21, 25 и 27 и последние сборки Java 6 и 7. Некоторым клиентам по-прежнему нужна 32-разрядная Java 8, поэтому мы также попросили BellSoft добавить на наш портал 32-разрядные установщики 8u513+9 для Windows и Linux. BellSoft добавила их в тот же день.
• 28–29 октября: обновлены репозиторий и схемы миграции. Мы добавили эти сборки в наш репозиторий для клиентов и обновили рекомендации по миграции с Oracle JDK на Liberica, чтобы они указывали на эти сборки; изменения проверил второй инженер.

Клиенты Azul Zulu

Сборки Azul от 21 и 24 октября доступны подписчикам Azul через Azul. Подходящая сборка зависит от версии Java, от того, используете ли вы линейку CPU или PSU, и от базы (октябрьской или июльской). Проверьте примечания к выпуску Azul для вашей конкретной сборки или обратитесь к нам — мы поможем её определить.

Устаревшие Java 6 и 7

Некоторые клиенты всё ещё используют Java 6 или 7, часто в приложениях, которые нельзя быстро перевести на новые версии. Oracle больше не выпускает публичных обновлений для этих версий, но варианты у таких клиентов есть. Мы помогаем клиентам перейти со старых сборок Oracle JDK 6 и 7 на последние сборки Liberica JDK 6 и 7, а октябрьские сборки BellSoft 2026 года для обеих версий доступны нам через портал поддержки BellSoft. Если нужного нам исправления или пакета для этих версий нет, мы передаём запрос в BellSoft через канал коммерческой поддержки. Относительно этого инцидента см. примечание выше: прежде чем полагаться на свою сборку Java 6 или 7, убедитесь, что она включает изменение хранилища доверенных сертификатов, связанное с eMudhra.

Что нужно сделать сейчас

1. Найдите все среды выполнения Java

Составьте список всех мест, где работает Java, а не только системного JDK. Сюда входят серверы приложений, среды выполнения, встроенные в продукты сторонних поставщиков, образы jlink, агенты сборки CI и все образы контейнеров. В Linux следующая команда находит исполняемые файлы Java на хосте:

find / -xdev -type f -path "*/bin/java" 2>/dev/null

Для образов контейнеров выполните проверку внутри образа, например docker run --rm --entrypoint java <image> -version.

2. Проверьте точного поставщика и сборку

Основной версии недостаточно. Чтобы сверить с указанным поставщиком списком исправленных сборок, нужны название поставщика и полный номер сборки:

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

Для быстрой оценки можно также вывести список корневых сертификатов eMudhra (emSign) в хранилище доверенных сертификатов среды выполнения:

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

В наших тестах с публичными образами контейнеров BellSoft более старая сборка Liberica 21.0.10 показала пять корневых сертификатов emSign, а исправленные сборки 21.0.13.0.3+5 и 8u513 — ни одного. Пустой результат — хороший признак, но не доказательство. Например, исправление Azul от 21 октября блокировало промежуточные сертификаты, не удаляя корневые. Надёжная проверка — номер сборки. Более подробные проверки описаны в нашей предыдущей статье о проверке хранилищ доверенных сертификатов Java.

3. Установите последний применимый патч

• Azul Zulu: перейдите на внеплановую сборку от 24 октября для вашей линейки (CPU или PSU, октябрьская или июльская база), даже если вы установили сборку от 21 октября или применили обходное решение. Если вы используете сборки PSU, следите за последующим выпуском PSU от Azul.
• Liberica JDK: перейдите на исправленные сборки, указанные BellSoft (8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5).
• Другие поставщики и встроенные среды выполнения: изучите бюллетень соответствующего поставщика. JDK внутри стороннего продукта обновляет поставщик этого продукта, а не обновления вашей ОС.
• Контейнеры: пересоберите образы на исправленном базовом образе и разверните их заново. Исправление работающего контейнера не меняет образ.

4. Проверяйте TLS до и во время развёртывания

Удаление корневых сертификатов из хранилища может нарушить легитимные соединения, например с сайтами, которые всё ещё используют сертификаты с цепочкой к удалённым корневым сертификатам eMudhra. eMudhra сообщает, что перевыпускает затронутые сертификаты клиентов от альтернативной иерархии УЦ. Перед массовым развёртыванием протестируйте исходящие TLS-соединения, от которых зависят ваши приложения, особенно с партнёрами или сервисами, которые могут использовать сертификаты eMudhra. Развёртывайте поэтапно, перезапускайте процессы Java, чтобы они загрузили новое хранилище доверенных сертификатов, а затем проверяйте работающую версию.

5. Следите за внеплановыми выпусками

Этот инцидент привёл к двум экстренным выпускам Java за четыре дня, и могут последовать новые, например сборки PSU от Azul. Подпишитесь на уведомления о безопасности от своих поставщиков, проверяйте их страницы выпусков напрямую, а не полагайтесь только на электронную почту, и закладывайте в планы обновления Java вне ежеквартального графика.

Вывод

Пользователи Firefox были защищены за несколько часов, потому что у браузеров есть собственные хранилища доверенных сертификатов и автоматический способ их обновления. В корпоративной Java много хранилищ, по умолчанию нет проверки отзыва, а обновления ждут, пока их кто-нибудь установит. Чтобы закрыть этот разрыв, нужны точная инвентаризация, точные номера сборок, быстрый доступ к сборкам поставщиков и процесс, который не ждёт следующего ежеквартального патча. Если вам нужна помощь в поиске или обновлении сред выполнения Java в вашей инфраструктуре, свяжитесь с LOGIQ.

Источники

• Блог безопасности Mozilla: Protecting Firefox users following the compromise of eMudhra intermediate certificates (20 октября 2026 г.)
• eMudhra: Statement on recent certificate security incident (последнее обновление — 28 октября 2026 г.)
• Azul: Примечания к внеплановому выпуску от 21 октября 2026 г.
• Azul: Примечания к внеплановому выпуску от 24 октября 2026 г.
• Azul: Список CVE для Azul Zulu
• Azul: Обходное решение для компрометации промежуточных сертификатов УЦ eMudhra
• Блог Azul: Java patching at incident speed: lessons from the eMudhra CA compromise (27 октября 2026 г.)
• BellSoft: Distrusting compromised eMudhra intermediates in Java (последнее обновление — 27 октября 2026 г.)
• BellSoft: Выпуск Liberica JDK за октябрь 2026 г. (21 октября 2026 г.)