Октябрь выдался тяжелым месяцем для поддержания максимального уровня безопасности в средах выполнения корпоративных приложений.
21 октября проект PHP выпустил экстренные исправления для двух критических уязвимостей удаленного выполнения кода (RCE) в самом интерпретаторе. Один проект, один набор релизов, один ответ на вопрос «установлен ли у меня патч?»
У недели Java все было иначе. Запланированное октябрьское обновление OpenJDK содержало патчи для 53 CVE. Это абсолютный рекорд за всю историю квартальных обновлений: более чем в три раза больше двухлетнего среднего показателя до июля этого года, составлявшего 7,6 CVE на одно обновление. Ни одна из них не была критической, но, как мы теперь знаем, ИИ может объединять уязвимости с более низким баллом в эффективную цепочку эксплойтов. Раньше можно было не беспокоиться о низких и средних оценках, но теперь это уже невозможно.
Такое большое количество патчей безопасности создает серьезные проблемы для мейнтейнеров OpenJDK. Эти 53 CVE попадают в репозиторий OpenJDK 27 через группу OpenJDK Vulnerability Group, в которую входят инженеры из таких организаций, как Azul, Amazon, Microsoft и SAP. Именно эти инженеры, а не сотрудники Oracle, несут ответственность за бэкпортирование патчей безопасности (где это необходимо) в более старые LTS-версии. На момент написания статьи, спустя девять дней после выхода обновления, для JDK8u512 или JDK 11.0.33 все еще нет тегов общей доступности (ga). Это явно влияет на любой дистрибутив, который собирается напрямую из репозитория OpenJDK. Они просто не могут выпустить обновление.
eMudhra, у нас проблема
Ситуация ухудшилась день спустя, когда выяснилось, что восемь промежуточных CA-сертификатов, созданных в апреле 2025 года под брендом emSign компании eMudhra, имели закрытые ключи, которые были достаточно слабыми для того, чтобы их мог восстановить любой желающий. Шесть из них предназначались для TLS и два для подписания кода.
Компрометация eMudhra спровоцировала критический кризис безопасности для экосистемы Java.
Браузер может перестать доверять центру сертификации за одну ночь, потому что его вендор управляет корневым хранилищем и может отправлять изменения в фоновом режиме. У автономного JDK нет такого канала. Он решает, каким корневым сертификатам доверять, из поставляемого с ним файла lib/security/cacerts и хранит отдельный черный список известных ненадежных сертификатов в lib/security/blocked.certs. Обновление браузера или операционной системы не меняет ни один из этих файлов.
Два дополнительных обстоятельства сделали этот инцидент неприятным для Java:
- Отзыв сертификатов по умолчанию отключен. Стек TLS в Java не проверяет списки отзыва сертификатов или журналы Certificate Transparency, если вы его не настроите. Быстрая реакция браузеров опиралась как раз на те механизмы, которые Java пропускает.
- Существовало два пути доверия. Скомпрометированные промежуточные сертификаты ссылались на корневой сертификат eMudhra emSign ECC Root CA – G3. Но Sectigo также переподписала те же ключи под своим корневым сертификатом AAA Certificate Services, поэтому поддельный сертификат мог пройти проверку через любой корень. Удаление только корня emSign закрывает один путь и оставляет другой.
Эскалация развивалась так быстро, что Oracle пришлось выпустить два последовательных предупреждения безопасности, поскольку первое исправление оказалось недостаточным:
Раунд 1: CVE-2026-91403 (Выпущено 21 октября 2026 г.)
Oracle выпустила экстренное уведомление (CVSS 9.1). Первое исправление (например, JDK 11.0.33.0.2 и 8u511) пыталось точечно заблокировать 8 скомпрометированных промежуточных сертификатов eMudhra (и их 8 версий с перекрестной подписью Sectigo, всего 16 сертификатов), добавив их хеши SHA-256 в внутренний файл JDK lib/security/blocked.certs.
Раунд 2: CVE-2026-114820 (Выпущено 24 октября 2026 г.)
Всего несколько дней спустя Sonatype опубликовала блог, в котором пояснялось, что внесение конкретных отпечатков промежуточных сертификатов в черный список было недостаточно агрессивным для полной изоляции угрозы во всех сценариях развертывания. Oracle выпустила второй экстренный патч. Это обновление полностью удалило корневые сертификаты eMudhra из хранилища ключей JDK cacerts.
OpenJDK — это проект исходного кода, который не предоставляет бинарные файлы, устанавливаемые вами для запуска Java-приложений. Для этого мы полагаемся на дистрибутивы от таких провайдеров, как Azul, Amazon, Red Hat, Adoptium и Oracle.
Все они представляют собой разные организации с разными инженерными командами и различными ресурсами. Это может оказаться существенно важным для того, как (и даже сможет ли) вы получить обновление, содержащее патчи, необходимые для обеспечения максимального уровня безопасности.
Коммерчески поддерживаемая среда выполнения Java, такая как Azul Core, поставляется с соглашениями об уровне обслуживания (SLA) относительно того, как быстро будут доступны патчи. Azul не зависит от репозиториев OpenJDK, поэтому компания может собирать и доставлять обновленные бинарные файлы до того, как репозитории будут полностью обновлены. Когда вы сталкиваетесь с критической уязвимостью вроде eMudhra, можете ли вы позволить себе ждать дни или даже недели, чтобы развернуть патч?
Приложения, библиотеки, среды выполнения: разные, но те же самые
Как в случае с PHP, так и в случае с Java, проблема находилась ниже уровня приложения, поэтому исправление собственного кода приложения ничего не изменило. Недостатки PHP крылись в интерпретаторе, и чистый плагин для WordPress не служил защитой. Проблема Java заключалась в хранилище доверенных сертификатов, поставляемом со средой выполнения, и чистый сервис Spring также не был защитой. Среда выполнения и поставляемые с ней файлы являются зависимостями, и они должны быть учтены в вашей инвентаризации.
Комплаенс — это не опция
Регуляторы соблюдения требований также принимают во внимание возросший уровень угроз, создаваемый обнаружением и эксплуатацией уязвимостей с помощью ИИ. В Великобритании обновление Cyber Essentials, вступившее в силу в апреле, делает пропуск 14-дневного окна для критических патчей автоматическим сбоем сертификации. Неподдерживаемое программное обеспечение на попадающем в область видимости устройстве сразу же приведет к непрохождению проверки.
Соответствие требованиям треубет подписи на декларации со стороны директора для поддержания средств контроля в течение года. Теперь под этим стоит чье-то имя.
В США федеральные поставщики сталкиваются с новой директивой CISA, основанной на оценке рисков, с 72-часовыми окнами для худших случаев. Те же самые CVE, но то, как разные дистрибутивы доставляют патчи, может сильно различаться.
Куда мы движемся дальше?
Единственная константа — это изменения, и объем изменений для патчей безопасности в среде выполнения Java, вероятно, продолжит расти, по крайней мере в краткосрочной и среднесрочной перспективе. Расширенное использование все более сложных моделей продолжит выявлять уязвимости безопасности возрастающей сложности. В сочетании со способностью агентного ИИ объединять более простые уязвимости в практические эксплойты это создаст гораздо большую рабочую нагрузку для команд DevOps, отвечающих за установку патчей.
Выбор правильного дистрибутива среды выполнения Java имеет еще более важное значение для обеспечения того, чтобы ваши корпоративные приложения поддерживали максимальный уровень безопасности.
Часто задаваемые вопросы
Почему обновление моего браузера или операционной системы не защищает Java-приложения от скомпрометированного центра сертификации?
Java не использует решения браузера или операционной системы о доверии. Каждый JDK решает, каким центрам сертификации доверять, из собственного файла lib/security/cacerts и хранит отдельный черный список в lib/security/blocked.certs, поэтому ни то, ни другое не меняется до тех пор, пока сам JDK не будет обновлен. Azul Core, коммерчески поддерживаемая среда выполнения Java, выпустила обновления безопасности исключительно для проблемы компрометации eMudhra 21 и 24 октября 2026 года.
Чем дистрибутивы JDK отличаются по скорости выпуска обновлений безопасности Java?
OpenJDK — это проект исходного кода, а бинарные файлы, которые вы устанавливаете, поступают от таких дистрибутивов, как Azul, Amazon, Red Hat, Adoptium и Oracle, каждый из которых имеет свои инженерные команды и ресурсы. Дистрибутивы, создающие сборки исключительно на основе репозиториев OpenJDK, не могут выполнить поставку, пока эти репозитории не будут обновлены: спустя девять дней после октябрьского обновления 2026 года версии JDK 8u512 и JDK 11.0.33 все еще не имели тегов общей доступности (general availability). Azul Core поставляется с соглашениями об уровне обслуживания (SLA) в отношении скорости предоставления патчей, и Azul не зависит от репозиториев OpenJDK, поэтому компания может выпускать обновленные бинарные файлы до того, как они будут полностью обновлены там.
Что нужно обновить для защиты приложений Java от компрометации сертификата eMudhra?
Для устранения этой компрометации требовалось два исправления. Первое, CVE-2026-91403 (21 октября 2026 г.), добавило 16 сертификатов — восемь скомпрометированных промежуточных сертификатов eMudhra и восемь их кросс-подписанных версий Sectigo — в файл blocked.certs JDK. Второе, CVE-2026-114820 (24 октября 2026 г.), удалило корневые сертификаты eMudhra из хранилища ключей cacerts JDK, поэтому среды выполнения, к которым было применено только первое обновление, нуждаются во втором. Клиентам Azul Core и Azul Prime следует обновиться до сборок от 24 октября, даже если они уже применили сборки от 21 октября.
Чего требуют правила комплаенса при устранении критических уязвимостей Java?
В Великобритании обновление Cyber Essentials, вступившее в силу в апреле, делает пропуск 14-дневного окна для критических исправлений автоматической причиной непрохождения сертификации, а неподдерживаемое программное обеспечение на устройстве из области действия стандарта не проходит ее безоговорочно. В США федеральные поставщики сталкиваются с новой директивой CISA, основанной на оценке рисков, с 72-часовыми окнами для наиболее серьезных случаев. Коммерчески поддерживаемый дистрибутив, такой как Azul Core, с соглашениями об уровне обслуживания (SLA) по доступности патчей предоставляет командам четкий график, с которым можно сверять эти временные окна.
