Руководства по безопасности

Много ли уязвимостей в Next.js и React? Что на самом деле показывают данные CVE

Мы проверили NVD: у Next.js 56 CVE (28 в 2026 году), у React 6, и все недавние CVE React относятся к Server Components. Риск не во фронтенд-коде, а в серверных функциях, которые теперь предоставляет фреймворк.

Опубликовано 2026-08-22 Обновлено 2026-10-04 Последняя проверка 2026-08-22 8 мин чтения

Для кого: для команд, использующих Next.js в продакшене, и для тех, кто решает, стоит ли его внедрять. Цель — заменить смутное ощущение «у фреймворков много CVE» реальными цифрами и тем, что за ними стоит.

Вывод

большинство уязвимостей Next.js находятся в его серверных функциях

В NVD 56 CVE для Next.js (28 только за 2026 год) и 6 для React. Но ни одна из них не связана с тем, как пишутся компоненты; это проблемы серверных функций.

Все пять недавних CVE React относятся к React Server Components, которые работают на сервере
CVE Next.js сосредоточены в middleware, кешировании, оптимизации изображений, Server Actions и rewrites
Ведущие CWE — SSRF, десериализация, исчерпание ресурсов и обход авторизации
Защищайте Next.js как сервер: отключите неиспользуемые функции и проверяйте авторизацию повторно непосредственно перед обращением к данным

Данные (NVD, на 22 августа 2026 года)

CVE, связанных с Next.js (за всё время)

из них опубликованы в 2026 году — вдвое больше, чем годом ранее

CVE, связанных с React (за всё время)

5/5

недавних CVE React относятся к RSC — серверной стороне

	Next.js	React
За всё время	56	6
По годам	2020:1 / 2021:3 / 2022:3 / 2023:1 / 2024:6 / 2025:14 / 2026:28	2018:1 / 2025:4 / 2026:1
Критичность	CRITICAL 2, HIGH 21, MEDIUM 29, LOW 4	CRITICAL 1, HIGH 3, MEDIUM 2
Самая серьёзная	CVE-2025-29927 — обход авторизации, если она выполняется в middleware (CVSS 9.1)	CVE-2025-55182 — RCE до аутентификации в React Server Components (CVSS 10.0)

Как читать число CVE

Большое число не означает опасную технологию. Чем шире распространение, тем больше исследований, а чем больше исследований, тем больше сообщений. Малое число может означать «безопасно», а может — «никто не смотрит». Число — лишь отправная точка; решение принимается по тому, где возникают проблемы и какого они рода. Цифры здесь получены запросом к NVD по CPE (vercel:next.js, facebook:react), поэтому записи без назначенного CPE не учтены.

Где они возникают

Классификация CVE Next.js, опубликованных в 2025–2026 годах, по функциям, названным в их описаниях:

Где	Как это выглядит
Кеширование	Путаница и отравление кеша — ответ одного пользователя отдаётся другому
Middleware / маршрутизация	Обход авторизации: маршрут, который вы считаете защищённым middleware, пропускает запрос
Оптимизация изображений	SSRF и исчерпание ресурсов при загрузке удалённых URL
Server Actions / RSC	Десериализация недоверенных тел запросов; перегрузка, вызванная запросами
rewrites / redirects	Разное толкование цели перенаправления

Распределение CWE говорит о том же: CWE-770 (неконтролируемое выделение ресурсов), CWE-918 (SSRF), CWE-502 (десериализация), CWE-400 (исчерпание ресурсов), CWE-444 (противоречивое толкование запросов), CWE-288/285 (обход и ошибки авторизации). Это список слабых мест сервера и прокси.

Сторона браузера — React отрисовывает компоненты

одна CVE в NVD для самого React, 2018 года

Сторона сервера 1: React Server Components

здесь все пять недавних CVE React (худшая — RCE до аутентификации)

Сторона сервера 2: middleware / кеш / оптимизатор изображений / rewrites в Next.js

обход авторизации, SSRF, отравление кеша, исчерпание ресурсов

То, что называют «уязвимостью React/Next.js», почти целиком происходит в нижней половине схемы, на стороне сервера.

Проблема, которая возвращается: авторизация в middleware

Повторяющаяся закономерность важнее любой отдельной CVE.

Март 2025 — CVE-2025-29927 (CVSS 9.1)
Запрос с определённым заголовком мог обойти проверки авторизации, выполняемые в middleware. Исправлено в 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3.
Май 2026 — CVE-2026-44574 (CVSS 8.1)
Специально сформированные параметры запроса могли изменить значение динамического маршрута, которое видела страница, оставив видимый путь прежним, и защищённое содержимое отображалось без проверки middleware. Исправлено в 15.5.16 / 16.2.5.
Июль 2026 — CVE-2026-64642 (CVSS 8.2)
В App Router с Turbopack и единственной записью в config.i18n.locales специально сформированные запросы могли обойти аутентификацию на основе middleware/proxy. Исправлено в 16.2.11.

Вывод для архитектуры, который из этого следует

Три серьёзных обхода авторизации в middleware за восемнадцать месяцев. Это не череда отдельных ошибок реализации, а следствие того, что решение принимается до маршрута, а толкование этого маршрута может смещаться. Наша позиция: оставьте middleware первой, грубой проверкой, а настоящее решение об авторизации принимайте повторно непосредственно перед обращением к данным (на странице, в обработчике маршрута или в слое данных). Написать проверку дважды дешевле, чем ущерб от одного обхода.

Часть зависит от способа хостинга

Это легко упустить: одна и та же CVE может затрагивать вас по-разному в зависимости от того, размещаете ли вы приложение сами. CVE-2026-44578 (CVSS 8.6) позволяет SSRF через специально сформированные запросы на обновление до WebSocket в самостоятельно размещённых развёртываниях со встроенным сервером Node.js, что потенциально открывает доступ к внутренним сервисам или конечным точкам метаданных облака. В бюллетене сказано, что развёртывания на Vercel не затронуты.

Поэтому «уязвимость Next.js» — не что-то одно. Применима ли она, зависит от того, как вы его запускаете и какие функции используете.

Что делать

Проверяйте авторизацию дважды (самое ценное)

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

Ограничьте белым списком то, что может загружать сервер

Ограничьте удалённые URL, которые загружает оптимизатор изображений, адреса серверного fetch и цели rewrites. Проблемы SSRF наносят наибольший ущерб там, где исходящие адреса не ограничены. Проверьте также, доступна ли из приложения конечная точка метаданных облака.

Закройте точки Server Actions и RSC аутентификацией

Это пути, которые десериализуют тела запросов, и CVE класса CWE-502 там действительно выходили. Не оставляйте их вне аутентификации, применяйте ограничение частоты запросов и убедитесь, что неожиданные данные не могут обрушить процесс. Обращайтесь с ними так же, как с /api.

Сделайте обновление системой

Next.js быстро выпускает исправления, но это помогает, только если вы обновляетесь. Подробности (оценивать по реально работающей версии и автоматически следить за зависимостями) — в статьях как безопасно эксплуатировать Next.js и как начать работать с osv-scanner. При 28 CVE в год ручное внимание не масштабируется.

Позиция сайта: вопрос о фреймворке — не о количестве

«Стоит ли избегать Next.js, потому что у него много CVE?» — неверный вопрос. Данные показывают, что Next.js постепенно взял на себя больше серверных обязанностей: он проверяет авторизацию в middleware, загружает удалённые изображения, держит кеш, десериализует запросы. По сути, одна зависимость даёт вам и обратный прокси, и сервер приложений. Поэтому оценивать нужно не число, а какие из этих серверных функций вы реально используете и кто их защищает. Отключите ненужное, а вокруг нужного удвойте собственные меры контроля. При такой постановке выбор перестаёт быть делом вкуса и становится вопросом ваших эксплуатационных возможностей.

Источники

NVD (NIST) — цифры по запросу cpe:2.3:a:vercel:next.js и cpe:2.3:a:facebook:react 22 августа 2026 года
CVE-2025-29927 (обход авторизации в middleware) / CVE-2026-44574 (смещение значения динамического маршрута) / CVE-2026-64642 (обход аутентификации в App Router + Turbopack)
CVE-2026-44578 (SSRF через WebSocket при самостоятельном размещении; Vercel не затронут)
CVE-2025-55182 (RCE до аутентификации в React Server Components, CVSS 10.0) / CVE-2026-23864 (отказ в обслуживании в RSC)

Главное

Реальные цифры: Next.js 56 (28 только в 2026 году), React 6, и все пять недавних CVE React — на стороне сервера (RSC).
Они возникают в middleware, кешировании, оптимизации изображений, Server Actions, rewrites; CWE — SSRF, десериализация, исчерпание ресурсов и обход авторизации, всё это слабые места сервера.
«Авторизацию в middleware можно обойти» случилось трижды за восемнадцать месяцев → проверяйте авторизацию повторно у данных.
Затрагивает ли вас одна и та же CVE, может зависеть от самостоятельного размещения или управляемого хостинга. Читайте бюллетени применительно к тому, как вы реально работаете.

Что почитать дальше

Реализация: загрязнение прототипа в Node.js (область, которую среда выполнения объявила вне своей ответственности)
Эксплуатация: как безопасно эксплуатировать Next.js и не отставать по CVE / автоматический мониторинг зависимостей с osv-scanner
Проектирование: аутентификация и авторизация / подмена X-Forwarded-For и доверенные прокси
Термины: что такое SSRF / что такое CVE

FAQ

QМного ли уязвимостей в Next.js?

По количеству — да, и их число растёт. Запрос к NVD 22 августа 2026 года возвращает 56 CVE, связанных с Next.js: 6 опубликованы в 2024 году, 14 в 2025-м и 28 в 2026-м. Но не считайте большое число признаком «опасной технологии»: чем шире распространение, тем больше исследований и, соответственно, сообщений. Важно, где возникают проблемы, а не сколько их.

QУ React мало уязвимостей?

У React как библиотеки интерфейса на стороне браузера их очень мало: шесть в NVD. И кроме одной 2018 года, все недавние относятся к React Server Components (react-server-dom-parcel / turbopack / webpack), которые работают на сервере. Одна из них, CVE-2025-55182, — удалённое выполнение кода до аутентификации с оценкой CVSS 10.0.

QТак где реальный риск?

В серверных функциях. Недавние CVE Next.js сосредоточены в middleware, кешировании, оптимизации изображений, Server Actions и rewrites, а ведущие CWE — SSRF (CWE-918), десериализация недоверенных данных (CWE-502), неконтролируемое потребление ресурсов (CWE-770/400) и ошибки авторизации (CWE-285/288). Ничто из этого не связано с тем, как вы пишете компоненты.

QЧто изменить в первую очередь?

Четыре вещи: (1) перестать полагаться только на middleware для авторизации — обходы выходили неоднократно; (2) ограничить белым списком исходящие адреса для оптимизации изображений, серверного fetch и rewrites; (3) держать точки Server Actions и RSC за аутентификацией и ограничением частоты запросов; (4) сделать обновление системой, а не намерением. Пункт 1 важнее всего, потому что обход одной и той же формы появлялся и в 2025, и в 2026 году.