Fastjson 1.2.83 може викликати виконання віддаленого коду без використання традиційних gadget навіть за умови за замовчуванням AutoType=false, що було відтворено в середовищі ізоляції JDK 8/17/21/25 + Spring Boot Loader.

Автор статті, джерело: GCSA

Огляд

У традиційній системі захисту від вразливостей десеріалізації Java загальноприйнятими є такі міркування: «AutoType за замовчуванням вимкнений — це безпечно», «Фіксація другого параметра parseObject (тип верхнього рівня) — це безпечно», «Видалення залежностей Gadget десеріалізації з локального Classpath — це безпечно». Однак останні досягнення в технологіях атак та захисту повністю зруйнували ці ілюзії.

GCSA Global Cybersecurity Alliance сьогодні виключно публікує цей технічний аналітичний звіт. У звіті детально розглядається основна причина того, що Fastjson 1.2.83 у стані за замовчуванням AutoType=false все ще дозволяє виконувати віддалений код (RCE) без залежності від традиційних Gadget. Наразі ця експлуатаційна техніка була успішно повністю відтворена в середовищах JDK 8 / 17 / 21 / 25 та Spring Boot Loader ізоляції. Ця вразливість не є традиційним «обходом чорного списку з пошуком локальних Gadget», а натомість безпосередньо перетворює логіку виявлення метаданих класу Fastjson у канал отримання та авторизації віддалених шкідливих класів. Нижче наведено основний текст

Організація: GCSA Глобальний альянс кібербезпеки

Тип звіту: Ексклюзивні технічні інсайти / Глибокий аналіз вразливостей

Дата звіту: 2026-07-21

Статус звіту: аудит вихідного коду та відтворення в ізольованому середовищі завершено

Номер вразливості: внутрішній номер дослідження FJ-GETRESOURCE-RCE (не відповідає публічному CVE)

Fastjson 1.2.83 у випадку за замовчуванням AutoType=false все ще може спричинити виконання віддаленого коду без використання традиційних gadget, що було відтворено в середовищі JDK 8/17/21/25 + Spring Boot Loader. Рекомендується негайно увімкнути SafeMode та перейти на Fastjson 2.x.

1. Огляд

ParserConfig.checkAutoType у Fastjson 1.2.83 перетворює значення @type, що підконтрольні користувачу, на ім’я ресурсу класу та передає його getResourceAsStream поточного ClassLoader:

У середовищі ClassLoader fat-jar, здатному розбирати імена абсолютних URL-ресурсів, зловмисник може використовувати заміну крапками для створення URL-адрес http:, jar:http: та jar:file:, щоб завантажити зловмисний клас з анотацією @JSONType. Fastjson, виявивши цю анотацію, викликає loadClass і безпосередньо повертає клас до перевірки небезпечних базових класів та сумісності цільового типу. Під час інстанціювання та ініціалізації класу може бути виконано довільний код.

Ця експлуатація не залежить від вже наявних традиційних gadget-ів у classpath цілі і може бути викликана навіть за умови за замовчуванням Fastjson AutoType=false. Фіксований тип цілі для JSON.parseObject не може запобігти виконанню; увімкнення SafeMode може заблокувати нормальний шлях експлуатації до доступу до ресурсів.

Цей звіт було відтворено в ізольованому Linux-контейнері за допомогою того самого JSON-пейлоаду:

2. Оцінка вразливості

Не рекомендується надавати єдиний CVSS 9.8 лише на основі версії компонента: звичайний AppClassLoader є негативним контрольним прикладом, а сучасний ланцюжок JDK залежить від завантажувача, здатного розбирати обидва абсолютні URL JAR, і /proc/self/fd. У застосунках, що відповідають позитивному середовищу цього звіту, вразливість призводить до мережевого RCE без автентифікації.

3. Діапазон впливу та передумови

• Підтвердження виконання: Fastjson 1.2.83
• Підтвердження JDK: 8, 17, 21, 25
• Підтвердження операційної системи: Linux; на macOS також вдалося відтворити JDK 17/21/25 за допомогою /dev/fd
• loader підтверджено: Spring Boot 2.7.18 класичний loader + JDK 8; Spring Boot 3.2.0 loader + JDK 17/21/25
• Підтвердження API: JSON.parse та JSON.parseObject із фіксованим типом верхнього рівня

У зовнішньому описі 1.2.68–1.2.83 краще розглядати як відомий діапазон тестування, а не як версії, у яких було введено вразливість. Перевірка вихідного коду показує, що вирішальний код виявлення класових ресурсів уже існував у версіях 1.2.67 і 1.2.68. У цьому звіті повна перевірка через всі JDK середовища виконана лише для версії 1.2.83.

1. Зловмисник може керувати JSON, що надходить до Fastjson, і @type у вхідних даних буде розпарсено.

2. SafeMode не увімкнено.

3. ClassLoader Fastjson може розшифрувати згенероване абсолютне ім’я ресурсу як URL.

4. Захищений процес може підключитися до HTTP-сервісу атакувальника.

5. Сучасні вимоги до ланки Linux: /proc/self/fd має бути читабельним, а завантажувач повинен здати його розібрати

jar:file:/proc/self/fd/N!...

1. JDK повинен мати можливість створювати нормальний тимчасовий кеш віддалених JAR-файлів; це зазвичай означає, що тимчасова директорія JVM повинна бути доступна для запису.

Зловмиснику не потрібно:

• Запис файлу до цільового classpath
• Цільовий classpath передвстановлено з gadget: TemplatesImpl, JNDI, C3P0, Commons Collections
• Увімкнути Fastjson AutoType
• Контролюйте другий параметр JSON.parseObject

4. Аналіз кореневих причин

Розташування вихідного коду:

Основний код:

Ця логіка припускає, що resource — це звичайний шлях до classpath, але не обмежує його протокол, семантику абсолютних шляхів чи походження. Для конкретного завантажувача fat-jar наступні вхідні дані після заміни перетворються на абсолютні URL:

Тому getResourceAsStream завантажує мережеві ресурси, що підконтрольні зловмиснику, через виходження за межі локальних метаданих.

Fastjson використовує власний ASM ClassReader для аналізу вмісту ресурсів:

Атакуючий бік повинен лише надати віддаленому класу анотацію @JSONType Fastjson, щоб встановити jsonType на true. Тут перевіряються байти, надані атакуючим, а не клас, вже завантажений через довірений classpath.

Розташування вихідного коду:

TypeUtils.loadClass послідовно намагається використовувати явний завантажувач, завантажувач контексту потоку та Class.forName. У прямому середовищі завантажувач контексту потоку знову розбирає той самий абсолютний ім'я ресурсу, завантажує клас і виконує defineClass.

Розташування вихідного коду:

• Перевірка небезпечного базового класу не виконується
• expectClass.isAssignableFrom(clazz) не виконуватиметься
• Тип прив’язки фіксованих даних не може перешкоджати виконанню до ініціалізації класу

Розташування вихідного коду:

Перевірка SafeMode виконується перед доступом до ресурсу:

5. Детальний розбір ланцюга

Найкоротша форма:

JDK 17+ також виконуватиме мережеві запити, але відмовлятиметься від порожніх сегментів шляху в іменах,

Перший елемент масиву однієї вантажної частини:

JDK 17+ пізніше відмовився від першої фази jar:http://... внутрішніх імен, але Fastjson продовжив аналіз масиву через суфікс Exception.

Наступні кандидати:

Першим збігом у журналі завантаження класів JDK 17 є:

• JDK 8 безпосередньо приймає jar-файл першого етапу: http://... class і виконує його
• Після виконання команди class першого етапу намагається намагається викинути RuntimeException("stage-one-stop"), щоб запобігти JDK 8 продовжувати спроби з невідповідними socket/pipe FD
• JDK 17+ зазнає невдачі на першому етапі через неправильну назву перед ініціалізацією класу, а потім м’яко повертається через виняток до етапу перерахування FD

6. Середовище та докази

Очікуваний вивід:Скрипт буде:

• Збірка пошкодженого fat jar;
• Створити атакувальний JAR із FD-специфічним класом;
• Створіть JSON-масив payload;
• Запустити HTTP-сервіс атакуючого в ізольованій Docker-мережі;
• Запустіть контейнери з JDK 8/17/21/25;
• Перевірте кожен контейнер, що зіставлений з /tmp/fastjson-getresource-rce.

Burp відповідає лише за надсилання JSON до вразливих інтерфейсів з точками розбору Fastjson; атакуючий JAR повинен надаватися HTTP-сервісом атакуючого.

Шаблон запиту:

Якщо додаток використовує фіксований верхній тип, масив можна обгорнути за структурою поля, наприклад:

У цьому експерименті використовується JSON.parseObject(json, BoundEnvelope.class) для розбору вищезазначеного обгортання, результат залишається RCE-OK і повертає BoundEnvelope.

Пріоритетом є міграція на підтримувану версію Fastjson 2.x і повторна перевірка всіх конфігурацій поліморфних типів, AutoType та режиму сумісності. Не обмежуйтесь заміною JAR-файлу без регресійного тестування.

Конфігурація коду:

Параметри JVM:

Увага: Якщо додаток зареєстрував AutoTypeCheckHandler, його слід синхронно перевірити або видалити, оскільки обробник виконується до перевірки SafeMode.

• Не передавайте ненадійні запити безпосередньо JSON.parse/JSON.parseObject
• Відмовляйтеся від будь-яких спеціальних типів метаданих на шлюзі або в точці входу додатка.
• Тільки фіксація верхнього рівня типів Java не є достатнім захистом, оскільки вкладені об’єкти все ще можуть обробляти @type, а перевірка сумісності для jsonType цієї вразливості обходиться раннім поверненням

Тимчасово блокуйте запити, у яких після розшифрування ключа JSON дорівнює @type, і перезаписуйте параметри URL, тіло запиту та вкладені об’єкти. Не шукайте лише текстовий рядок "@type", оскільки Fastjson lexer спочатку розшифровує імена полів, наприклад:

Правила WAF можуть використовуватися лише як засіб зменшення ризиків, але не замінюють оновлення компонентів та SafeMode.

1. Заборонити JVM виконувати HTTP/HTTPS-з’єднання з необов’язковими зовнішніми адресами.
2. Застосуйте мінімальні мережеві політики до контейнерів додатків.
3. Обмежте використання або відображення /proc/self/fd, коли це дозволено сумісністю, або використовуйте більш строгу контейнерну пісочницю.
4. Перевірте обробку ClassLoader абсолютних URL-імен ресурсів, відмовляючись від протоколів, таких як http:, https:, jar:, file:.
5. Спостерігайте за незвичайною активністю jar_cache* у тимчасовому каталозі JVM.

8. Рекомендації щодо виявлення та IOC

Зверніть увагу на розкодовані значення @type, які містять:

Окремо виникнення Exception недостатньо для сповіщення, його слід аналізувати разом із форматом протоколу, @type та послідовними FD-кандидатами в масиві.

• JVM запитує у неправильного хоста JAR або .class без розширення
• Під час одного запиту аналізу відбувається 1–3 повторення GET/HEAD
• У шляху запиту можуть зустрічатися /x, /a.class або користувацькі еквівалентні шляхи, визначені зловмисником

• Створення тимчасового каталогу JVM jar_cache*
• Процес Java відкриває власний файл через /proc/self/fd/N
• У журналі class-load з’являються подібні записи:

9. Висновок

Ця вразливість не є традиційним «обходом чорного списку з використанням локальних gadget», а перетворює логіку виявлення метаданих класів Fastjson у віддалений канал отримання класів та авторизації. Раннє повернення @JSONType дозволяє приймати класи, надані зловмисником, до перевірки небезпечних базових класів і прив’язки типів; м’який канал помилок Exception та тимчасовий кеш JDK jar:http: розширюють прямі примітиви завантаження JDK 8 до JDK 17/21/25.

Тому наступні поширені припущення не є дійсними:

• «AutoType за замовчуванням вимкнений, тому безпечно» — не вірно
• «Фіксація другого параметра parseObject, тому безпечно» — не вірно
• Класpath не має відомих gadget, тому безпечний” — це неправда
• JKD 17+ відмовлятиметься від внутрішніх імен http://, тому це може бути лише SSRF” — неправильно



У розгортаннях, що задовольняють умови перевіреного завантажувача, мережі та дескрипторів файлів, ця проблема може розгорнутися з одного неперевіреного JSON-запиту до реального виконання віддаленого коду. Слід пріоритетно перейти на Fastjson 2.x та негайно увімкнути SafeMode, а також вузько обмежити вихідний трафік і межі розбору ресурсів ClassLoader.

10. Шлях до додатків та доказів

Підпис та авторські права: Цей звіт та відповідний технічний аналіз виключно опубліковані GCSA — Глобальним альянсом кібербезпеки. При копіюванні обов’язково зберігайте офіційне посилання GCSA та початкове посилання, а також не змінюйте основні висновки звіту з недобросовісними цілями.

Джерело: GCSA Глобальний альянс кібербезпеки

Офіційний сайт: www.gcsa.org