Квартальное обновление безопасности Oracle закрывает несколько десятков уязвимостей в Java SE, JavaFX и GraalVM Enterprise Edition. Часть из них позволяет вызвать отказ в обслуживании, часть - прочитать или изменить данные приложения, отдельные дают выйти за пределы песочницы Java, то есть изолированной среды для недоверенного кода. Проверка охватила не только собственный код платформы, но и сторонние библиотеки libxml2 и GStreamer, которые Oracle поставляет в составе JavaFX.
Компоненты Java SE, затронутые уязвимостями
Статус уведомления - подтверждённая уязвимость: Oracle проверила продукты и выпустила исправления. Затронуты все поддерживаемые ветки Java SE, от восьмой до двадцать седьмой, включая сборки 8u503, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1 и 26.0.2. В том же списке JavaFX 21.0.12, 25.0.4 и 27, GraalVM Enterprise Edition 21.3.19.1.1, GraalVM for JDK 17.0.20.1 и 21.0.12.1.
Список компонентов широкий. Уязвимости нашлись в компиляторе, сетевом стеке, средствах разбора XML (JAXP), драйвере доступа к базам данных (JDBC), механизме удалённого вызова методов (RMI), подсистеме работы с изображениями, встроенном HTTP-сервере и в брокере объектов CORBA. Отдельные записи касаются службы аутентификации и авторизации (JAAS), протокола TLS, который шифрует соединения, механизма JGSS, отвечающего за защиту обмена сообщениями, шрифтов и графики, звука, служебных утилит JDK и плагина браузера.
Атака почти во всех случаях идёт по сети, учётные данные не нужны. Для части проблем достаточно передать данные в прикладной интерфейс, принимающий их извне, - типичная ситуация для веб-сервиса на Java. В JavaFX, подсистеме звука и графической библиотеке AWT успех зависит от пользователя: он должен открыть файл или запустить приложение. Четыре проблемы требуют локального входа на хост, где исполняется Java.
Область действия Oracle оговаривает отдельно. Многие из этих уязвимостей проявляются в клиентских установках, где исполняется недоверенный код: в приложениях Java Web Start и апплетах, которые полагаются на песочницу. На серверах, где работает только доверенный код администратора, эти же проблемы обычно не срабатывают. Зато уязвимости в сетевом стеке, JDBC и разборе XML от характера кода не зависят. Самый высокий балл в выпуске - 7.5 из 10, столько Oracle выставила ошибке в WebKitGTK, которую использует JavaFX.
Две записи относятся не к коду Oracle. Путаница типов в libxml2 (CVE-2026-6732) возникает, когда библиотека разбирает XML-документ со ссылкой на внутреннюю сущность: тип объекта определяется неверно, и приложение падает. Вторая проблема - целочисленное деление на ноль в GStreamer при разборе звуковой дорожки в формате MP4, она приводит к аварийному завершению обработки файла. Обе библиотеки входят в поставку JavaFX, поэтому исправлять их нужно вместе с платформой.
Сведений об эксплуатации в реальных атаках нет. Раскрытие технических деталей не означает атаку: Oracle опубликовала состав обновления, но сообщений об использовании этих уязвимостей не приводит. Косвенный признак - оценки EPSS, прогноза вероятности эксплуатации в ближайшие 30 дней: для всех перечисленных записей они ниже одного процента. Порог входа здесь выше, чем у сетевых ошибок с готовым эксплойтом (вредоносным кодом, использующим уязвимость), - нужен разбор форматов файлов или точное знание прикладного интерфейса.
Исправления вышли в октябрьском квартальном обновлении Oracle. Номера исправленных сборок вендор приводит в документе CPU388 на support.oracle.com, в открытом описании их нет. Патчи Java SE доступны клиентам с действующим контрактом поддержки, поэтому точные версии для своей ветки удобнее смотреть в этом документе. Дистрибутивы Linux закрывают те же проблемы своими сборками OpenJDK: Red Hat отметила затронутость пакетов java-*-openjdk во всех ветках RHEL, Debian и Ubuntu - пакета openjdk-17.
Порядок действий зависит от того, что запущено на узле. Серверы обновляют в первую очередь: уязвимости в сетевом стеке, JDBC и JAXP доступны извне, даже если недоверенный код там не исполняется. На рабочих станциях с Java SE 8 повод пересмотреть отношение к плагину браузера, у него отдельная уязвимость. Если JavaFX на узле не нужен, его пакеты лучше не устанавливать - так остаётся меньше кода, который принимает чужие файлы. На RHEL, Debian и Ubuntu обновление приходит через штатный пакетный менеджер.
Для большинства организаций риск умеренный. Серверный парк обновляют планово, а часть проблем закрыта самой песочницей. Однако уязвимости в сетевом стеке и разборе XML работают независимо от того, доверенный ли код исполняется, и именно они задают сроки установки обновления.
Ссылки
