• Node.js
• npm

Установка

[!NOTE] В package.json зафиксирована уязвимая версия 19.0.0.

Доказательство концепции

1. Запустите уязвимый сервер

Этот скрипт настраивает простой HTTP-сервер, использующий уязвимую среду выполнения React для декодирования запросов.

2. Запустите скрипт эксплойта

В отдельном терминале запустите эксплойт. Он отправляет вредоносную Flight-нагрузку на сервер.

Вы должны увидеть вывод команды в ответе:

Ожидаемый вывод:

Анализ

Почему возникла уязвимость?

Функция requireModule в ReactFlightDOMServerNode.js по сути просто доверяла любому name, отправленному клиентом. Она выполняла moduleExports[metadata[NAME]] без проверки, предназначено ли это свойство для раскрытия. Поэтому если клиент говорил «братан, я хочу это свойство», сервер просто отвечал «без проблем! держи, чувак».

Почему позволять доступ к любому свойству — плохая идея?

Потому что это, по сути, позволяет любому добраться до цепочки прототипов, включая constructor, что чрезвычайно опасно. Если модуль экспортирует функцию (например, module.exports = () => {}), то её constructor — это буквально глобальный конструктор Function.

Почему получение конструктора Function приводит к RCE?

Как только злоумышленник получает конструктор Function, он может злоупотребить функцией «Bound Server Action». Он привязывает строку, содержащую вредоносный JavaScript, к этому конструктору (фактически превращая его в new Function("вредоносный код")). И как только это выполняется, сервер выполняет любой код, который злоумышленник туда поместил.

Почему React вообще запустит эту вредоносную функцию?

Потому что Серверные действия можно вызывать по ID. Если злоумышленник создаёт нагрузку с Action ID, указывающим на их ссылку module#constructor, React разрешает её как обычное действие и выполняет. Это «действие» на самом деле является их вредоносной функцией.

Почему всё это не проверялось?

Система просто предполагала, что id и name из метаданных Server Reference всегда будут указывать на действительные экспорты, определённые разработчиком. Не было проверки безопасности, такой как hasOwnProperty, чтобы убедиться, что запрашиваемое свойство действительно является реальным экспортом, а не унаследовано от цепочки прототипов.

Почему server.js, а не Next.js?

Я использую чистый server.js (и вспомогательный webpack-runtime.js) для ручной настройки среды выполнения React Server Components. Это позволяет нам:

1. Принудительно настроить уязвимую конфигурацию: Эксплойт работает только если модуль экспортируется как функция (module.exports = fn). Настоящий сборщик может изменить способ обёртки экспортов в зависимости от своей конфигурации.
2. Изолировать ошибку: Это позволяет показать, что проблема находится внутри react-server-dom-webpack, а не в Next.js.
3. Воссоздать среду сборщика: react-server-dom-webpack предполагает, что он работает внутри сборки Webpack. Наш webpack-runtime.js предоставляет ему глобальные переменные, которые он ожидает (__webpack_require__, __webpack_chunk_load__). Это не имитация уязвимости, а просто предоставление библиотеке минимальной среды выполнения, необходимой для её работы.

Примечания

Были обсуждения о "Невалидных PoC", которые работают только если разработчик намеренно раскрывает опасные вещи, такие как child_process.exec.

Этот PoC не из таких. Он работает в обычной, безопасной настройке.

1. Экспонированная функция безвредна Приложение раскрывает простую функцию updateProfile, которая просто возвращает строку и ничего подозрительного, никаких shell-команд.

2. Эксплойт полностью обходит эту функцию Уязвимость позволяет атакующему игнорировать безопасный экспорт и перейти сразу к updateProfile.constructor, который является глобальным конструктором Function.

3. Основная проблема — доступ к свойству React НЕ ДОЛЖЕН был разрешать доступ к .constructor. Разработчик не намеревался раскрывать конструктор Function, вместо этого небезопасная десериализация сделала это за него.

Единственное реальное требование — чтобы модуль экспортировал функцию напрямую (module.exports = fn), что очень распространено в CommonJS и многих конфигурациях сборщиков.

Нагрузка

Нагрузка в exploit.js формирует React Flight-сообщение с тремя чанками:

• Чанк 0: Указывает на Server Reference, определённый в Чанке 1.
• Чанк 1: Объявляет Server Reference:
  • id: "user-profile-action#constructor", что означает «дай мне конструктор».
  • bound: указывает на Чанк 2, который содержит аргументы.
• Чанк 2: ["console.log('nice try, diddy!')"]: строка вредоносного кода.

Когда React десериализует это:

1. Он разрешает user-profile-action.
2. Читает свойство .constructor => получает глобальный Function.
3. Привязывает к нему предоставленную атакующим строку.
4. Фактически выполняет: new Function("console.log('nice try, diddy!')")

И это RCE!

Смягчение

Немедленно обновитесь до исправленных версий:

• react-server-dom-webpack >= 19.0.1
• react-server-dom-parcel >= 19.0.1
• react-server-dom-turbopack >= 19.0.1

Патч добавляет проверки hasOwnProperty для предотвращения доступа к унаследованным свойствам и ограничивает загрузку файлов base64.

Если вы запустите этот PoC против исправленной версии, сервер упадёт или выдаст ошибку:

Это подтверждает, что эксплойт не смог получить доступ к свойству constructor (оно вернуло undefined вместо Function), и поэтому последующий вызов .bind не удался.

Отказ от ответственности

Этот код предназначен только для образовательных целей и тестирования. Не используйте этот эксплойт против систем, которыми вы не владеете или на тестирование которых у вас нет явного разрешения.

Лицензия

Выпущено под DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE.