Как защитить веб-серверы от уязвимости CVE-2025-55182

Результат выполнения команды на самом сервере — script.sh стал выполняемым файлом:

Модуль fs

В отличие от модуля child_process, модуль fs позволяет совершать операции с файлами без необходимости выполнять дополнительные linux-команды.
Для начала стоит попытаться прочитать файл с помощью команды readFileSync, которая позволяет вывести содержимое файлов, находящихся на сервере. В качестве примера одного из таких файлов был выбран /etc/passwd.

Запрос к серверу:

Ответ от сервера. Содержимое файла закодировано в Unicode:

Декодирование файла проводится с помощью онлайн-декодера:

Команды writeFileSync и appendFileSyncвыполняют схожие операции — изменяют файл. Но если writeFileSync полностью перезаписывает содержимое файла, то appendFileSync добавляет новую строку в конец файла, не трогая его содержимое. Обе команды были успешно выполнены.

Запрос к серверу с командой writeFileSync:

Ответ от сервера:

Записанные в файл строки на уязвимом сервере:

Запрос с командой appendFileSync, которая дописывает строку в файл /opt/executor.txt:

Ответ от сервера:

Результат выполнения команды на сервере:

Модуль vm

Последним из проверяемых модулей стал vm, позволяющий запускать JS-код в различных изолированных контекстах без доступа к глобальному окружению Node.js, однако такую изоляцию можно (и, в нашем случае, нужно) обойти.
Самый простой вариант обойти изоляцию — не изолировать себя вообще. То есть запустить команду в том же контексте, в котором запущен сервер. Для этого используется команда runInThisContext, с помощью которой формируется обращение к ранее использованному модулю child_process и команде execSync.

Для демонстрации успешности эксплуатации уязвимости была использована команда hostnamectl:

В ответ от сервера была получена информация об имени сервера, его ОС, архитектуре и версии ядра:

Второй вариант обхода изоляции был осуществлен при выполнении команды runInNewContext и использовании в ней структуры вида this.constructor.constructor(‘return process’)(), что позволяет получить доступ к глобальному окружению из изолированного контекста.

Для примера была предпринята попытка получить содержимое файла /etc/apt/sources.list с помощью команды cat и обращения все к тому же модулю child_process и команде execSync:

В ответ сервер возвращает содержимое всего файла:

Подводя небольшой итог, на незащищенном сервере с библиотекой React злоумышленник может провести широкий набор действий — от вывода имени сервера до выполнения собственных скриптов через оболочку сервера или даже полностью вывести сервер из строя.

Теперь, когда удалось полностью убедиться в работоспособности уязвимости, необходимо проработать варианты того, как себя обезопасить от эксплуатации этой уязвимости на серверах, использующих библиотеку React. Самым правильным решением будет установка версии React/Next.js, в которой уже нет уязвимости. Однако возможны случаи, когда существует необходимость использования конкретной версии React на сервере, например, потому что на нее жестко завязана работа еще каких-либо модулей и обновление может привести к отказу сервера. В таком случае требуется вариант временного закрытия уязвимости, например, используя класс решений Web-Application Firewall или WAF, который создан для защиты веб-приложений. Для проверки того, как решение класса WAF позволяет бороться с эксплуатацией уязвимости, выбрано хорошо известное решение от производителя Positive Technologies — PT AF Pro версии 4.1.7

Сначала для проверок тестовый WAF использовался с правилами «из коробки», то есть без дополнительной настройки пользовательских правил. Описание процесса добавления веб-приложения на WAF в данной статье не рассматривается, так как не имеет отношения к эксплуатации уязвимости, однако стоит отметить, что у PT AF Pro сразу имеется шаблон политик безопасности для веб-приложений, использующих Node.js, который и был использован:

Модуль child_process

Первая же проверка выполнения команды execSync показала неутешительный результат — PT AF Pro с правилами «из коробки» пропустил выполнение команды echo на сервере:

Ответ от сервера:

Результат выполнения команды на сервере. Строка успешно добавлена в файл /opt/executor.txt:

А вот проверка выполнения команды spawnSync показала уже хороший результат — выполнение команды было заблокировано:

Ответ от сервера. WAF вернул статус код 403 Forbidden и ID события в веб-консоли:

Модуль fs

Ни одна из выполняемых команд не дошла до сервера, все они были заблокированы правилом попытки выхода за пределы каталога WAF.

Первой была проверена команда readFileSync с попыткой прочитать файл /etc/passwd:

Ответ от сервера, статус-код 403 и ID события в веб-консоли WAF:

Описание блокировки запроса:

С командами writeFileSync и appendFileSyncситуация аналогичная: запросы заблокированы правилом попытки выхода за пределы каталога.

Запрос с командой writeFileSync:

Ответ от WAF:

Запрос с командой appendFileSync:

Ответ от WAF:

Модуль vm

Результат проверки команд модуля vm оказался не таким однозначным, как с модулем fs: одна из команд была заблокирована, а вот вторая была успешно выполнена, но с небольшой особенностью, о которой расскажем далее.

Команда runInThisContext сразу заблокирована как попытка выполнения межсайтового выполнения сценария, что не является корректным определением нашей попытки выполнить атаку, но тут скорее важна сама блокировка, а не корректное определение атаки.

Запрос с командой runInThisContext и попыткой выполнения команды hostnamectl:

Ответ от WAF:

Описание заблокированной атаки в веб-консоли:

Выполнение команды runInNewContext дало несколько неожиданный результат. Попытка доступа к файлу /etc/passwd была заблокирована, но не потому, что обнаружена атака в запросе, а из-за того, что в ответе присутствуют чувствительные данные:

Такое поведение WAF позволило нам сделать вывод, что команда runInNewContext в целом может быть успешно выполнена, если немного модифицировать вывод файла /etc/passwd. В модификации вывода нам поможет команда xxd с аргументом -p, позволяющая вывести содержимое файла в шестнадцатеричной кодировке, которая не должна корректно обрабатываться правилами PT AF Pro.

Запрос с командой runInNewContext с выводом файла /etc/passwd в шестнадцатеричной кодировке:

Ответ от сервера, в котором видно успешное выполнение переданной команды и вывод файла /etc/passwd в шестнадцатеричной кодировке:

Декодирование полученного вывода можно провести с помощью все тех же онлайн-декодеров:

Как показали проверки, PT AF Pro без настроенных правил блокирует большую часть вариантов эксплуатации уязвимости, однако оставляет довольно ощутимую «дыру» в безопасности. А именно возможность выполнения команд execSync и runInNewContext, которые все еще позволяют злоумышленнику реализовать широкий набор действий с уязвимым сервером.

Для проведения следующих проверок на сервер WAF было загружено пользовательское правило, выпущенное производителем Positive Technologies 4 декабря специально для предотвращения эксплуатации уязвимости CVE-2025-55182.

Правило направлено на блокировку запросов с типом данных multipart/form-data, и специфичными для уязвимости конструкциями, такими как vm, fs, child_process, module или даже переменными из заголовка name $ACTION_REF_0 или $ACTION_0:0.
Добавление правила привело к закономерному результату: оставшиеся незаблокированными варианты эксплуатации уязвимости через выполнение команд execSync и runInNewContextтеперь блокировались новым пользовательским правилом. В обходе правила не помогла ни кодировка части символов в Unicode (WAF их успешно расшифровал и заблокировал запрос), ни разбиение запроса на части.

Запрос с командой execSync:

Ответ от WAF:

Запрос с командой runInNewContext:

Ответ от WAF:

Событие в веб-консоли:

Попытка разделения запроса на части с помощью скрипта также привела к блокировке по добавленному правилу:

C использованием пользовательских правил можно исключить возможность эксплуатации уязвимости и даже препятствовать наиболее распространенным вариантам обхода блокировок со стороны WAF путем замены символов на их кодировки в Unicode или разделению запроса на несколько частей. Однако такая мера по нейтрализации уязвимости может оказаться выполненной слишком «широкими мазками» и начать блокировать уже легитимные запросы.

Тестирование решений класса WAF от других производителей показало, что некоторые системы не способны обнаружить попытки эксплуатации уязвимости «из коробки» и требуют серьезных доработок правил безопасности. При этом даже при тонкой настройке таких WAF существует вероятность обхода правил блокировки с помощью кодирования символов, либо разделения запроса на несколько частей.

Тестирование проводилось только для on-prem вариантов WAF. В случае противодействия новейшим уязвимостям можно предположить, что поставщики WAF как сервиса будут разрабатывать компенсирующие правила оперативнее и точнее в силу более короткого времени получения обратной связи, но, по организационным причинам эту версию проверить не удалось.

Чтобы обезопасить себя от возможной эксплуатации рассматриваемой уязвимости, следует выполнить следующие действия:

1. Провести аудит и убедиться, что опубликованные наружу веб-приложения используют React/Next.js уязвимых версий.
2. Перейти на безопасные версии RSC-пакетов: 19.0.1, 19.1.2, 19.2.1.
3. Обновить Next.js до безопасных версий: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 или 16.0.7.
4. В случае если обновиться здесь и сейчас нет возможности, следует использовать решения класса Web Application Firewall (WAF) для блокировки попыток эксплуатации уязвимости злоумышленниками. Важно проводить тонкую настройку решения и использовать пользовательские правила, а не только правила «из коробки».
5. Пользовательские правила можно составить по совокупности следующих критериев:

• тип запроса POST;
• значение заголовка Content-type — multipart/form-data;
• в теле запроса встречаются следующе конструкции: vm#, fs#, child_process, constructor, runInThisContext, runInNewContext, execSync, execFileSync, spawnSync, module#_load, module#createRequire, readFileSync, writeFileSync, appendFileSync.

Также важно помнить, что, несмотря на доказанную эффективность WAF для закрытия уязвимости, использование решений данного класса не является панацеей. Правила, которые производители WAF выпускают для оперативного закрытия, призваны отсечь широкий спектр возможных тактик злоумышленников, поэтому могут быть написаны «широкими мазками» и частично блокировать и легитимные запросы.

Самым правильным вариантом всегда будет обновление до версий ПО, в которых эта уязвимость уже устранена. Однако WAF защитит вас здесь и сейчас и даст дополнительное время на ожидание пропатченных версий и само обновление.