😳 Миллионы веб-приложений под угрозой: в React Server Components нашли уязвимость максимального уровня опасности

React — один из самых популярных открытых фреймворков для веб-разработки. С его помощью созданы миллионы сайтов, корпоративных сервисов, интернет-магазинов и других приложений — все, чем мы пользуемся каждый день. Чтобы такие приложения работали быстрее, часть логики переносится на сервер через механизм React Server Components (RSC). И именно там 3 декабря была обнаружена критическая уязвимость PT-2025-48817 (CVE-2025-55182).

💡 Недостаток безопасности связан с тем, как серверная часть React принимает данные от клиента: сервер получает пакет данных и должен убедиться, что внутри нет ничего вредоносного. Но из-за ошибки он фактически не проверяет содержимое как следует. В результате хакер может отправить специальный запрос, который сервер воспримет как легитимный и выполнит команды, скрытые внутри.

Злоумышленник потенциально может без авторизации выполнить на сервере свой код — достаточно специально составленного HTTP-запроса и приложения, использующего функции для выполнения кода. Это может дать ему полный доступ к серверу: возможность менять файлы, получать данные и выполнять любые другие действия. Более того, уязвимость затрагивает все фреймворки, основанные на React, включая Next.js, что еще больше расширяет поверхность атаки, отмечает Егор Подмоков, руководитель отдела экспертизы MaxPatrol VM.

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

⚠️ Проблема получила максимальную оценку опасности — 10 из 10 по CVSS — и требует срочного устранения.

Крупные облачные провайдеры уже добавили правила для блокировки атак в своих продуктах класса web application firewall. Наш продукт PT Application Firewall защищает от эксплуатации обнаруженной уязвимости: команда выпустила пользовательское правило, которое усиливает штатную защиту и помогает детектировать наиболее распространенные на сегодня векторы на ранней стадии развития атаки.

Для устранения недостатка необходимо обновить React и связанные пакеты (в том числе транзитивные зависимости) до безопасных версий: 19.0.1, 19.1.2, 19.2.1. Если используется Next.js — обновить до релизов, где уязвимость исправлена (например, 15.0.5, 15.1.9, 15.2.6 и выше; для ветки 16 — 16.0.7; для ветки 14 необходима миграция на версии 15 или 16).

Уязвимость уже получила внимание всего профессионального сообщества, и единственный способ снизить риски — оперативно установить обновления 🤝

@Positive_Technologies

Уже лишь только ленивый не написал про CVE-2025-55182 aka React2Shell, пересказывая своими словами райтапы, пересказанные ранее другими авторами с пересказанных ещё кем-то постов.

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

✖️ Что НЕ сделали разработчики React'а?

Команда React не предусмотрела надёжную проверку и фильтрацию данных при десериализации входных нагрузок RSC (React Server Components). В результате они могли расширять свойства объектов без достаточной валидации (например, путём инъекции proto), что позволяло загрязнять прототипы (prototype pollution) и выполнять произвольный код на сервере.

✅ Что делать разработчикам?

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

💻💻:

• Используйте структуры данных без прототипа: вместо пустых объектов {} применяйте Object.create(null) или литерал {__proto__: null}. Это предотвратит наследование опасных свойств от Object.prototype.

• При необходимости используйте ассоциативные коллекции — применяйте new Map() и new Set() вместо обычных объектов. У них нет «прототипа» в классическом понимании, и методы вроде .get()/.has() возвращают только значения.

• Замораживайте глобальные прототипы: например, вызов Object.freeze(Object.prototype) (и/или Object.seal) заблокирует добавление или изменение свойств базового прототипа. Это затруднит атаки, но нужно учитывать, что многие библиотеки рассчитывают на динамическое расширение объектов.

• При запуске Node.js можете указать флаг --disable-proto=delete — он полностью удалит свойство __proto__ из стандартных объектов.

• Санитизируйте имена полей при объединении/парсинге JSON: запрещайте или фильтруйте ключи вроде __proto__, prototype, constructor и подобных. Лучше всего – явно разрешать (whitelist) только ожидаемые имена полей и отбрасывать все остальное.

• Избегайте небезопасных merge-функций (например, lodash.merge, рекурсивных функций объединения объектов) при работе с внешними данными. Если мёрдж неизбежен, тщательно проверяйте, как реализована функция: нет ли в ней присвоения прототипов или вызова setattr (в JS – методов вроде Object.assign/reduce).

💻 Python:

• Не используйте pickle, или хотя бы не выполняйте pickle.loads на входных данных. Если нужна сериализация, используйте безопасный формат (JSON, json/yaml без пользовательских конструкторов).

• Избегайте рекурсивного слияния атрибутов объектов из пользовательских словарей. Любая функция типа merge(src, dst) может при наличии поля __class__ или __globals__ обойти границы объекта и изменить класс или глобальные переменные. Проверяйте, что входные данные не содержат ключей, начинающихся с __ или равных именам методов объектов.

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

• Проверяйте использование setattr и init: ни в коем случае не допускайте передачи строкового кода или списка методов для выполнения через eval/instance_eval внутри __init__ или других «магических» методов.

• Замораживайте и не раскрывайте конфиденциальные переменные: не давать внешнему коду доступ к глобальному состоянию приложения (модули, конфиг и т.д.), тем более через __globals__/__class__.

Продолжение — в следующем посте.

А у нас две новости о грядущем PHDays Fest ✌️

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

🤖 Подробностями поделимся позже, но уже сейчас можем сказать, что на нем мы продолжим говорить о технологиях. Более простым и понятным языком — для всех, посложнее — для специалистов по кибербезопасности и ИТ. Будет больше сцен, исследований, практики и открытых диалогов.

Вторая новость — мы открываем прием заявок на выступления как перед широкой аудиторией, так и перед экспертным сообществом.

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

👉 Узнать больше подробностей и подать заявку можно на сайте киберфестиваля PHDays.

#PHDays
@PHDays
@Positive_Technologies