Fastjson CVE-2026-16723: увімкніть SafeMode у 1.x

Fastjson CVE-2026-16723 дає змогу віддалено виконувати код без автентифікації у поширеній, але конкретній конфігурації Spring Boot. Розробники бібліотеки вказують як уразливі Fastjson від 1.2.68 до 1.2.83, якщо застосунок працює як executable fat JAR, обробляє контрольований зловмисником JSON, а SafeMode вимкнено — це стандартне налаштування [1].

ThreatBook повідомляє, що її платформа зафіксувала спроби експлуатації, а Imperva окремо спостерігала атаки на організації з кількох галузей. Це підстава для термінової перевірки, але не доказ того, що кожен запит завершився виконанням коду чи зламом. Практичне завдання — підтвердити всі умови ризику, негайно ввімкнути SafeMode та відмовитися від непідтримуваної гілки 1.x.

Кого стосується CVE-2026-16723?

Ланцюжок перевірено на Spring Boot 2.x, 3.x і 4.x з JDK 8, 11, 17 та 21. Прив’язка JSON до конкретного класу не є достатнім захистом, якщо об’єкт містить поле типу Object або Map, куди можна вкласти шкідливе значення.

Чому вимкнений AutoType не захищає

Fastjson використовує поле @type для поліморфної десеріалізації. У цьому ланцюжку контрольоване зловмисником значення типу доходить до пошуку ресурсу всередині Spring Boot fat JAR. Спеціально сформований шлях до вкладеного JAR може підвантажити сторонній bytecode, а анотація @JSONType — спрацювати як сигнал довіри. Разом ці механізми обходять захист, на який адміністратори розраховують після вимкнення AutoType.

Fastjson2 не має такого самого шляху resource probing та annotation trust. У ній діє allowlist-first model, тому розробники виключають усі версії fastjson2 зі сфери CVE-2026-16723.

Як перевірити ризик без запуску експлойта

1. Знайдіть прямі й транзитивні залежності. Перевіряйте build і фактично розгорнутий artifact, а не лише верхній рівень pom.xml. Для Maven команда mvn dependency:tree -Dincludes=com.alibaba:fastjson допоможе знайти транзитивну копію; для Gradle перегляньте runtime dependency report і lockfiles.
2. Підтвердьте, який файл реально запущено. Перевірте container image, service command і deployed JAR. Spring Boot archive з каталогом BOOT-INF/ та вкладеними бібліотеками потребує першочергової уваги.
3. Знайдіть реальні parser entry points. Перегляньте виклики JSON.parse, JSON.parseObject(String) і JSON.parseObject(String, Class) та встановіть, чи може до них дійти неавтентифікований або інтернет-доступний запит.
4. Перевірте SafeMode у runtime. Звірте JVM arguments, fastjson.properties та ініціалізацію застосунку. Налаштування в репозиторії ще не доводить, що воно потрапило у production process.
5. Шукайте сліди безпечно. Перевірте підозрілі значення @type, nested JAR URL patterns, неочікувані outbound connections, дочірні процеси Java, нові файли та web shells. Не надсилайте proof-of-concept запит у production.

Перевірка залежностей важлива, бо Java-застосунок часто успадковує ризик. Аналіз транзитивних залежностей Log4j показав, чому уразливий код довго залишається у package graph. Подібна логіка діє й в інших екосистемах: після компрометації пакета Jscrambler перевіряти потрібно було не лише manifest, а й lockfile та фактичне виконання.

Що зробити зараз

1. Негайно ввімкніть SafeMode. Використайте JVM option -Dfastjson.parser.safeMode=true, додайте fastjson.parser.safeMode=true до properties або викличте ParserConfig.getGlobalInstance().setSafeMode(true). Потім підтвердьте значення у запущеному сервісі.
2. Якщо міграція не почнеться сьогодні, використайте restricted build. Розробники пропонують com.alibaba:fastjson:1.2.83_noneautotype, де пов’язаний з AutoType уразливий код прибрано під час компіляції.
3. Сплануйте й протестуйте перехід на fastjson2. SafeMode та WAF rules лише тимчасово знижують ризик і не замінюють виправлену гілку 1.x, якої немає. Перед production rollout перевірте сумісність serialization behavior та package names.
4. Обмежте доступність. Додайте автентифікацію, де це можливо, закрийте непотрібні публічні parser endpoints і блокуйте підозрілі @type та nested-JAR URL patterns на WAF або API gateway. Perimeter filtering не замінює міграцію.
5. Розслідуйте підозрілі хости. Збережіть application, proxy, WAF, container та egress logs. Якщо процес Java запускав команди, завантажував ресурси, створював невідомі файли або відкривав secrets, ізолюйте workload і після containment змініть credentials.

Що доводять повідомлення про експлуатацію?

ThreatBook заявляє, що її detection platform зафіксувала експлуатацію в реальних атаках і відтворила повний RCE у Spring Boot fat JAR на JDK 8. У тесті з embedded Tomcat дослідники отримали remote JAR fetch або SSRF, але не повне виконання коду [2]. Ця різниця ще раз показує, чому спосіб пакування й runtime conditions потрібно перевіряти окремо.

Станом на 26 липня CVE-2026-16723 немає у CISA Known Exploited Vulnerabilities. Запис NVD містить оцінку CISA-ADP від 23 липня зі значенням exploitation none, що не збігається з пізнішими заявами постачальників telemetry [3]. Обережний висновок: спроби експлуатації спостерігали, але публічних доказів успішного масового компрометування поки мало. Усунути ризик потрібно зараз, не називаючи неперевірені запити підтвердженими зламами.

Джерела

1. Розробники Alibaba Fastjson. “Security Advisory: Remote Code Execution in fastjson 1.2.68–1.2.83.” GitHub, 21 липня 2026 року, дата доступу 26 липня 2026 року. Офіційний advisory.
2. ThreatBook Research Team. “Fastjson RCE (≤1.2.83): Active Exploitation Detected — Detection & Mitigation.” ThreatBook, 22 липня 2026 року, дата доступу 26 липня 2026 року. Звіт дослідників.
3. National Institute of Standards and Technology. “CVE-2026-16723 Detail.” National Vulnerability Database, опубліковано 23 липня 2026 року, дата доступу 26 липня 2026 року. Запис CVE.