Крупная компания поднимает тревогу: в Java-проектах на Spring Boot нашли уязвимость, которая позволяет запустить код через обычный JSON-запрос. Для этого атакующему не нужен вход в систему, а исполняться код будет с правами процесса Java.

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

Речь идёт о проблеме в Fastjson 1.x — библиотеке Alibaba для работы с JSON в Java. Уязвимость получила номер CVE-2026-16723 и оценку CVSS 9,0.

По данным ThreatBook и Imperva, атаки уже идут. Alibaba опубликовала предупреждение 21 июля, а к 25 июля исправленной версии Fastjson 1.x в открытых источниках так и не появилось.

Как работает атака

Эксплойт срабатывает не на любом Java-сервисе, а на довольно конкретной конфигурации. Нужны Fastjson версий с 1.2.68 по 1.2.83, исполняемый Spring Boot fat-JAR, доступная извне точка входа и отключённый SafeMode.

Важно, что AutoType может быть выключен — это не спасает. В одном из сценариев вредоносный JSON использует поле @type, которое Fastjson превращает в обращение к ресурсу класса. В подходящей fat-JAR-сборке это открывает путь к загрузке кода из вложенного JAR-файла.

Исследователи описывают и вариант для более новых версий Java: там злоумышленник может сослаться на удалённый JAR через /proc/self/fd. Alibaba отдельно пишет, что обычные JAR, универсальные uber-JAR и развертывания в Tomcat или Jetty под удар не попадают.

Если нужен общий фон о том, как хрупко ведут себя серверные библиотеки на стыке приложений и загрузчиков, посмотрите наш разбор уязвимости Zilliqa и Ledger и материал о том, как атакующие используют веб-обвязку серверов в WP-SHELLSTORM.

Кого затронуло и чем это грозит

ThreatBook утверждает, что зафиксировала эксплуатацию в реальных атаках после того, как добавила детектирование. Imperva пишет о всплеске активности против финансового сектора, медицины, ретейла и ИТ-компаний, прежде всего в США, а также в Сингапуре и Канаде.

При этом ни одна из компаний не раскрыла число атак, имена жертв или доказательства успешного захвата систем. То есть речь пока идёт о подтверждённой попытке эксплуатации, а не о массово задокументированной компрометации.

Для организаций риск вполне практический: под угрозой серверы, которые принимают JSON извне и используют уязвимую связку Fastjson и Spring Boot fat-JAR. Администраторам стоит проверить зависимые пакеты, логи на странные @type, неожиданные исходящие соединения, создание процессов и следы web shell.

Если у вас есть удалённые сотрудники и вы ищете дополнительный слой защиты для работы с банком или внутренними системами из чужой сети, подойдёт защищённый канал для удалённой работы. Но в случае с Fastjson главная задача другая — убрать уязвимую библиотеку или включить SafeMode.

Что делать сейчас

Alibaba пока не выпустила патч для ветки 1.x. Временное решение — включить SafeMode командой -Dfastjson.parser.safeMode=true или перейти на сборку com.alibaba:fastjson:1.2.83_noneautotype, если полная миграция сразу невозможна.

Долгосрочный путь — переход на Fastjson2. По словам разработчиков, новая ветка не использует тот же путь проверки ресурсов и не опирается на доверие к аннотациям так, как это делает 1.x.

Отдельно стоит проверить, нет ли в инфраструктуре старых зависимостей, которые тянут Fastjson транзитивно. В таких инцидентах именно забытая библиотека в глубине сборки часто становится точкой входа.

Чек-лист для администратора

  • Найти все сервисы, где используется Fastjson 1.x, включая транзитивные зависимости.
  • Проверить, есть ли в проде версии с 1.2.68 по 1.2.83.
  • Включить SafeMode, если миграция на новую версию займёт время.
  • Убедиться, что сервисы не принимают неожиданные JSON-объекты из внешней сети.
  • Просмотреть логи на @type, странные вложенные JAR-пути и нетипичные исходящие запросы.
  • Отследить запуск лишних процессов, изменения файлов и появление web shell.
  • Запланировать переход на Fastjson2 как основной вариант исправления.
  • Для удалённой работы сотрудников проверить отдельные каналы доступа к корпоративным ресурсам через защищённый канал для рабочей сети.
Поделиться: