Хакеры начали атаковать критическую уязвимость CVE-2026-16723 в Java-библиотеке Fastjson. Ошибка получила 9,0 балла по CVSS и позволяет удалённо выполнить код на сервере без аутентификации и без участия пользователя.

Проблема затрагивает Fastjson версий с 1.2.68 по 1.2.83 в Spring Boot-приложениях, собранных в исполняемые fat JAR. Разработчики Alibaba выпустили Fastjson 1.2.84 29 июля 2026 года, а аналитики ThreatBook и Imperva уже сообщили о реальных попытках эксплуатации.

Какую проблему решаем

Если у вас есть Java-сервис на Fastjson, задача простая: понять, попадает ли он в зону риска и можно ли быстро закрыть дыру. Для атакующую сторону достаточно сетевой точки входа, которая принимает JSON и передаёт его библиотеке.

Проблема особенно неприятна тем, что SafeMode в типовой конфигурации выключен, а AutoType включать не нужно. Это значит, что многие старые схемы проверки безопасности тут не спасают.

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

Что подготовить

Сначала соберите минимум информации о приложении. Нужны версия Fastjson, способ сборки, список публичных точек входа и понимание, обрабатывает ли сервис JSON от внешних клиентов.

Дальше проверьте, не использует ли проект одну из уязвимых версий — с 1.2.68 по 1.2.83. Отдельно стоит посмотреть, не развёрнут ли сервис как fat JAR и не включён ли SafeMode.

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

Пошаговые действия

Шаг первый — найдите все экземпляры Fastjson. Проверьте зависимости в основном приложении и во вспомогательных сервисах. Уязвимость может сидеть не только в главном сервере, но и в отдельном модуле, который принимает JSON.

Шаг второй — обновите библиотеку до 1.2.84. Это основной и самый надёжный вариант. Разработчики закрыли проблему, усилили проверки allowlist и убрали возможность вытащить запрещённый класс из кеша.

Шаг третий — если обновление откладывается, включите SafeMode. Alibaba советует задать параметр -Dfastjson.parser.safeMode=true. Это временная мера, но она лучше, чем оставлять сервис открытым.

Шаг четвёртый — переходите на 1.2.83_noneautotype, если патч пока не ставится. Эта сборка подходит как промежуточный вариант. Но держать её долго не стоит: патч 1.2.84 всё равно нужен.

Шаг пятый — пересмотрите приём JSON от внешних источников. Особенно внимательно проверьте поля Object и Map, потому что именно там вредоносный пейлоад может прятаться незаметно для простых фильтров. Не полагайтесь на то, что привязка входных данных к заранее заданному классу всё решает.

Похожая логика уже подводила админов и в других инцидентах: старый компонент, внешняя точка входа и ощущение, что «у нас всё и так закрыто». Именно так развиваются многие атаки, о которых мы писали в материале о выходе ИИ-агентов из песочницы.

Как проверить себя

Самый простой тест — найти точную версию Fastjson в зависимостях и сравнить её с диапазоном риска. Если у вас 1.2.68–1.2.83, обновление нельзя откладывать.

Затем проверьте конфигурацию запуска: включён ли SafeMode, есть ли внешние JSON-эндпоинты, не принимает ли сервис данные от непроверенных клиентов. Если приложение работает в продакшене, посмотрите журналы на странные запросы, похожие на попытки подбора payload’ов.

Ещё один признак — неожиданные ошибки в разборе JSON и всплеск запросов к одному и тому же API без нормальной пользовательской активности. По данным ThreatBook и Imperva, атакующие часто используют инструменты, которые маскируются под обычные браузеры.

Что делать, если не получилось

Если обновление прямо сейчас невозможно, включите SafeMode и сократите поверхность атаки: закройте лишние публичные эндпоинты, ограничьте доступ по сети, уберите обработку JSON там, где она не нужна. Это не заменяет патч, но снижает риск.

Если сервис критичен для бизнеса, вынесите его в приоритетный список на обновление. В таких инцидентах промедление редко заканчивается хорошо: уязвимость уже получила публичную огласку, а атаки пошли вживую.

Практический чек-лист

  • Проверить, используется ли Fastjson в продукте и во вспомогательных сервисах.
  • Сверить версию: риск касается 1.2.68–1.2.83.
  • Обновить библиотеку до 1.2.84.
  • Если обновление затягивается, включить -Dfastjson.parser.safeMode=true.
  • Рассмотреть переход на 1.2.83_noneautotype как временную меру.
  • Проверить внешние JSON-эндпоинты и убрать лишние точки входа.
  • Просмотреть журналы на подозрительные запросы и ошибки парсинга.
  • Запланировать миграцию на Fastjson2, если проект ещё на старой ветке.
Поделиться: