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

Автор статьи, источник: GCSA

Краткое содержание

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

GCSA Global Cybersecurity Alliance сегодня исключительно публикует этот технический аналитический отчет. Отчет детально анализирует корневую причину удаленного выполнения кода (RCE), которая все еще может быть вызвана в Fastjson 1.2.83 при состоянии AutoType=false без зависимости от традиционных 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 и сразу возвращает класс до проверки на опасные базовые классы и совместимости целевого типа. При инстанциации и инициализации класса выполняется произвольный код.

Этот эксплойт не зависит от существующих традиционных гаджетов десериализации в classpath цели и может быть запущен даже при стандартном состоянии Fastjson AutoType=false. Фиксация целевого типа для JSON.parseObject не препятствует выполнению; включение SafeMode может заблокировать стандартный путь эксплуатации до доступа к ресурсам.

Этот отчет был воспроизведен в изолированном Linux-контейнере с использованием того же JSON-заголовка:

2. Оценка уязвимости

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

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. Классовый загрузчик 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) не будет выполнен
• Fixed data binding type cannot prevent execution before class initialization

Расположение исходного кода:

Проверка SafeMode осуществляется перед доступом к ресурсу:

5. Подробное объяснение цепочки

Краткая форма:

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

Первый элемент массива в одиночном payload:

JDK 17+ позже отказался от первого этапа jar:http://... внутреннего имени, но Fastjson продолжил анализ массива из-за суффикса Exception.

Последующие кандидаты:

Первое совпадение в журнале загрузки классов JDK 17:

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

6. Среда воспроизведения и доказательства

Ожидаемый вывод:Скрипт будет:

• Соберите жирный 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 сначала декодирует имена полей, например:

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 делает это безопасным» — неверно
• Класспах не имеет известных гаджетов, поэтому безопасно — неверно
• JKD 17+ отклоняет внутренние имена с http://, поэтому это максимум SSRF» — неверно



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

10. Путь к вложениям и доказательствам

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

Источник: GCSA Global Cyber Security Alliance

Официальный сайт: www.gcsa.org