Oracle и OpenJDK экстренно обновили Java: хранилище cacerts доверяло сертификатам eMudhra со слабыми ключами

21 октября 2026 года Oracle и OpenJDK вне квартального графика закрыли CVE-2026-91403 с оценкой CVSS 9.1. Встроенное хранилище сертификатов Java (cacerts) доверяло восьми промежуточным центрам сертификации eMudhra, чьи закрытые ключи можно вычислить из публичных сертификатов. Обновите JDK и JRE во всех окружениях — от серверов до CI.

Уязвимость затрагивает не код вашего приложения, а цепочку доверия: любой Java-клиент, который ходит по HTTPS к внешним API, платёжным шлюзам или микросервисам, мог принять поддельный сертификат как настоящий. Если ваш бэкенд или API работает на JVM — Spring, Quarkus, Micronaut, Kotlin на сервере, — патч касается вас напрямую.

Это вторая на этой неделе история о доверии TLS в популярных рантаймах: тот же промежуточный центр eMudhra убран из хранилища корневых сертификатов в свежем выпуске Node.js — подробнее в новости об октябрьских патчах Node.js. Для команд, которые ведут Android-разработку на Java и Kotlin, важно другое: серверные сборки и CI-раннеры с JDK тоже нужно обновить.

Что случилось с сертификатами eMudhra

eMudhra — индийский центр сертификации, чьи корневые сертификаты входят в стандартные хранилища доверия. По данным Azul, 20 октября было публично раскрыто, что закрытые ключи восьми промежуточных центров сертификации eMudhra сгенерированы с дефектом: любой желающий может восстановить их из открытых сертификатов. Apple, Google, Microsoft и Mozilla уже заблокировали эти сертификаты в браузерах и операционных системах, а Mozilla и Chrome Root Program подтвердили компрометацию.

Проблема для Java в том, что JDK поставляется со своим набором корней. Цепочки к скомпрометированным промежуточным центрам строились от корней, которые лежат в cacerts. Злоумышленник «посередине» соединения мог выпустить сертификат на любое доменное имя, и TLS-клиент на Java счёл бы его доверенным — так описывает сценарий Red Hat.

Какие версии Java затронуты

• OpenJDK — advisory от 21 октября: компонент security-libs/javax.net.ssl, CVSS 3.1 — 9.1; уязвимы 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.32.1, 8u504 и более ранние сборки.
• Oracle Java SE и GraalVM — внеплановый Security Alert от 21 октября; в перечне Oracle — Java SE 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 и 27.0.1, а также ряд выпусков GraalVM.
• Azul Zulu и Prime — обновления вышли 21 октября: Zulu для версий 27, 25, 21, 17, 11, 8, 7 и 6, Prime — для 25, 21, 17, 11 и 8.
• Red Hat оценивает риск ниже — 6.8 (атака сложнее и требует действий пользователя). RPM-пакеты OpenJDK, которые берут сертификаты из системного ca-certificates, получат исправление через его обновление; переносимые (portable) сборки для Linux и Windows обновляются отдельно.
• IBM опубликовала отдельный бюллетень о влиянии на IBM SDK, Java Technology Edition.

Важная деталь исправления: OpenJDK не удаляет корневой сертификат eMudhra, а блокирует конкретные промежуточные сертификаты через список blocked.certs. Сайты, легитимно работающие на других цепочках eMudhra, продолжат открываться.

Почему это опаснее обычного CVE в библиотеке

Обычную уязвимость закрывает обновление зависимости в одном проекте. Здесь проблема в данных, которые лежат внутри каждой установленной JVM: в базовых Docker-образах, в JRE на серверах приложений, в агентах CI и в собственных truststore, которые команды когда-то скопировали из cacerts. Обновить pom.xml или build.gradle недостаточно — исправление приезжает только вместе с новой сборкой рантайма или системного пакета сертификатов.

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

Что сделать команде разработки

1. Обновите JDK/JRE до сборок от 21 октября у вашего поставщика: Oracle, Azul, Red Hat, IBM, Eclipse Temurin или другого дистрибутива OpenJDK.
2. Пересоберите контейнеры. Тег базового образа вроде eclipse-temurin:21 подтянет исправление только при новой сборке, а уже запущенные поды продолжат работать со старым cacerts.
3. Обновите системный пакет ca-certificates на хостах с RHEL-совместимыми дистрибутивами, где OpenJDK берёт сертификаты из системы.
4. Проверьте собственные truststore. Если приложение использует отдельный JKS или PKCS12, скопированный из cacerts, обновление JDK его не исправит — уберите из него цепочки eMudhra вручную.
5. Если обновиться прямо сейчас нельзя, OpenJDK и Azul предлагают временную меру: заменить файл blocked.certs в каталоге lib/security каждой установленной JVM и перезапустить приложение. Это обходной путь, а не замена обновлению.

Часто задаваемые вопросы

Затронуты ли Android-приложения? Android использует собственное системное хранилище сертификатов, а не cacerts из JDK; по данным Azul, Google уже заблокировала эти сертификаты в своих операционных системах. Но серверная часть приложения, сборочные агенты и инструменты на JVM должны быть обновлены.

Почему оценки CVSS расходятся — 9.1 и 6.8? OpenJDK и Oracle считают атаку простой и не требующей действий пользователя. Red Hat учитывает, что злоумышленнику нужно оказаться на сетевом пути между клиентом и сервером, поэтому ставит высокую сложность. Для планирования патча разница невелика: обновлять нужно в любом случае.

Хватит ли включить проверку отзыва сертификатов? eMudhra отозвала проблемные сертификаты, но проверка отзыва в Java по умолчанию часто не включена, а при сетевых сбоях может молча пропускаться. Надёжнее обновить рантайм или блок-лист.

Источники

• OpenJDK Vulnerability Group — OpenJDK Vulnerability Advisory: 2026/10/21 (первоисточник).
• Oracle — Security Alert Advisory CVE-2026-91403, 21 октября 2026.
• Red Hat Customer Portal — CVE-2026-91403.
• Azul — Statement on the eMudhra Intermediate CA Certificates Compromise, октябрь 2026.
• IBM — eMudhra CA Certificate Compromise (CVE-2026-91403): Impact on IBM SDK, Java Technology Edition.