Браузер получил патч через 3 часа. А защищена ли ваша экосистема Java?
В пятницу вечером, 17 октября, исследователь доказал, что подконтрольны закрытые ключи восьми промежуточных центров сертификации eMudhra, подписав каждым из них одно и то же короткое сообщение: «У нас здесь проблема».
Mozilla получила отчет в 20:06 UTC, и уже к 22:59 UTC Firefox заблокировал сертификаты. Chrome заблокировал их в тот же день. Apple последовала примеру 19-го числа, Microsoft — 20-го.
В браузерах предусмотрен автоматический способ прекратить доверие к центру сертификации, и они применили его в течение нескольких часов, но как насчет тысяч Java-приложений, работающих в ваших дата-центрах и облаках?
Хронология реагирования на компрометацию УЦ eMudhra, 17–24 октября 2026 г.
Как eMudhra влияет на Java
По умолчанию Java не полагается на решения о доверии браузера или операционной системы. Каждый JDK поставляется с собственным хранилищем доверенных сертификатов (cacerts), а каждый образ контейнера, содержащий JDK, несет в себе собственную копию. Обновление ОС или перезапуск браузера ничего в них не меняет.
Пока каждая среда выполнения не будет обновлена, служба, совершающая исходящие TLS-вызовы (к платежному шпроцессору, партнерскому API, SaaS-платформе), может быть обманута и вынуждена доверять поддельному сертификату любым злоумышленником, способным встать между ней и пунктом назначения.
И это произошло в ту же неделю, когда вышел октябрьский квартальный патч: 53 уязвимости OpenJDK CVE — максимум для одного квартального выпуска за последние более чем десять лет.
Исправление для браузера не доходит до ваших JVM
Что я слышу от клиентов
Я каждую неделю общаюсь с корпоративными командами Java по всей Северной Америке. Большинство из них не могут перенести обновление JDK в продакшн быстрее чем за несколько недель, и главная причина кроется в том, что именно входит в состав обновления.
Типичный релиз JDK объединяет исправления безопасности с исправлениями ошибок, изменениями производительности и изменениями поведения. Каждое из них является поводом для повторного тестирования, поэтому каждое обновление запускает полный цикл регрессионного тестирования. Команды не могут взять нужное им срочно исправление без всего остального, что шло в комплекте.
В связи с этим одни и те же пробелы возникают снова и снова:
- Они не могут с уверенностью сказать, где именно работает каждая JVM, какая у нее версия и вендор, и кто за нее отвечает.
- Окна изменений назначаются ежемесячно или ежеквартально, а «экстренный» путь представляет собой конференц-связь и огромные затраты сил.
- Образы контейнеров пересобираются только тогда, когда команда разработчиков выпускает какую-то функцию.
Результат: исправление, готовое в течение нескольких часов, добирается до продакшна неделями, а иногда и целым кварталом. Именно в этом разрыве кроется реальный риск.
Затем первое исправление оказалось недостаточным
В субботу, 24 октября, вторая критическая уязвимость, CVE-2026-114820 (CVSS 9.1), показала, что черный список сертификатов, разосланный всей индустрией в среду (включая нас), не полностью закрыл брешь. Теперь исправление полностью удаляет затронутые корневые сертификаты, связанные с eMudhra, из хранилища доверенных сертификатов Java. Каждую среду выполнения Java необходимо снова обновить, включая те, которые уже установили среду из среды.
Это два экстренных обновления среды выполнения за четыре дня в дополнение к рекордному квартальному релизу. Для команды, чей самый быстрый путь к продакшн-окружению измеряется неделями, это не график патчей. Это бэклог.
Характер патча определяет скорость вашей работы
Когда обновление содержит только исправления безопасности, объем изменений, подлежащих проверке, невелик. Цикл тестирования резко сокращается, и патч может пройти путь от сборки до продакшна за считанные дни вместо квартала.
Это становится еще важнее, когда исправление не может ждать следующего запланированного релиза. Для такого инцидента, как eMudhra, требуется внеплановое обновление безопасности, в котором вы можете быть уверены, что оно ничего больше не изменит.
Это будет происходить быстрее и чаще
Цифры говорят сами за себя. В «Отчете о глобальном ландшафте угроз за 2026 год» от Rapid7 отмечается, что количество проэксплуатированных высоких и критических уязвимостей выросло более чем в два раза в годовом исчислении (на 105%), а среднее время от обнаружения до включения в каталог известных эксплуатируемых уязвимостей CISA сократилось с 8,5 дней до 5. И такие инциденты, как компрометация центра сертификации, не станут ждать вашего следующего окна обслуживания.
Раньше планом было ежеквартальное исправление. Теперь это минимум.
Окно для установки патчей сужается
Построение подхода быстрого реагирования
У команд, которые успешно справились с этой неделей, еще до ее начала были реализованы пять вещей:
- Знать: актуальный инвентарь каждой JVM, версии, вендора и хранилища доверенных сертификатов, включая те, что находятся внутри контейнеров.
- Триаж: четкий путь для принятия решения в течение нескольких часов о том, относится ли проблема к вам и насколько она срочна.
- Минимизировать: исправления только для безопасности, включая внеплановые фиксы, чтобы каждое обновление изменяло как можно меньше, а тестирование оставалось целенаправленным.
- Доказывать: автоматизированное регрессионное тестирование, способное сертифицировать обновление среды выполнения за день.
- Поставлять: конвейер, способный развернуть новую среду выполнения (и ее хранилище доверенных сертификатов) на всех узлах, а также откатить ее.
В этом нет ничего экзотического, но это должно существовать до инцидента.
Пять возможностей, которые превращают недели в часы
Это модель, которую мы создали в Azul. 20 октября наши критические патчи безопасности (Critical Patch Updates), ориентированные исключительно на безопасность, устранили все 53 уязвимости CVE без сопутствующих изменений кода. 21 октября мы выпустили внеплановое обновление, блокирующее все восемь промежуточных сертификатов eMudhra, менее чем через 24 часа после раскрытия информации. А 24 октября, когда CVE-2026-114820 показала, что этого черного списка недостаточно, наша команда работала всю ночь: около 12 часов с момента принятия решения о пересборке до выпуска сборок безопасности, попавших к клиентам. Поскольку каждое обновление несет в себе только исправление безопасности, объем тестирования для наших клиентов составляет лишь малую долю от полноценного обновления JDK.
Остальное — инвентаризация, триаж и конвейер — это именно тот разговор, который я больше всего хочу вести с Java-командами прямо сейчас.
Итак, вопрос к вам: если бы центр сертификации, которому вы доверяете, был скомпрометирован завтра утром, сколько времени пройдет, прежде чем каждая Java-служба в вашей инфраструктуре перестанет ему доверять?
Источники
- Примечания к выпуску Azul Core
Часто задаваемые вопросы
1. Если браузеры заблокировали скомпрометированные УЦ eMudhra в течение нескольких часов, почему Java-приложения все еще подвержены риску? Java не зависит от решений браузера или операционной системы о доверии. Каждый JDK поставляется с собственным хранилищем доверенных сертификатов (cacerts), а каждый образ контейнера, содержащий JDK, хранит собственную копию. Пока каждая среда выполнения не будет обновлена, служба, выполняющая исходящие TLS-вызовы к платежному шлюзу, партнерскому API или SaaS-платформе, может быть обманута и вынуждена доверять поддельному сертификату любым лицом, находящимся между ней и конечным пунктом назначения.
2. Почему исправление Java занимает недели или целый квартал, и что делает патчи, ориентированные исключительно на безопасность, более быстрыми? Типичный релиз JDK объединяет исправления безопасности с исправлениями ошибок, изменениями производительности и изменениями поведения. Каждое из них является поводом для повторного тестирования, поэтому каждое обновление запускает полный цикл регрессионного тестирования. Обновление, предназначенное только для безопасности, затрагивает исключительно исправление безопасности, поэтому объем изменений для проверки невелик. Тестирование резко сокращается, и патч может перейти из состояния сборки в продакшн за считанные дни вместо квартала. Это имеет наибольшее значение для внеплановых исправлений, таких как реакция на инцидент с eMudhra, когда вам нужно обновление, в котором вы можете быть уверены, что оно ничего больше не изменит.
3. Что необходимо иметь на предприятии для реагирования на инцидент безопасности Java в течение нескольких часов? Пять возможностей, которые должны быть внедрены до инцидента:
- Знать: актуальный инвентарь каждой JVM, версии, вендора и хранилища доверенных сертификатов, в том числе внутри контейнеров.
- Триаж: четкий алгоритм, позволяющий в течение нескольких часов определить, относится ли проблема к вам и насколько она срочна.
- Минимизация: исправления, касающиеся только безопасности, включая внеплановые патчи, чтобы тестирование оставалось сфокусированным.
- Доказательство: автоматизированное тестирование регрессий, способное подтвердить корректность обновления среды выполнения за один день.
- Поставка: конвейер, способный развернуть новую среду выполнения и ее хранилище доверенных сертификатов на всем парке систем, а также откатить изменения.
Это важно, потому что темпы ускоряются. В отчете Rapid7 Global Threat Landscape Report за 2026 год отмечается рост числа эксплуатируемых уязвимостей высокого и критического уровня на 105%, а медианное время включения в каталог известных эксплуатируемых уязвимостей CISA (KEV) сократилось с 8,5 до 5 дней.
/)
