React2Shell: три границы безопасности серверных компонентов

Дорогая ошибка: считать установку патча полноценной проверкой

React2Shell, CVE-2025-55182, раскрыли 3 декабря 2025 года как уязвимость React Server Components, допускающую удалённое выполнение кода без аутентификации. React указывает Лахлана Дэвидсона как автора обнаружения. Официальный бюллетень относит проблему к небезопасной десериализации. [1, 6]

Для владельца продукта важен вопрос: безопасно ли развёрнутый сервис превращает внешний запрос в серверную работу? Здесь предлагается проверка трёх границ: допустимых значений, разрешённых операций и допустимого потребления ресурсов. Это авторский анализ открытых документов, проверенных 4 октября 2026 года, а не заявление об обнаружении или воспроизведении этих уязвимостей.

Определяйте подверженность по развёрнутой системе, а не названию продукта

Составьте перечень интеграций RSC и фактически разрешённых версий react-server-dom-webpack, react-server-dom-parcel или react-server-dom-turbopack. React-приложение без серверного исполнения или интеграции с поддержкой RSC не входит в область исходного бюллетеня. Отсутствие явно написанной Server Function само по себе не доказывает, что развёрнутая RSC-система не затронута. [1]

Зафиксируйте идентификатор производственного образа или развёртывания, разрешение зависимостей, конфигурацию фреймворка и доступные обработчики запросов. Исправленная рабочая копия разработчика не показывает, что работает в старом развёртывании, preview-окружении или образе для отката. Разделяйте утверждения «пакет присутствует», «присутствует уязвимая версия» и «нужный путь исполнения достижим»: каждому нужны свои доказательства.

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

Десериализация не сводится к проверке сходства запроса с JSON. Декодер может восстанавливать ссылки, интерпретировать типы или разрешать отложенные значения. Нужно выяснить, какие смыслы атакующий способен заставить сервер построить до прикладной валидации. Проследите преобразование в реальной интеграции фреймворка, не предполагая, что бизнес-обработчик получает только безвредные примитивы.

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

HTTP input
  -> [1] decode into permitted values
  -> [2] authorize the requested operation
  -> [3] execute within an explicit work budget
  -> produce a permitted response

Review invariants:
  malformed input -> bounded rejection
  unauthorized operation -> no state change
  excessive work -> bounded termination
  error response -> no sensitive implementation data

Вторая граница: возможность вызвать функцию не даёт права на операцию

Документация React Server Functions объясняет, как клиентские вызовы превращаются в сетевые запросы к серверному коду. Такая транспортная возможность не обеспечивает объектные права доступа вашего продукта. [5] Для функции изменения счёта сервер должен установить, кто вызывает её, какому tenant принадлежит счёт и разрешён ли этому субъекту конкретный переход состояния.

Составьте матрицу прав для анонимного посетителя, участника нужного tenant, участника другого tenant и учётной записи только для чтения. Проверяйте ответ и сохранённое состояние. Отклонение запроса после выполненного изменения означает провал авторизации, даже если HTTP-статус выглядит правильно. Повторите проверку для косвенных вызовов, пакетных операций и альтернативных идентификаторов, которые приложение действительно принимает.

Третья граница: корректный ввод может требовать недопустимого объёма работы

CVE-2026-23864, раскрытая 26 января 2026 года, охватывает дополнительные случаи отказа в обслуживании RSC. Разработчики описывают чрезмерное использование CPU, исчерпание памяти и аварийное завершение процессов. [3] React отдельно указывает, что эти последующие проблемы не отменили исправление удалённого выполнения кода React2Shell. Различайте свойства, которые обеспечивает каждый патч. [2]

Лимит размера запроса измеряет входящие байты, но напрямую не ограничивает работу, которую они запускают. Где соответствующие механизмы существуют, исследуйте разворачивание ссылок, повторное разрешение, обращения к другим сервисам и отмену. Выберите реалистичные ограничения CPU, памяти, параллельности и времени выполнения. Тайм-аут полезен, только если работа действительно прекращается. Используйте тестовое окружение и заранее заданные пороги остановки; намеренное истощение производственного процесса не служит полезной приёмочной проверкой.

Исследуйте производственный ответ и содержимое собранного кода

CVE-2025-55183 связана с раскрытием исходного кода при определённых конфигурациях Server Functions. Бюллетень указывает риск для секретов, встроенных в раскрываемый код; он не устанавливает общую утечку значений переменных окружения через эту конкретную ошибку. Встраивание функций сборщиком может влиять на код, видимый в производственном артефакте. [4, 2]

Проверьте возвращаемые значения, неявные преобразования в строки, ошибки и скомпилированное тело функции. В отдельной тестовой сборке используйте безвредный маркер, чтобы установить, проходят ли детали реализации через границу ответа. Отрицательный результат для одного маркера — ограниченное доказательство, а не подтверждение безопасности всех путей ответа. Отделяйте эту проверку от расследования RCE-инцидента: скомпрометированный процесс может иметь значительно более широкий доступ к секретам.

Ведите журнал границ, который разработчики смогут воспроизвести

Журнал ниже связывает маршрут и развёрнутую сборку с субъектом, классом ввода, ожидаемым результатом и наблюдаемыми доказательствами. Это предлагаемый шаблон отчёта. Заполняйте его реальными измерениями, не выдавая теоретическую атаку за подтверждённую находку. Для отклонённой операции фиксируйте отсутствие изменения состояния; для ресурсной проверки — момент прекращения работы и применённые ограничения.

В январском бюллетене 2026 года версии 19.0.4, 19.1.5 и 19.2.4 указаны как исправления затронутых RSC-пакетов. Это исторические пороги исправления, а не рекомендация навсегда оставить систему на этих версиях и не утверждение об отсутствии новых бюллетеней. [3] Выберите поддерживаемый исправленный выпуск фреймворка, пересоберите и разверните продукт, затем проверьте разрешённые зависимости и нужное поведение именно в этом артефакте.

route_id | deployed_build | package_versions
principal | tenant | object | requested_operation
input_class | expected_result | observed_result
cpu_time | peak_memory | downstream_calls
state_before | state_after | reviewer | evidence_ref

Что полезная проверка должна дать владельцу продукта

Запрашивайте понятное решение о подверженности, подтверждающие его сведения о зависимостях и развёртывании и отдельные выводы о декодировании, правах, ресурсах и утечках через ответы. Для каждой находки нужны условия, затронутый сценарий, воспроизведение в согласованном окружении, практическое влияние и критерии проверки. Впечатляющий перечень CVE не заменяет связи с вашим приложением.

Для целевой проверки выберите важный сценарий: выставление счетов, управление учётными записями или доступ к данным tenant. Соедините анализ кода с согласованными поведенческими проверками, сохраните журнал границ и повторно проверьте исправленное развёртывание. Разделение смысла, полномочий и бюджета работы полезно также для десериализации Java и нативных парсеров, но их механизмы и уязвимости нужно исследовать независимо.

Источники

Обсудить такую проверку

Услуги

Все статьи