1. Обзор уязвимости

В последние два дня React уязвимость RCE из-за десериализации нашумела, официальный CVSS сразу выставил 10.0 баллов, наравне с Log4j в своё время. Сразу же появились слухи, что это современный Log4j для фронтенда, что вызвало панику у многих разработчиков компаний, и все, проснувшись, начали штудировать документацию и ставить патчи... В то же время в сети появилось немало сомнений, некоторые после тестирования обнаружили, что уязвимость не так серьезна, как рекламируется, наоборот, для её эксплуатации требуются определённые условия. Поэтому я решил выделить время и глубоко изучить эту уязвимость.

1.1 Информация об уязвимости

• CVE ID: CVE-2025-55182
• CVSS Score: 10.0 (Critical)
• Тип уязвимости: Загрязнение прототипа → Удаленное выполнение кода
• Затронутые версии: react-server-dom-webpack < 19.2.0, react-server-dom-turbopack < 19.2.0
• Сфера влияния: Приложения, использующие React Server Components

---

2. Анализ принципа уязвимости

2.1 Основная причина уязвимости

Причина возникновения данной уязвимости следующая: в [email protected] ключевая функция для парсинга Server Action на сервере — requireModule (псевдокод):

function requireModule(metadata) {
  var moduleExports = __webpack_require__(metadata[0]);
  // ...
  return "*" === metadata[2]
    ? moduleExports
    : "" === metadata[2]
      ? moduleExports.__esModule
        ? moduleExports.default
        : moduleExports
      : moduleExports[metadata[2]];  // ← Точка уязвимости
}

2.2 Основная проблема уязвимости

Основная проблема заключается в части moduleExports[metadata[2]]: отсутствует проверка metadata[2], что позволяет атакующему получать доступ не только к собственным экспортируемым свойствам модуля, но и к свойствам цепочки прототипов (например, constructor, __proto__ и т.д.). Когда атакующий конструирует metadata[0] (например, указывая на vm), он может снова сконструировать metadata[2], тем самым экспортировать опасные методы из указанного модуля, например, vm.runInThisContext, что приводит к эксплуатации уязвимости.

---

3. Анализ эксплуатации уязвимости

При анализе я обращался к тестовой среде и эксплуатации, предоставленным ejpir, и в качестве примера использовал gadget vm_runInThisContext для Code Execution. Процесс описан ниже (обратите внимание: в реальной среде процесс эксплуатации может отличаться!).

Шаг 1: Получение запроса

Сначала после отправки запроса с полезной нагрузкой ставим точку останова на месте получения запроса:

Шаг 2: Парсинг данных формы

Затем программа доходит до const formData = parseMultipart(buffer, boundaryMatch[1]);, заходим в parseMultipart

parseMultipart извлекает данные тела запроса и возвращает их в formData

Шаг 3: Вызов decodeAction (вход в уязвимость)

Заходим в const actionFn = await decodeAction(formData, serverManifest); Место возникновения уязвимости

Заходим в loadServerReference

Шаг 4: Основной код уязвимости requireModule

Теперь дошли до ключевого места кода уязвимости requireModule, заходим

Возвращает значение id, разделённое символом #, как метод модуля, и значение параметра bound как аргумент метода

Шаг 5: Выполнение полезной нагрузки

Заходим в actionFn, выполняем финальную полезную нагрузку

На этом эксплуатация уязвимости завершена!

---

4. Резюме и защита

Эта уязвимость, по сути, также вызвана недостаточно строгой проверкой входных данных — так же, как и в случае с Log4j и fastjson. Я тестировал vm_runInThisContext, но на самом деле у этой уязвимости есть несколько доступных гаджетов, например:

• vm#runInThisContext
• vm#runInNewContext
• child_process#execSync
• child_process#execFileSync
• child_process#spawnSync
• fs#readFileSync
• fs#writeFileSync
• #constructor
• #__proto__
• #prototype

Атакующий может использовать эту уязвимость для:

• Удаленного выполнения кода (RCE): через vm#runInThisContext или child_process#execSync выполнять произвольные системные команды
• Операций с файловой системой: через fs#readFileSync, fs#writeFileSync читать/записывать произвольные файлы
• Постоянных атак: запись открытых ключей SSH, изменение .bashrc, перезапись файлов приложения и т.д.
• Утечки информации: чтение конфиденциальных конфигурационных файлов (.env, закрытые ключи, учетные данные базы данных и т.д.)

Исходя из этого, можно дать следующие меры защиты:

1. Временная защита

В качестве временной защиты можно настроить на WAF правила блокировки опасных полей для своевременного перехвата вредоносных атак. Также можно настроить блокировку на nginx, как показано ниже:

# Пример конфигурации Nginx
location /formaction {
    # Блокируем запросы, содержащие ссылки на опасные модули
    if ($request_body ~* "(vm#|child_process#|fs#|module#)") {
        return 403;
    }
    # Блокируем попытки загрязнения прототипа
    if ($request_body ~* "(#constructor|#__proto__|#prototype)") {
        return 403;
    }
}

2. Скорейшее обновление

Официально выпущены обновления безопасности, немедленно обновитесь до безопасной версии!:

# Обновление react-server-dom-webpack
npm install react-server-dom-webpack@>=19.2.0

# Обновление react-server-dom-turbopack
npm install react-server-dom-turbopack@>=19.2.0

# Для пользователей Next.js
npm install next@>=15.0.5

Исправленные версии:

• react-server-dom-webpack: >= 19.2.0
• react-server-dom-turbopack: >= 19.2.0
• next.js: >= 15.0.5