Когда уязвимость во фронтенде — это проблема всего отдела: разбираем React4Shell и почему бэкендеру нельзя пропускать мимо ушей
Привет, коллеги!
Как вы знаете, моя кухня — это бэкенд. Laravel, PHP, серверная логика, безопасность API, валидация, санитизация... Всё, что происходит на стороне сервера, — это моя вотчина. Я привык думать, что уязвимости вроде SQL-инъекций или RCE (удалённое выполнение кода) — это наши, бэкенд-бойцовские, головные боли. Мы за всем следим, всё фильтруем, везде ставим барьеры.
Но сегодняшняя история — это яркий пример того, как границы стираются. Речь пойдёт о критической дыре не где-нибудь, а в самом React. И проблема эта не про «криво отрисовался компонент», а про полноценный RCE (Remote Code Execution). Зовут её CVE-2025-55182, а в народе уже окрестили React4Shell или React2Shell. Думаю, многие об этом уже знают, а кто нет - повод задуматься и решить проблему...
Что случилось?
В декабре 2025 в React 19 (а конкретно в механизме React Server Components (RSC) и Server Actions) нашли критическую уязвимость. Суть в том, что серверные функции ошибочно начинали доверять данным, пришедшим от клиента, и воспринимали их как часть исполняемого кода. Представьте, что вы на бэкенде вдруг взяли и выполнили eval() над сырым JSON-ом из тела запроса без какой-либо проверки. Вот что-то похожее произошло и тут.
Сухие факты:
- CVE: CVE-2025-55182 (React4Shell / React2Shell).
- Суть: RCE через некорректную обработку данных пользователя в Server Actions.
- Угроза: Злоумышленник мог выполнить произвольный код на сервере, украсть токены, сессии, данные, атаковать внутреннюю сеть.
- Затронуто: React версий 19.0.0 – 19.2.0, а также Next.js ~15.0.4 – 16.0.6.
- Лечение: Релиз патча в React 19.2.3 (3 декабря 2025) и соответствующие обновления для Next.js.
Почему это важно знать нам, бэкендерам?
- Архитектура. Современные фуллстек-фреймворки (вроде Next.js) стирают грань. Server Components и Server Actions — это код, который выполняется на сервере, но пишется фронтенд-разработчиком. По сути, часть логики переместилась в их зону ответственности, но выполняется на нашей территории. И если там дыра — бьёт она по нашему же серверу.
- Командная ответственность. Мы не можем вариться в своём соку. Безопасность — сквозная задача. Если наш коллега-фронтендер не в курсе этой уязвимости (мало ли, был в отпуске), а мы, зная о таких рисках, можем его вежливо спросить: «Слушай, а мы на патч переехали?», — это спасёт проект.
- Понимание угроз. Теперь мы знаем, что RCE может прийти не только через наш эндпоинт /api/, но и через, казалось бы, безобидный запрос от React-компонента. Это расширяет картину мира.
Что делать? (Советую переслать это своим фронтенд-коллегам):
- Срочно обновить React до версии 19.2.3+.
- Обновить Next.js или другой используемый мета-фреймворк до пропатченной версии.
- Пересмотреть логику Server Actions: никакого слепого доверия входящим данным от клиента. Всё валидировать и санитизировать. Золотое правило бэкенда теперь касается и этой части фронтенда.
История с React4Shell — это отличный повод лишний раз поговорить с командой о безопасности. Не в формате «ваш код кривой», а в формате «ребята, вот новая угроза, давайте вместе убедимся, что мы защищены».
Потому что в современной разработке бэкенд и фронтенд — это не два отдельных мира, а два берега одной реки под названием «Продукт». И если на одном берегу прорвёт дамбу, затопит обоих.
А вы сталкивались в своих командах с подобными междисциплинарными уязвимостями? Если да — как решали? Если нет — может, стоит сегодня за чашкой кофе спросить у фронтендеров: «Как у вас там дела с React?»