Библиотека Fastjson от Alibaba — штука, которую используют тысячи Java-проектов для работы с JSON. И вот в ней нашли дырку, которая получила номер CVE-2026-16723 и оценку 9.0 по шкале CVSS — оценку выставила сама Alibaba, что уже показатель серьёзности. Речь о неаутентифицированном удалённом выполнении кода: атакующий может выполнить произвольный код с теми же правами, что имеет сам Java-процесс. Никакого пароля, никакой авторизации — достаточно отправить специально сформированный JSON туда, куда его примет уязвимый парсер.
О проблеме заговорили сразу несколько источников. Компания ThreatBook сообщила, что эксплуатация уже фиксируется в реальном мире, а не только в лабораторных условиях. Imperva подтвердила активность атак и рассказала, кого именно бьют. А исследователь по фамилии Фирсов (Firsov) разобрался в технической начинке бага и объяснил, откуда растут корни проблемы.
Чтобы атака сработала, нужно совпадение нескольких факторов. Во-первых, версия Fastjson должна быть в диапазоне от 1.2.68 до 1.2.83. Во-вторых, приложение должно быть развёрнуто как исполняемый fat-JAR на Spring Boot — то есть весь набор зависимостей упакован в один файл. В-третьих, должен существовать сетевой путь, по которому атакующий может передать вредоносный JSON уязвимому парсеру. И наконец, режим SafeMode должен оставаться в отключённом состоянии — а это, что важно, состояние по умолчанию. Отдельно стоит отметить: AutoType при этом может быть выключен, а гаджет из classpath вообще не требуется — раньше именно на этом строились классические атаки на Fastjson.
Фирсов проследил проблему до механизма разрешения типов внутри библиотеки. Значение поля @type, которое контролирует атакующий, превращается в запрос на поиск ресурса класса. Если приложение упаковано в fat-JAR совместимой сборки Spring Boot, специально сформированный вложенный путь внутри JAR-архива позволяет получить байткод, который контролирует злоумышленник. А дальше происходит любопытная штука: аннотация @JSONType в этом ресурсе воспринимается библиотекой как «сигнал доверия» — и класс проскакивает мимо проверок типов Fastjson и загружается. Отдельно обнаружен путь для более новых версий JDK: там загружается удалённый JAR-файл, а обращение к нему идёт через /proc/self/fd.
Тестирование проводилось на широком наборе окружений — версии Spring Boot 2.x, 3.x и 4.x, версии JDK 8, 11, 17 и 21. При этом Alibaba уточняет: уязвимы именно исполняемые fat-JAR на Spring Boot. Обычные не-fat JAR-файлы, generic uber-JAR-сборки и развёртывания через WAR на Tomcat или Jetty под удар не попадают.
С точки зрения кода уязвимыми точками входа названы методы JSON.parse, JSON.parseObject(String) и JSON.parseObject(String, Class). Здесь есть важная оговорка: даже если разработчик привязывает входные данные к конкретному фиксированному классу, это не спасает — если внутри объекта есть поле типа Object или Map, туда можно вложить payload, и защита не сработает.
Хронология развития событий такая: около 20 июля ThreatBook добавила детектирование этой угрозы в свои продукты. 22 июля компания сообщила, что её платформа зафиксировала реальную эксплуатацию в дикой природе. 23 июля оценка CISA-ADP неожиданно показала статус эксплуатации «отсутствует». А к 25 июля ситуация выглядела так: Alibaba так и не выпустила исправленную версию Fastjson 1.x, издание The Hacker News подтвердило, что уязвимость отсутствует в каталоге известных эксплуатируемых уязвимостей CISA (KEV), а исправленного артефакта Fastjson 1.x не нашлось ни в тегах на GitHub, ни в Maven Central.
Собственные лабораторные тесты ThreatBook дали более узкую картину, чем изначально прозвучало в заявлениях. Полное выполнение кода воспроизвели только на Spring Boot fat-JAR под JDK 8. А вот при тестировании со встроенным Tomcat результат оказался слабее — получилось добиться лишь загрузки удалённого JAR-файла или SSRF (Server-Side Request Forgery), но не полноценного RCE.
Imperva описала географию и отраслевую специфику атак. Под прицелом оказались финансовые организации, здравоохранение, компании из сферы вычислительных технологий, ритейл и ряд других организаций. Географически основная нагрузка приходится на США, меньшие объёмы зафиксированы в Сингапуре и Канаде. Что касается инструментов атакующих — большинство запросов шло через программы, маскирующиеся под браузеры, а примерно 30% суммарно пришлось на инструменты, написанные на Ruby и Go.
При этом ни одна из компаний не раскрыла конкретные цифры: сколько всего атак зафиксировано, какие именно запросы отправлялись, есть ли доказательства успешного выполнения кода, названия пострадавших организаций или подтверждённые случаи компрометации. Отчёты фиксируют факт наблюдаемой попытки эксплуатации — но это не равно доказательству того, что код реально выполнился или что произошёл взлом. Отдельно бросается в глаза нестыковка: CISA-ADP оценила статус эксплуатации как «отсутствует», тогда как поставщики систем безопасности сообщают об активной эксплуатации в реальном времени. Источники это противоречие никак не объясняют.
По состоянию на 25 июля официального патча для Fastjson 1.x так и не существует. Последним стандартным релизом линейки 1.x остаётся версия 1.2.83 — и она же остаётся уязвимой. Из альтернатив доступна ограниченная сборка :fastjson:1.2.83_noneautotype.
Организациям, которые пока не могут перейти на другую библиотеку, рекомендуется включить SafeMode через параметр -Dfastjson.parser.safeMode=true либо перейти на упомянутую сборку с суффиксом noneautotype. В долгосрочной перспективе сама Alibaba советует мигрировать на Fastjson2 — новую версию библиотеки, которая этой проблеме не подвержена, поскольку не использует ни механизм прощупывания ресурсов, ни путь доверия через аннотации. Для обнаружения и инвентаризации риска специалистам советуют проверить прямые и транзитивные зависимости от Fastjson в своих проектах, а также искать подозрительные значения @type, вложенные пути JAR-архивов, неожиданные исходящие соединения, необычные дочерние процессы, изменения файлов и веб-шеллы.
Есть здесь и своя горькая ирония. В 2022 году именно версия 1.2.83 была той самой рекомендованной Alibaba обновой, которая закрывала другую, отдельную уязвимость, связанную с обходом механизма AutoType. Теперь тот же самый финальный релиз линейки 1.x попадает в диапазон версий, затронутых новой CVE-2026-16723. The Hacker News направила запросы в Alibaba — с просьбой уточнить список затронутых версий и планы по выпуску патча для Fastjson 1.x, а также в Imperva — за деталями зафиксированной активности атак. Ответов на момент публикации не поступило.
О проблеме заговорили сразу несколько источников. Компания ThreatBook сообщила, что эксплуатация уже фиксируется в реальном мире, а не только в лабораторных условиях. Imperva подтвердила активность атак и рассказала, кого именно бьют. А исследователь по фамилии Фирсов (Firsov) разобрался в технической начинке бага и объяснил, откуда растут корни проблемы.
Чтобы атака сработала, нужно совпадение нескольких факторов. Во-первых, версия Fastjson должна быть в диапазоне от 1.2.68 до 1.2.83. Во-вторых, приложение должно быть развёрнуто как исполняемый fat-JAR на Spring Boot — то есть весь набор зависимостей упакован в один файл. В-третьих, должен существовать сетевой путь, по которому атакующий может передать вредоносный JSON уязвимому парсеру. И наконец, режим SafeMode должен оставаться в отключённом состоянии — а это, что важно, состояние по умолчанию. Отдельно стоит отметить: AutoType при этом может быть выключен, а гаджет из classpath вообще не требуется — раньше именно на этом строились классические атаки на Fastjson.
Фирсов проследил проблему до механизма разрешения типов внутри библиотеки. Значение поля @type, которое контролирует атакующий, превращается в запрос на поиск ресурса класса. Если приложение упаковано в fat-JAR совместимой сборки Spring Boot, специально сформированный вложенный путь внутри JAR-архива позволяет получить байткод, который контролирует злоумышленник. А дальше происходит любопытная штука: аннотация @JSONType в этом ресурсе воспринимается библиотекой как «сигнал доверия» — и класс проскакивает мимо проверок типов Fastjson и загружается. Отдельно обнаружен путь для более новых версий JDK: там загружается удалённый JAR-файл, а обращение к нему идёт через /proc/self/fd.
Тестирование проводилось на широком наборе окружений — версии Spring Boot 2.x, 3.x и 4.x, версии JDK 8, 11, 17 и 21. При этом Alibaba уточняет: уязвимы именно исполняемые fat-JAR на Spring Boot. Обычные не-fat JAR-файлы, generic uber-JAR-сборки и развёртывания через WAR на Tomcat или Jetty под удар не попадают.
С точки зрения кода уязвимыми точками входа названы методы JSON.parse, JSON.parseObject(String) и JSON.parseObject(String, Class). Здесь есть важная оговорка: даже если разработчик привязывает входные данные к конкретному фиксированному классу, это не спасает — если внутри объекта есть поле типа Object или Map, туда можно вложить payload, и защита не сработает.
Хронология развития событий такая: около 20 июля ThreatBook добавила детектирование этой угрозы в свои продукты. 22 июля компания сообщила, что её платформа зафиксировала реальную эксплуатацию в дикой природе. 23 июля оценка CISA-ADP неожиданно показала статус эксплуатации «отсутствует». А к 25 июля ситуация выглядела так: Alibaba так и не выпустила исправленную версию Fastjson 1.x, издание The Hacker News подтвердило, что уязвимость отсутствует в каталоге известных эксплуатируемых уязвимостей CISA (KEV), а исправленного артефакта Fastjson 1.x не нашлось ни в тегах на GitHub, ни в Maven Central.
Собственные лабораторные тесты ThreatBook дали более узкую картину, чем изначально прозвучало в заявлениях. Полное выполнение кода воспроизвели только на Spring Boot fat-JAR под JDK 8. А вот при тестировании со встроенным Tomcat результат оказался слабее — получилось добиться лишь загрузки удалённого JAR-файла или SSRF (Server-Side Request Forgery), но не полноценного RCE.
Imperva описала географию и отраслевую специфику атак. Под прицелом оказались финансовые организации, здравоохранение, компании из сферы вычислительных технологий, ритейл и ряд других организаций. Географически основная нагрузка приходится на США, меньшие объёмы зафиксированы в Сингапуре и Канаде. Что касается инструментов атакующих — большинство запросов шло через программы, маскирующиеся под браузеры, а примерно 30% суммарно пришлось на инструменты, написанные на Ruby и Go.
При этом ни одна из компаний не раскрыла конкретные цифры: сколько всего атак зафиксировано, какие именно запросы отправлялись, есть ли доказательства успешного выполнения кода, названия пострадавших организаций или подтверждённые случаи компрометации. Отчёты фиксируют факт наблюдаемой попытки эксплуатации — но это не равно доказательству того, что код реально выполнился или что произошёл взлом. Отдельно бросается в глаза нестыковка: CISA-ADP оценила статус эксплуатации как «отсутствует», тогда как поставщики систем безопасности сообщают об активной эксплуатации в реальном времени. Источники это противоречие никак не объясняют.
По состоянию на 25 июля официального патча для Fastjson 1.x так и не существует. Последним стандартным релизом линейки 1.x остаётся версия 1.2.83 — и она же остаётся уязвимой. Из альтернатив доступна ограниченная сборка :fastjson:1.2.83_noneautotype.
Организациям, которые пока не могут перейти на другую библиотеку, рекомендуется включить SafeMode через параметр -Dfastjson.parser.safeMode=true либо перейти на упомянутую сборку с суффиксом noneautotype. В долгосрочной перспективе сама Alibaba советует мигрировать на Fastjson2 — новую версию библиотеки, которая этой проблеме не подвержена, поскольку не использует ни механизм прощупывания ресурсов, ни путь доверия через аннотации. Для обнаружения и инвентаризации риска специалистам советуют проверить прямые и транзитивные зависимости от Fastjson в своих проектах, а также искать подозрительные значения @type, вложенные пути JAR-архивов, неожиданные исходящие соединения, необычные дочерние процессы, изменения файлов и веб-шеллы.
Есть здесь и своя горькая ирония. В 2022 году именно версия 1.2.83 была той самой рекомендованной Alibaba обновой, которая закрывала другую, отдельную уязвимость, связанную с обходом механизма AutoType. Теперь тот же самый финальный релиз линейки 1.x попадает в диапазон версий, затронутых новой CVE-2026-16723. The Hacker News направила запросы в Alibaba — с просьбой уточнить список затронутых версий и планы по выпуску патча для Fastjson 1.x, а также в Imperva — за деталями зафиксированной активности атак. Ответов на момент публикации не поступило.
