Уязвимости Next.js в мае 2026: главная угроза — отравление RSC-кеша

Какие уязвимости Next.js действительно важны: суть и приоритеты

6 мая 2026 года Next.js выпустил 13 согласованных бюллетеней безопасности, а 7 мая — исправленные версии 16.2.6 и 15.5.18. Пресса сосредоточилась на CVE-2026-44578, SSRF через WebSocket: из неё получается эффектный скриншот. Злоумышленник переводит соединение в режим WebSocket, сервер сам обращается к 169.254.169.254, а эндпоинт метаданных возвращает учётные данные IAM. Выглядит драматично.

Но уязвимость затрагивает только self-hosted-развёртывания. В развёртывании под управлением Vercel, перед которым стоит Cloudflare, этот путь недоступен. До моих читателей может добраться другая проблема — почти не обсуждаемое отравление RSC-кеша со степенью опасности Moderate. Отравленный RSC-ответ не остаётся в рамках запроса атакующего: он попадает в общий edge-кеш и затем отдаётся каждому посетителю, пока я не выполню сброс по тегу.

Если используется любая версия Next.js >= 13.4.13, обновиться нужно на этой неделе. Вопросы только в том, до какой версии обновляться, в каком порядке и что затем перепроверить. Ниже — матрица триажа, которую я применил к omidsaffari.com: App Router на Vercel, Cloudflare перед ним, сброс кеша по Cache-Tag и вебхук ревалидации. Её вывод заставил меня сместить приоритет с уязвимости, попавшей в заголовки.

Что это означает для основателей без технического бэкграунда

Если ваш продукт работает на Next.js, эту задачу нужно закрыть на этой неделе, а не отправлять в бэклог. Риск для бизнеса здесь связан не с задержками или стоимостью часов разработчиков. Отравленная страница в кеше или обход авторизации на административном маршруте бьют по доверию клиентов. Достаточно одного скриншота, где на маркетинговой странице показывается контент злоумышленника, или одного сообщения о доступе к /admin без сессии — и следующую неделю придётся потратить на объяснения, а не на продажи.

Задайте инженерам ровно один вопрос: «Мы уже на 16.2.6 или 15.5.18 и очистили edge-кеш после деплоя?» Если ответ менее конкретен — «ставим патч», «работа идёт», «SSRF нас не затрагивает», — задача ещё не выполнена. Self-hosted-развёртывания (ECS, EC2, Kubernetes и всё, где next start работает на вашем сервере) относятся к группе повышенного риска: им угрожает и SSRF, и все остальные проблемы. Уточните, к какому типу относится ваша инфраструктура. Ответ должен занять десять секунд.

Все 13 уязвимостей Next.js — по применимости к вашей инфраструктуре

Главная ошибка во всех публикациях в духе «13 CVE — срочно ставьте патч» — представлять список плоским. Это не так. Для каждого бюллетеня есть условие: self-hosted-развёртывание, Turbopack, Cache Components, nonce в CSP или i18n. Реальный риск создают только те уязвимости, чьи условия совпадают с вашей конфигурацией. Ниже те же 13 проблем, сгруппированные по условиям эксплуатации.

Группа обходов middleware и прокси (5 бюллетеней, в основном High). Самая серьёзная — GHSA-267c-6grr-h53f: URL предварительной загрузки сегмента App Router позволяет обойти проверки авторизации в middleware. Сюда же входят опубликованное 7 мая дополнение к неполному исправлению (GHSA-26hh-7cqf-hhc6) для Turbopack, обход через путь локали по умолчанию i18n в Pages Router и обход с помощью внедрения параметра динамического маршрута. Условие: middleware Next.js отвечает за авторизацию или перенаправление маршрутов с помощью rewrite. Так устроено почти у всех.

SSRF, CVE-2026-44578. Обработчик переключения на WebSocket в self-hosted-сервере обращается к внутренним HTTP-эндпоинтам на порту 80, включая метаданные облака. Затронуты версии 13.4.13+ до <15.5.16 и 16.0.0–<16.2.5, только при self-hosted-развёртывании. Подтверждено, что управляемые развёртывания Vercel не затронуты.

Отказ в обслуживании, два бюллетеня. Первый описывает upstream-уязвимость RSC DoS, второй — DoS с исчерпанием соединений в приложениях, где включены Cache Components (High, GHSA-q4gf-8mx6-v5v3). Условие для второго: Cache Components должны быть включены явно, а в большинстве приложений это не сделано.

Отравление RSC-кеша (Moderate). Коллизии механизма обхода кеша в конвейере RSC-пейлоада позволяют специальным запросом отравить кешированный ответ. Условие: RSC-ответы кешируются где-либо ниже по цепочке — в CDN, reverse proxy, edge-сети Vercel или Cloudflare. Для моей инфраструктуры это ключевая уязвимость.

XSS, два бюллетеня. CVE-2026-44581 (Moderate) затрагивает приложения с App Router, которые создают nonce для CSP; ещё одна XSS-уязвимость возникает в скриптах beforeInteractive, получающих недоверенный ввод. Условия: CSP с nonce либо передача пользовательского ввода в тег скрипта beforeInteractive.

Зафиксируйте, какие условия выполняются в вашем развёртывании: это и будет реальный список. Для omidsaffari.com картина такая: группа обходов middleware — да; SSRF — нет, хостинг Vercel; RSC DoS — да, это upstream-проблема; DoS в Cache Components — нет, компонент не включён; отравление RSC-кеша — да, причём с усиленным эффектом; XSS через nonce CSP — да; XSS в beforeInteractive — нет. Восемь бюллетеней High/Moderate сокращаются до пяти применимых ко мне, а самый большой радиус поражения у вовсе не самой известной уязвимости.

Почему нашумевшая SSRF, скорее всего, вам не угрожает, а отравление RSC-кеша — угрожает

Для эксплуатации CVE-2026-44578 сервер next start на стороне Node должен обработать переключение WebSocket и пройти по редиректу. Vercel не проводит мои запросы через такой сервер так, чтобы этот SSRF-маршрут оставался доступным: платформа завершает WebSocket-соединения, а эндпоинт метаданных защищён IMDSv2 с таким hop limit, что запрос всё равно не пройдёт по этой цепочке. Cloudflare перед Vercel вывод не меняет. В топологии Vercel + Cloudflare эффектного скриншота не получится.

С отравлением RSC-кеша всё ровно наоборот. Уязвимость находится на пути обработки запросов, которым пользуются все, а результатом становится отравленный RSC-пейлоад — сериализованное дерево React, получаемое читателями. На моём сайте этот пейлоад не остаётся внутри запроса злоумышленника. Он попадает сюда:

Cache-Control: public, s-maxage=300, stale-while-revalidate=86400
Cache-Tag: article:nextjs-may-2026-security-triage

s-maxage=300 означает, что Cloudflare хранит ответ пять минут. С stale-while-revalidate=86400 он продолжит отдавать ответ ещё сутки после истечения срока, пока в фоне идёт ревалидация. Cache-Tag нужен мне для очистки: при публикации новой редакции revalidate-вебхук запускает purge по тегу, и объект удаляется.

Разберём путь отравленного ответа. Злоумышленник обращается к маршруту, на котором срабатывает коллизия механизма обхода кеша. Cloudflare видит кешируемый ответ, сохраняет его под ключом кеша этого URL и помечает тегом article:<slug>. Все последующие посетители этой страницы получают отравленный RSC-пейлоад с edge-узла — не из origin, не через middleware и не через правило WAF, которое я добавлю десять минут спустя. Отравленный объект уже находится ниже по цепочке. Он останется там до конца окна s-maxage или до запуска очистки в моём конвейере публикации. Правила WAF на origin ничего не меняют для ответа, который уже находится в 300 PoP.

Поэтому под угрозой оказывается поверхность опубликованного контента — результат контентной системы, — а не внутренний API. В списке из 13 бюллетеней SSRF имеет уровень High, а эта проблема — Moderate. Для RSC-сайта с кешем перед origin практический порядок рисков обратный.

Как обновить Next.js и не попасть в ловушку с исправлением Turbopack

Шаг первый — выяснить фактическую версию. При диапазоне с кареткой package.json не показывает разрешённую версию; смотрите lockfile.

bun pm ls | grep next
# or
npm ls next

Затем закрепите ровно 16.2.6 для ветки Next.js 16 или 15.5.18 для ветки Next.js 15. Не 16.2.5. Не 15.5.16.

bun add next@16.2.6
# or
npm install next@16.2.6 --save-exact

Точная фиксация версии нужна из-за ловушки, о которой почти никто не упоминает. 6 мая исходные 13 уязвимостей исправили в 16.2.5 / 15.5.16. Но 7 мая Vercel выпустил GHSA-26hh-7cqf-hhc6 — дополнение к неполному исправлению обхода middleware через segment-prefetch, который оставался возможен при обработке запроса через Turbopack. Пользователи без Turbopack были защищены уже на 16.2.5 / 15.5.16, а пользователи Turbopack — нет. Полное исправление находится в 16.2.6 / 15.5.18.

Для веток 13.x и 14.x патча не будет: Vercel не планирует бэкпорт. Единственное исправление — миграция на 15.x или 16.x, и оценивать её нужно именно как миграцию, а не как bun update. Для нетривиального приложения закладывайте минимум неделю: несовместимости реальны, особенно в matcher-правилах middleware и стандартном поведении кеша App Router.

После деплоя очистите edge-кеш. Этот шаг отсутствует во всех других материалах, которые я прочитал на этой неделе. Без purge RSC-пейлоад, попавший в кеш Cloudflare до установки патча, останется там. Если в период уязвимости кто-то воспользовался эксплойтом, пейлоад может быть отравлен и продолжит отдаваться с edge-узла до истечения s-maxage. В моей инфраструктуре очистка выглядит так:

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Затем проверьте результат. Возьмите маршрут с авторизацией через middleware, соберите URL в формате segment-prefetch из описания бюллетеня и повторите запрос к продакшену. В ответе должен быть 401 / 302 / любой другой статус, который middleware возвращает неавторизованному клиенту. Если приходит 200 с контентом, исправление middleware не применилось: проблема уже в деплое, а не в Next.js.

Что сломалось после перехода на 16.2.6

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

Более строгая работа matcher с .rsc и segment-prefetch URL. Исправление обхода через segment-prefetch изменило сопоставление matcher-правил. Если ваше правило зависело от прежнего формата — особенно если negative lookahead исключал пути _next и предполагалось, что .rsc всегда находится внутри них, — перепроверьте его. Мне пришлось расширить одно правило, чтобы оно явно захватывало суффикс segment-prefetch на защищённом маршруте. Исправление заняло пять минут, но без replay-теста регрессия осталась бы незаметной.

Обработка nonce в CSP. Исправление XSS (CVE-2026-44581) меняет передачу nonce при рендеринге App Router. Если nonce создаётся в middleware и используется в компоненте Script, после деплоя оставьте CSP в режиме report-only на сутки. У меня нарушений не появилось, но изменение реально, и я слышал об одной команде, которой пришлось обновить процесс генерации nonce.

Изменение поведения Cache Components. Если Cache Components включены и вы устанавливаете исправление DoS с исчерпанием соединений, учтите: теперь промахи кеша под нагрузкой объединяются иначе. Повторно протестируйте самые нагруженные пути. У меня Cache Components не используются, поэтому эта проверка не потребовалась.

Мой контрольный список перед тем, как считать обновление завершённым:

[ ] next version pinned to 16.2.6 in lockfile
[ ] middleware auth replay on /admin via segment-prefetch URL → 401
[ ] middleware auth replay via .rsc URL → 401
[ ] RSC cache key sanity: same URL, two clients, identical payload
[ ] forced edge purge after deploy
[ ] CSP report-only on for 24h with no new violations
[ ] one full revalidate cycle on a high-traffic page

Обязательно проведите прогон на staging. Это обновление нельзя считать безрисковым patch-релизом: исправления безопасности намеренно меняют маршрутизацию и поведение ключа кеша. Разница между деплоем во вторник днём и инцидентом во вторник ночью — в replay-тестах маршрутов авторизации до переключения продакшена.

Устанавливайте патч, а не полагайтесь на WAF

Для этого релиза Vercel не выпустил правил WAF. В журнале изменений прямо сказано, что единственная полная мера защиты — установка патча, и это обоснованно: эти уязвимости нельзя чисто отфильтровать на edge-уровне, потому что вредоносные запросы слишком похожи на легитимные. 6 мая Cloudflare выпустил правила WAF и меры защиты в адаптерах фреймворка как дополнительный уровень защиты, а не замену обновлению. Формулировка имеет значение: в журнале изменений Cloudflare прямо указано, что правила WAF снижают риск на время развёртывания, но не после него.

В этом и состоит главный системный урок недели. Если инфраструктура позволяет за один день обновить фреймворк, выполнить повторный деплой и очистить edge-кеш, согласованное раскрытие 13 CVE остаётся обычной задачей на вторник. Если нет — обновление требует миграции, отсутствует механизм purge или в конвейере деплоя есть ручные согласования — система остаётся уязвимой всё время, пока идёт развёртывание. Несколько дней. Иногда недель.

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

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