С вашим Artifactory все в порядке. А вот с хостом Linux, на котором он работает, возможно, нет.

Источник: JFrog•

С вашим Artifactory все в порядке. А вот с хостом Linux, на котором он работает, возможно, нет.

Клиенты JFrog, использующие самоуправляемые инсталляции, должны проверить и пропатчить хосты Linux на уязвимость CVE-2026-98432. Узнайте, как проверить ядро, применить исправления и минимизировать риски эксплуатации гонки состояний уже сегодня.

Сводка Как мы уже писали, технологии ИИ сокращают время между моментом публикации исправления и появлением рабочего эксплойта практически до нуля. Продукты JFrog не подвержены уязвимости ядра Linux CVE-2026-98432. Artifactory, Xray и остальная часть платформы JFrog не содержат этой ошибки, так как она находится в самом ядре Linux. Мы рекомендуем всем клиентам, использующим самоуправляемые инсталляции JFrog, проверить свои хосты Linux и немедленно обновить ядра для защиты своих сред, которые могут включать размещенные версии продуктов JFrog. После обновления ОС продукты JFrog не подвергаются риску.

Наша цель всегда заключается в защите ваших систем, и в некоторых случаях это может включать рекомендации по защите сред, в которых функционируют ваши продукты JFrog. Клиенты JFrog Cloud не подвержены данной уязвимости Linux, но если вы самостоятельно управляете JFrog, читайте дальше.

Ваше ядро Linux может быть уязвимо, что требует его патчинга для защиты вашей среды.

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

15 октября команда разработчиков ядра Linux по безопасности опубликовала уязвимость CVE-2026-98432. Это уязвимость типа use-after-free в коде настройки новых соединений IPv4 TCP, вызванная состоянием гонки (race condition). Ошибка берет свое начало в Linux 4.4. Разработчики исправили ее 5 октября после патчинга основной ветки 17 сентября; исправление в upstream появилось на целых десять дней раньше, чем CVE стала публичной.

Команда разработчиков ядра оценивает эту уязвимость в 9,8 балла. Red Hat, Oracle, SUSE и Amazon оценивают ее ниже — от 5,9 до 8,1 балла.

Затем компания Anthropic опубликовала 27 октября исследование, в котором утверждается, что ее модель Claude написала рабочий эксплойт. Удаленный злоумышленник без учетных данных получает root-оболочку на серверах со слушателем multipath TCP (MPTCP). В тесте Anthropic утечка адреса ядра заняла 48 минут. Получение возможности выполнения команд заняло всего на пять минут больше. В этом сценарии потеря гонки приводит к разрыву только этого одного соединения, поэтому злоумышленник просто пробует снова.

Важно отметить, что Anthropic не опубликовала код эксплойта. По состоянию на 2 ноября не было зафиксировано ни одного сообщения об атаках «в дикой природе». MPTCP менее экзотична, чем кажется: начиная с Go 1.24, программы на Go запрашивают этот протокол по умолчанию для сокетов, которые они прослушивают. Команда безопасности Go также отмечает, что лежащая в основе ошибка не ограничивается только MPTCP. (Подсказка: развертывания JFrog включают в себя несколько сервисов на Go версий выше 1.24.)

Какму клиенту JFrog…

В самоуправляемом развертывании вы владеете операционной системой, в которой работает JFrog. Мы несем ответственность за безопасность наших продуктов, а вы — за лежащую в основе платформу (хост, ядро, патчинг) в рамках модели совместной ответственности. Уязвимое ядро под исправной инсталляцией JFrog все равно подвергает риску этот хост и все, что на нем находится.

По состоянию на 30 октября ни Ubuntu, ни RHEL не выпустили исправленное ядро. Версии Ubuntu от 22.04 до 26.10 отмечены как находящиеся в разработке, а более старые выпуски уязвимы напрямую. RHEL 8, 9 и 10 указаны как затронутые, без указания даты. Debian, Oracle Linux, SUSE и Amazon Linux выпустили исправления по крайней мере для некоторых ядер. Проверьте вашу конкретную версию, так как покрытие различается в зависимости от дистрибутива.

Что мы рекомендуем сделать как можно скорее

  • Узнайте, что именно запущено у вас. Номера версий могут обманывать, поскольку дистрибутивы бэкпортируют исправления без изменения номеров версий. Вместо этого проверьте журнал изменений (changelog).

В Debian или Ubuntu:

В RHEL и его производных:

Если команда ничего не выводит, ваше работающее ядро не содержит исправления.

  • Установите патч там, где доступно исправление, а затем перезагрузите систему. Обновление ядра ничего не дает до тех пор, пока машина не загрузится с ним. Если вы собираете собственное ядро, исправление содержится в версиях 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 и 7.3. Команда разработчиков ядра рекомендует переходить на последний стабильный выпуск, а не выбирать один коммит.
  • Там, где исправления еще нет, действуйте проактивно. Red Hat заявляет, что ни одно из доступных средств минимизации рисков не соответствует ее стандартам. Отключение MPTCP для каждой программы в отдельности является ненадежным методом, о чем напрямую говорит команда Go: стоит забыть про один слушатель, и вы снова уязвимы. Ограничьте круг лиц, имеющих доступ к этим хостам на сетевом уровне, следите за бюллетенями безопасности вашего вендора по уязвимости CVE-2026-98432 и устанавливайте патч в день выхода пакета. Другим вариантом минимизации рисков может быть использование балансировщика нагрузки уровня L7 или обратного прокси-сервера с завершением TCP (TCP termination) для снижения прямого воздействия на уязвимые хосты. Снижение подверженности угрозам не устраняет саму ошибку, но уменьшает количество людей, которые могут попытаться ее проэксплуатировать.
  • Сделайте следующую процедуру проще. Если вы проксируете свои репозитории Debian или RPM через Artifactory, исправленное ядро поступает в репозиторий, из которого ваши хосты уже выполняют скачивание. Подготовьте его, продвиньте и внедряйте волнами, используя тот же процесс, что и для всего остального. Пакет ядра — это такой же артефакт, как и любой другой, и у него должна быть система учета.

JFrog Xray сканирует артефакты и образы вашей цепочки поставок. Он не подскажет, какое ядро работает на вашем хосте, так как ядро не входит ни в один из них; первым шагом является выполнение команды, которую вы должны запустить самостоятельно.

Окно уязвимости велико, но сужается

В условиях, когда время от исправления до эксплойта стремится к нулю, требуется оперативный патчинг. Исправление этой уязвимости было опубликовано 5 октября. Новость о появлении рабочего эксплойта появилась 27 октября. 30 октября в двух наиболее распространенных корпоративных дистрибутивах все еще не было обновлений.

Наша рекомендация по защите ваших систем проста:

Запустите проверку журнала изменений на каждом хосте, на котором сегодня работает JFrog. Обновите систему и выполните перезагрузку там, где существует исправленное ядро. Там, где его нет, ограничьте доступ и

Примечание: Содержимое этого блога предоставляется исключительно в общих информационных и ознакомительных целях. Оно отражает информацию, доступную на дату публикации, указанную ниже, и может не обновляться. Примеры и результаты носят иллюстративный характер; фактические результаты могут отличаться в зависимости от вашей среды и вариантов использования. JFrog не дает никаких заявлений или гарантий относительно того, что содержимое является полным, точным, актуальным или подходящим для ваших конкретных обстоятельств. Вы несете ответственность за оценку содержимого перед тем, как полагаться на него. Содержимое этого блога не изменяет никаких соглашений, регулирующих использование вами продуктов или услуг JFrog. Использование продуктов по-прежнему регулируется применимым Соглашением о подписке JFrog или другим письменным соглашением между вами и JFrog.

О чём эта статья

Ещё в разделе «Разработка ПО»

Все →

Ещё от JFrog