Фронтенд больше не просто фронтенд
Некоторые уязвимости патчатся и быстро забываются. Другие заставляют нас переосмыслить модель риска используемой нами архитектуры. CVE-2025-55182 относится ко второй категории.
3 декабря 2025 года команда React объявила о критической уязвимости удалённого выполнения кода, затрагивающей версии Next.js, использующие React 19 и React Server Components. Исследователи быстро дали этой уязвимости название React2Shell. Тогда же возникло и сравнение с Log4Shell. Хотя это сравнение может показаться преувеличенным, оно небезосновательно.
Три особенности делают React2Shell критической: она затрагивает широко используемые современные веб-фреймворки; она может быть удалённо инициирована без аутентификации; она создаёт риск выполнения кода на стороне сервера через фреймворк, воспринимаемый как «фронтенд». Последний пункт особенно важен.
React долгое время считался слоем интерфейса. Но вместе с React Server Components и современными архитектурами SSR это разделение изменилось. Теперь некоторые компоненты React выполняются непосредственно на стороне сервера. Это делает фронтенд-фреймворк частью бэкенд-поверхности с точки зрения безопасности приложений. React2Shell сделал видимым последствие этого перехода для безопасности.
Если злоумышленник может нацелить серверный обработчик RSC специально сформированным HTTP-запросом, речь идёт уже не только о JavaScript, выполняемом в браузере. Речь о процессе приложения, переменных окружения, подключениях к базе данных, файловой системе и доступах к внутренним сервисам. Поэтому React2Shell — это не просто уязвимость React, а неправильно классифицированная поверхность безопасности современной веб-архитектуры.
Уязвимость с первого взгляда
Без аутентификации, удалённо, без взаимодействия пользователя
Бюллетень безопасности ReactСкоординированное раскрытие с доступными патчами
Бюллетень безопасности ReactТакже версии Next.js, использующие React Server Components
Бюллетень безопасности ReactДоля новых веб-приложений, использующих React (отраслевая оценка)
Strobes Top CVEs декабрь 2025Что это за уязвимость?
React Server Components — важная модель, используемая в React 19 и современной архитектуре Next.js. В этой модели одни компоненты выполняются на стороне клиента, другие — на стороне сервера. Компоненты, выполняемые на сервере, не отправляют клиенту просто HTML в классическом смысле. Вместо этого используется специальный формат сериализации, позволяющий восстановить дерево React. Этот формат быстр, выразителен и обеспечивает фреймворку гибкость. Но эта гибкость одновременно порождает риск.
CVE-2025-55182 связана с тем, что в затронутых версиях этот процесс сериализации и десериализации может быть использован злоумышленником. Специально сформированный запрос RSC может заставить серверный обработчик небезопасно обработать данные, контролируемые злоумышленником. В ходе этого процесса злоумышленник может получить возможность выполнения кода внутри процесса приложения.
Такой тип уязвимости не нов для мира безопасности. Это новый пример класса «выполнение кода через десериализацию недоверенных данных», который годами наблюдается в Java RMI, Python pickle, .NET BinaryFormatter и подобных технологиях, в мире современных веб-фреймворков. Новым является то, что этот паттерн проявляется в архитектуре, воспринимаемой как фронтенд-ориентированная, такой как React Server Components.
Критический момент, усиливающий воздействие уязвимости: обработчик RSC в некоторых развёртываниях может обрабатывать данные, контролируемые злоумышленником, до применения аутентификации или авторизации. Это выводит уязвимость из классической категории «баг в панели администратора с аутентификацией». Если есть конечная точка RSC, открытая в интернет, злоумышленнику нужен лишь соответствующим образом сформированный запрос.
Log4Shell стал поворотной точкой в современной безопасности ПО. Причиной было не только обнаружение критической уязвимости в Log4j — настоящей причиной было то, что Log4j используется почти повсеместно и атака может быть инициирована с крайне низким порогом. Единственная строка, контролируемая злоумышленником, достигнув нужного пути кода, могла привести к удалённому выполнению кода. React2Shell разделяет те же характеристики, перенесённые на современный веб-стек: React — один из самых широко используемых фреймворков в современной веб-разработке (отраслевая оценка ~40% новых веб-приложений), Next.js занимает сильную позицию в продакшен-приложениях на основе React, RSC — модель по умолчанию в современной архитектуре Next.js. Единственный сформированный HTTP-запрос, без аутентификации, полный захват сервера. Многие команды всё ещё классифицируют React как «фронтенд» — этот рефлекс больше недостаточен. Часть кода приложения выполняется на сервере и порождает для злоумышленника бэкенд-воздействие. «Log4Shell фронтенда» — это не просто броский заголовок; это более глубокое архитектурное предупреждение: фронтенд-фреймворки больше не освобождены от дисциплины бэкенд-безопасности.
Как работает цепочка атаки?
Атака класса React2Shell со стороны может выглядеть довольно простой. Но её воздействие велико из-за контекста выполнения на стороне сервера.
Определение цели
Злоумышленник сначала пытается выявить актуальные приложения Next.js, использующие React 19 или RSC. Этот процесс снятия отпечатков чаще всего несложен. Конечные точки RSC можно определить по характерным паттернам URL, типам контента, форматам ответов или поведению фреймворка. Интернет-сканеры и автоматизированные инструменты разведки могут перечислять такие поверхности в широком масштабе. После объявления уязвимости первый риск — это волна автоматического сканирования до целевых атак.
Сформированный запрос RSC
Злоумышленник отправляет специально сформированный HTTP-запрос на конечную точку RSC. Этот запрос со стороны не обязательно должен выглядеть полностью аномальным. Тип контента, структура заголовков и целевая конечная точка могут быть похожи на легитимный трафик RSC. Опасная часть находится внутри нагрузки — она формируется так, чтобы использовать процесс десериализации на стороне сервера. Тот же эффект может быть получен разными цепочками гаджетов, разными техниками кодирования или разными формами фрейминга; это затрудняет обнаружение.
Десериализация на стороне сервера
В затронутых версиях серверный обработчик RSC обрабатывает входящую нагрузку небезопасным образом. Если десериализация происходит до проверок аутентификации или авторизации, отсутствие аутентификации у злоумышленника не препятствует атаке. На этом этапе злоумышленник может получить возможность выполнения кода внутри процесса, в котором работает приложение. Это и есть настоящая точка прорыва атаки — потому что злоумышленник теперь производит воздействие не в браузере, а на сервере.
Продвижение с полномочиями приложения
Выполнение кода на стороне сервера не означает выполнение лишь одной команды. Злоумышленник может получить доступ к полномочиям, которыми обладает процесс приложения — переменные окружения, данные подключения к базе данных, ключи API, доступ к файловой системе, доступы к внутренним сервисам, системы логов и кэша, инфраструктуры очередей/хранилищ/обмена сообщениями, конечные точки cloud metadata, токены сервисных учётных записей. После этого атака переходит в классическую фазу post-exploitation: сбор секретов, закрепление, горизонтальное перемещение, утечка данных.
Сокрытие следов
В уязвимостях вроде React2Shell первый запрос может быть похож на легитимный трафик RSC. Злоумышленники могут пытаться смешать попытки эксплуатации с нормальными паттернами трафика. Если на уровне приложения недостаточно логирования, найти первый инициирующий запрос становится сложно. Для расследования после инцидента одних только access-логов может быть недостаточно — структуры нагрузок, поступающих на конечные точки RSC, аномальные паттерны сериализации, POST-попытки без аутентификации и необычные коды ошибок должны рассматриваться вместе.
Почему обнаружение WAF затруднено?
WAF — мощный первый уровень защиты для многих классов атак. Они могут масштабно перехватывать такие паттерны, как SQL injection, XSS, path traversal, известные нагрузки эксплойтов и нарушения протокола. Уязвимости класса React2Shell же сложнее для обнаружения WAF — по трём причинам.
Трафик может быть похож на легитимный трафик RSC
Запрос эксплойта может использовать ту же конечную точку, тот же тип контента и схожую структуру заголовков. Блокировка только по URL или типу контента может породить высокую долю ложных срабатываний. Полное отключение трафика RSC нарушает функциональность. Подхода WAF «я увидел запрос RSC, заблокирую его» недостаточно — нужно совместно оценивать структуру нагрузки, паттерн запроса, поведение конечной точки и контекст приложения.
Нагрузка полиморфна
Эксплойты десериализации могут выражаться в разных формах — разные цепочки гаджетов, разное кодирование, разные структуры вложенности, разные вариации сериализации. Та же цель эксплуатации может быть достигнута множеством разных форм нагрузки. Это сокращает срок жизни статических сигнатур. Пока сигнатура перехватывает определённый вариант, злоумышленник может снова попробовать ту же уязвимость с другой структурой нагрузки.
Требуется контекст приложения
Эффективное обнаружение React2Shell не может выполняться только на уровне протокола. Нужно понимать, что нагрузка означает в потоке RSC и какие структуры в норме не должны приниматься. Без этого контекста приложения обнаружение WAF остаётся частичным. Постоянное решение — патч фреймворка; WAF снижает сканирование и попытки эксплуатации низкой квалификации в окне до патчинга, но не заменяет патчинг.
Что должны делать организации?
Для уязвимостей вроде React2Shell правильный ответ — не паника, а приоритизированное реагирование. Приведённые ниже шаги следует рассматривать по порядку.
Проведите инвентаризацию приложений React 19 и Next.js RSC
Первый шаг — знать, какие приложения затронуты. В инвентаризацию следует включить не только основные продакшен-приложения; также staging-окружения, партнёрские порталы, внутренние панели управления, демо-окружения, временные публикации, edge-развёртывания, serverless-функции, preview-окружения и старые, но открытые в интернет приложения Next.js. Информация о владельце также должна быть частью инвентаризации. Приоритет: открыто ли в интернет, использует ли RSC, есть ли конечная точка до аутентификации, есть ли доступ к чувствительным данным или внутренним сервисам, работает ли с высокопривилегированной сервисной учётной записью.
Примените официальные патчи
Постоянное решение — применение официальных патчей. Бюллетень безопасности React и соответствующие объявления фреймворка следует отслеживать на предмет затронутых версий и путей обновления. Если применение откладывается из-за конфликтов зависимостей, поломки тестов или процесса развёртывания, эту тему нельзя оставлять обычному циклу обслуживания. Для уязвимостей этого класса приоритет патчинга должен быть наивысшим. Для приложений, открытых в интернет, использующих RSC и обрабатывающих чувствительные данные, время патчинга следует рассматривать в масштабе часов или дней.
Ужесточите валидацию конечных точек RSC
Если патчинг откладывается или в переходный период нужна дополнительная защита, для конечных точек RSC следует применить дополнительную валидацию: принудительное использование ожидаемых типов контента, ограничения размера нагрузки, валидацию схемы, отклонение неправильно сформированных последовательностей сериализации, сокращение доступа к RSC до аутентификации, отключение неожиданных HTTP-методов, ограничение скорости на уровне конечной точки, пометку аномальных комбинаций заголовков и тела. Эти средства контроля не заменяют патч, но сужают поверхность атаки.
Проверьте логи начиная с ноября 2025 года
Следует оценить вероятность того, что некоторые злоумышленники предпринимали попытки эксплуатации ещё до объявления уязвимости. Проверьте трафик, поступающий на конечные точки RSC начиная с ноября 2025 года: POST-запросы без аутентификации, необычные размеры нагрузок, неожиданные структуры сериализации, неправильно сформированные запросы, вызовы RSC, не связанные с нормальным потоком пользователя, множество попыток вариаций с одного IP, рост кодов ошибок, события сбоя или перезапуска приложения, аномальный рост задержки на конечных точках RSC. При вероятности успешной эксплуатации следует выполнить: ротацию секретов, пересмотр сервисных учётных записей, проверку container image, анализ изменений файловой системы и расследование перемещения по внутренней сети.
Включите управляемые правила WAF
Крупные поставщики WAF, включая TR7, выпустили управляемые правила, нацеленные на паттерны атак React2Shell. Эти правила полезны для снижения волн автоматического сканирования, перехвата известных вариантов эксплойтов, блокировки атак низкой квалификации, обеспечения видимости аномалий в трафике конечных точек RSC и создания дополнительного уровня защиты до применения патча. Правила WAF не следует рассматривать как абсолютную гарантию — из-за полиморфизма нагрузки и контекста приложения могут существовать варианты, которые WAF не перехватит. Правильный порядок: сначала патч, затем глубокая защита с WAF.
Подготовьтесь к следующей уязвимости фреймворка
React2Shell — это не просто один CVE. Он показывает, что архитектура современных фреймворков создаёт новые поверхности, которые должны проходить тестирование безопасности. React Server Components, SSR, edge rendering, server actions, потоковые ответы и протоколы сериализации внутри фреймворков требуют большего, чем классическая модель безопасности фронтенда. Моделируйте угрозы для этих поверхностей как для бэкенда: какой код фреймворка выполняется на сервере, какие конечные точки создаются автоматически, где выполняется десериализация или сериализация, на каком этапе применяется аутентификация, с какими полномочиями работают server actions, логируются ли конечные точки фреймворка, есть ли ограничение скорости, открыты ли в интернет окружения preview/staging.
Самый важный урок React2Shell — не в том, что класс уязвимости нов. Напротив, класс уязвимости очень знаком: десериализация недоверенных данных, приводящая к выполнению кода. Новой является поверхность. Эта уязвимость показала, что классическая проблема бэкенд-безопасности может проявиться в архитектуре фреймворка, ориентированного на фронтенд. Из этого следуют два вывода: во-первых, команды фронтенд-фреймворков теперь несут часть тех обязанностей по безопасности, что несут команды бэкенд-фреймворков — компоненты, выполняемые на стороне сервера, протоколы фреймворка, server actions и слои сериализации должны тестироваться глазами злоумышленника. Во-вторых, корпоративные команды безопасности не должны классифицировать React, Next.js, Remix, Astro и подобные современные фреймворки только как клиентскую технологию — в большинстве развёртываний эти фреймворки производят бэкенд-поведение. Категория в архитектуре безопасности должна измениться: фронтенд-код, выполняемый на сервере, — это бэкенд-код.
Как уровни TR7 отвечают на угрозы класса React2Shell?
Для уязвимостей вроде React2Shell первичное решение — патч. Но до применения патча и после него для рисков схожего класса нужна многоуровневая защита. WAAP-подход TR7 отвечает на такие угрозы на нескольких уровнях.
Управляемые правила WAF
TR7 WAF предлагает управляемые правила, настроенные на обнаружение паттернов атак React2Shell на уровне протокола, конечной точки и структуры нагрузки. По мере появления новых вариантов эксплойтов наборы правил обновляются. Это первый уровень защиты против автоматического сканирования и попыток эксплуатации низкой квалификации, начинающихся по всему интернету.
Ограничение скорости на конечных точках RSC
Ограничение скорости с учётом приложения снижает автоматическую разведку и попытки вариаций эксплойтов. Злоумышленники делают множество попыток нагрузок на множестве целей — ограничение скорости на уровне конечной точки снижает скорость сканирования и нарушает экономику атаки.
Аутентификация с AGS
TR7 AGS может сделать аутентификацию обязательной для внутренних приложений и панелей управления до того, как запрос достигнет приложения. Это предотвращает оставление конечных точек RSC открытыми в интернет без аутентификации. Применяются политики минимальных полномочий и условного доступа.
Аналитика в реальном времени
Необычные структуры нагрузок в трафике конечных точек RSC, неожиданные паттерны запросов, аномальные доли ошибок и нестандартные распределения источников могут помечаться аналитикой в реальном времени. Отдельные запросы могут выглядеть легитимными; на уровне сессии или источника проявляется попытка атаки — эта видимость особенно важна при полиморфных нагрузках.
Криминалистическое логирование
Детали запросов/ответов на путях RSC, контекст сессии, решения WAF и сигналы аномалий становятся доступными для реконструкции после инцидента. Команды безопасности могут расследовать вопросы «какая нагрузка пришла, какая конечная точка была затронута, в каком контексте сессии это произошло и какие данные оказались под риском?».
Изоляция высокой ценности с ZeroLeak
Некоторые приложения React/Next.js — не обычные веб-приложения, а финансовые панели, консоли клиентских PII, порталы юридических документов, интерфейсы администраторов. Для таких приложений визуальная изоляция браузера ZeroLeak обеспечивает дополнительное архитектурное средство контроля. Пользователь видит только поток пикселей; DOM, JavaScript, ответ API или токен сессии не отправляются.
Заключение: сначала патч, затем постоянный архитектурный урок
Первый и самый важный ответ для React2Shell ясен: найдите затронутые приложения React 19 и Next.js RSC и примените официальные патчи. Этот шаг нельзя откладывать. Уязвимости удалённого выполнения кода без аутентификации, особенно на распространённых поверхностях фреймворков, являются инцидентами безопасности наивысшего приоритета.
Но эту уязвимость не следует закрывать лишь как задачу патчинга. React2Shell даёт более крупный урок о современной веб-архитектуре: фронтенд-фреймворки больше не сводятся только к UI-коду, выполняемому в браузере. Модели вроде Server Components, SSR, server actions и edge runtime размывают границу между фронтендом и бэкендом.
Поэтому должна измениться и модель угроз команд безопасности. В React, Next.js и подобных фреймворках каждый путь, выполняемый на сервере, должен рассматриваться с дисциплиной бэкенд-безопасности. Слои сериализации и десериализации должны проверяться. Конечные точки, автоматически создаваемые фреймворком, должны инвентаризироваться. Порядок аутентификации и подверженность конечных точек должны явно тестироваться.
Краткий урок React2Shell: фронтенд-код, выполняемый на сервере, — это бэкенд-риск.
Источники
Отраслевой анализ критических CVE декабря 2025 года, включая CVE-2025-55182 React2Shell. https://strobes.co/blog/top-cves-of-december-2025/
Независимые новости об объявлении React2Shell и ландшафте атак. https://securityboulevard.com/2026/01/top-cves-of-december-2025/
Официальная запись CVE. https://nvd.nist.gov/vuln/detail/CVE-2025-55182
Отслеживание атак в реальных условиях от CISA. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Сначала патч, затем многоуровневая защита
Примените патчи из бюллетеня безопасности React ко всем затронутым приложениям. Проведите инвентаризацию конечных точек RSC, проверьте прошлый трафик и обеспечьте дополнительную защиту управляемыми правилами WAF в окне патчинга. TR7 WAF, AGS, аналитика в реальном времени, криминалистическое логирование и изоляция ZeroLeak обеспечивают многоуровневую защиту против угроз класса React2Shell.
Изучить TR7 WAF