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

Команда Next.js выпустила обновления 15.5.21 и 16.2.11, закрывающие девять уязвимостей в серверной части фреймворка. Четыре проблемы получили высокий уровень опасности, ещё пять — средний. Ошибки позволяют отправлять запросы во внутренние сети, обходить проверку доступа в отдельных конфигурациях, перегружать процессор и память, смешивать кэшированные ответы и раскрывать идентификаторы серверных функций.

Next.js 16.2.11 относится к ветке Active LTS, то есть активной долгосрочной поддержки. Версия 15.5.21 выпущена для ветки Maintenance LTS, где продолжают выходить критические исправления. Патчи также включены в предварительные сборки 16.3.0-canary.92 и 16.3.0-preview.7.

Пакет объединяет разные классы уязвимостей. Наличие Next.js в проекте ещё не означает, что приложение подвержено каждой из них.

Часть проблем возникает только при использовании App Router и Server Actions. Для других необходим самостоятельно размещённый сервер, особые правила rewrites() или обработка удалённых изображений. Обход проверки доступа затрагивает исключительно Next.js 16 с Turbopack и необычной настройкой локализации.

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

CVE-2026-64645 получила 8,3 балла по шкале CVSS 4.0. Проблема находилась в правилах rewrites() и redirects(), если имя внешнего сервера строилось из данных запроса.

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

module.exports = {

  async rewrites() {

    return [

      {

        source: '/:tenant',

        destination: 'https://:tenant.api.example.com',

      },

    ]

  },

}

Владелец приложения мог рассчитывать, что запрос всегда отправится на поддомен api.example.com. Специально подобранное значение позволяло изменить фактическое имя узла и направить сервер на другой адрес.

При использовании rewrites() запрос выполнял сам сервер Next.js. Ответ возвращался пользователю через исходный домен приложения. Такой сценарий относится к SSRF — подделке серверного запроса. Атакующий потенциально мог обратиться к локальным службам, внутренним панелям, метаданным облачной виртуальной машины или другому узлу, недоступному напрямую из интернета.

Уязвимость затрагивает версии от 12.0.0 до 15.5.20 включительно и от 16.0.0 до 16.2.10. Статический внешний адрес безопасен с точки зрения этой конкретной ошибки. Необходимое условие — пользовательские данные попадают именно в имя узла назначения.

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

Ошибка в redirects() использует тот же недостаток проверки, но её последствия отличаются.

Rewrite заставляет сервер самостоятельно обратиться к выбранному адресу. Redirect возвращает браузеру команду перейти на другой сайт. Во втором случае возникает открытое перенаправление: злоумышленник формирует ссылку с доверенным начальным доменом, после чего браузер отправляет пользователя на посторонний ресурс.

Такую схему удобно применять в фишинге. Человек видит знакомый адрес в письме или сообщении, открывает ссылку и оказывается на поддельной странице.

Называть оба варианта SSRF некорректно. SSRF относится к rewrites(), открытое перенаправление — к redirects(). Официальный бюллетень разделяет эти последствия.

CVE-2026-64649 также оценена в 8,3 балла. Она затрагивает Server Actions — серверные функции, которые клиентская часть Next.js может вызывать через HTTP-запрос.

При перенаправлении или пересылке Server Action фреймворк определял исходный адрес приложения через заголовки, связанные с Host. Если внешний пользователь мог контролировать Host или X-Forwarded-Host, Next.js рисковал отправить исходящий запрос на сервер злоумышленника.

Ошибка проявляется в основном на собственных Node.js-серверах и в конфигурациях без обратного прокси, который фиксирует имя узла. Управляемые платформы с принудительной установкой Host не затронуты. Стандартный запуск через next start и автономная сборка закрепляют исходный адрес начиная с Next.js 14.2.

Уязвимые версии:

• от 14.1.1 до 15.5.20;

• от 16.0.0 до 16.2.10.

До обновления нужно проверять и принудительно задавать Host и X-Forwarded-Host на внешнем прокси. В Next.js 14.2 и новее можно также указать настоящий адрес приложения через переменную __NEXT_PRIVATE_ORIGIN.

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

CVE-2026-64642 позволяет специально сформированному запросу обойти проверку доступа, реализованную через Middleware или Proxy. Ошибка получила 8,3 балла, но её поверхность атаки заметно уже, чем может показаться из кратких пересказов.

Приложение должно одновременно:

• использовать App Router;

• работать на Next.js 16;

• быть собрано с Turbopack;

• содержать ровно одну запись в config.i18n.locales.

Если авторизация зависит только от Middleware или Proxy, атакующий может добраться до страницы без ожидаемой предварительной проверки. Уязвимы версии от 16.0.0 до 16.2.10. Ветка Next.js 15 в официальном бюллетене не указана.

CVE-2026-64641 получила 8,2 балла. Специальный запрос к приложению с App Router и хотя бы одной Server Action мог вызвать чрезмерную загрузку процессора.

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

Уязвимы версии:

• от 13.0.0 до 15.5.20;

• от 16.0.0 до 16.2.10.

Проекты на Pages Router и приложения без Server Actions не затронуты. Надёжной временной меры разработчики не предложили: официальная рекомендация сводится к обновлению.

Ограничение частоты запросов способно уменьшить риск массовой эксплуатации, но не устраняет саму ошибку обработки.

CVE-2026-64646 связана с Server Actions, работающими в Edge Runtime. Фреймворк не обеспечивал достаточного ограничения тела входящего запроса, из-за чего специально отправленные данные могли вызвать чрезмерное потребление памяти.

Для эксплуатации нужны App Router и хотя бы одна Server Action, настроенная на Edge Runtime. Обычная Server Action в Node.js Runtime не попадает под условия именно этого бюллетеня.

Уязвимы Next.js от 13.0.0 до 15.5.20 и от 16.0.0 до 16.2.10. Ошибка получила 6,3 балла.

При невозможности обновиться ограничение нужно установить на уровне хостинга, сети доставки контента или обратного прокси. Официальная рекомендация — принимать тела запросов размером не более 5 МиБ.

Контроль должен срабатывать до передачи запроса в Next.js. Проверка уже внутри Server Action не предотвратит первоначальное выделение памяти для входящих данных.

CVE-2026-64644 затрагивает программный интерфейс оптимизации изображений /_next/image. Подготовленный SVG-файл мог вызвать ресурсоёмкую обработку и истощить процессорное время.

Официальный бюллетень говорит об истощении процессора. Конкретный результат зависит от конфигурации процесса, количества запросов, тайм-аутов и механизмов перезапуска.

Уязвимость возникает только при самостоятельном размещении Next.js с обычным загрузчиком изображений и разрешённой оптимизацией удалённых ресурсов. Внешние адреса должны быть настроены через images.remotePatterns.

Не затронуты проекты:

• на Vercel;

• с images.unoptimized: true;

• с images.loader: 'custom'.

Проблема появилась в Next.js 15.5.0. Уязвимы версии 15.5.0–15.5.20 и 16.0.0–16.2.10. Более ранние выпуски ветки 15 в этом конкретном бюллетене не перечислены.

Временная мера — включить экспериментальную настройку:

experimental: {

  imgOptSkipMetadata: true

}

Она пропускает ресурсоёмкий этап обработки метаданных. Полной заменой обновления этот параметр не является.

CVE-2026-64648 получила 6 баллов и затрагивает серверный fetch() в App Router.

Проблема возникает, когда код создаёт объект Request с одним набором параметров, а затем передаёт в fetch() другой набор настроек. В такой конфигурации Next.js мог использовать неправильный ключ кэша и вернуть тело ответа, сохранённое для другого запроса к тому же адресу.

Сам исходящий запрос не устранялся как повторный. Ошибка касалась именно выбора кэшированного ответа.

При наличии персональных данных в ответе на POST содержимое, предназначенное одному пользователю, могло попасть другому запросу. Для эксплуатации приложение должно использовать серверный fetch() с телом, кэшированием и несовпадающими наборами параметров.

Уязвимы версии от 13.0.0 до 15.5.20 и от 16.0.0 до 16.2.10. Pages Router не затронут. Временной меры, кроме обновления, нет.

CVE-2026-64647 относится к похожей ошибке кэширования, но требует тела запроса в кодировке, отличной от UTF-8.

Разные последовательности байтов могли преобразоваться в одинаковое представление и получить общий ключ кэша. После этого Next.js рисковал вернуть ответ, сохранённый для другого тела запроса к тому же адресу.

Официальный бюллетень приводит пример двух разных строк в UTF-16, которые могли попасть в один кэш. Проблема требует нестандартной кодировки и специально подобранных данных, поэтому сложность атаки оценена выше.

Уязвимы версии:

• от 13.0.0 до 15.5.20;

• от 16.0.0 до 16.2.10.

Pages Router не затронут. До установки патча можно ограничиться телами в UTF-8 — это стандартный вариант для Next.js.

CVE-2026-64643 раскрывает внутренние идентификаторы Server Functions неавторизованным пользователям. Она затрагивает App Router и серверные функции с директивами use server или use cache.

Next.js может помещать ссылки на Server Actions в общедоступные клиентские фрагменты JavaScript. Страница, где функция используется, при этом способна находиться за авторизацией. Атакующий получает возможность извлечь идентификатор из статического файла, не открывая саму защищённую страницу.

Идентификатор не является паролем, токеном или пользовательской информацией. Сам по себе он обычно служит инструментом разведки: показывает, какие серверные точки вызова существуют в приложении.

Риск возрастает, если функция полагается на авторизацию страницы и не проверяет права внутри собственного кода. Зная идентификатор, атакующий может попытаться вызвать Server Action напрямую.

Уязвимы версии от 13.0.0 до 15.5.20 и от 16.0.0 до 16.2.10. Исправление вошло в 15.5.21 и 16.2.11.

Главное правило защиты остаётся прежним: каждая функция с use server и граница use cache должна самостоятельно проверять пользователя и его права.

Обновление нужно установить всем пользователям уязвимых версий, но первоочередной аудит требуется проектам, которые:

• строят внешний адрес rewrites() или redirects() из параметров запроса;

• используют Server Actions на собственном сервере;

• позволяют клиенту влиять на Host или X-Forwarded-Host;

• полагаются на Middleware как на единственный слой авторизации;

• запускают Server Actions в Edge Runtime;

• самостоятельно оптимизируют удалённые SVG;

• кэшируют серверные fetch() с телами;

• используют Server Actions без проверки прав внутри функции.

Pages Router не затронут уязвимостями Server Actions, раскрытием их идентификаторов и двумя ошибками кэша. Он всё же может быть подвержен CVE-2026-64645 при опасной настройке rewrites() или redirects().

Для ветки 15 исправления находятся в Next.js 15.5.21: npm install next@15.5.21

Для ветки 16 нужно установить Next.js 16.2.11: npm install next@16.2.11

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

Изменение номера в package.json не обновит уже работающий контейнер или сервер. Версию следует проверить непосредственно в производственной сборке.

Отдельных исправленных выпусков для веток 12, 13 и 14 в июльских бюллетенях нет. Проекты на них нужно переводить на поддерживаемую ветку 15.5.21 или 16.2.11. При этом Next.js 12 затронута только ошибкой динамических rewrites() и redirects(), а большинство остальных проблем начинается с версии 13 или 14.

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

Июльский выпуск стал первым релизом новой программы плановых обновлений Next.js. Команда заранее объявляет дату пакета, чтобы разработчики могли подготовить тестовую среду и окно развёртывания.

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

Модель упрощает планирование, но требует дисциплины. Команде нужно заранее резервировать время на обновление зависимостей, повторную сборку, проверку Server Actions и тестирование правил маршрутизации.

Вопросы и ответы

Сколько уязвимостей закрыла команда Next.js?

Июльский выпуск исправляет девять проблем: четыре высокого и пять среднего уровня опасности.

Какие версии содержат исправления?

Патчи вошли в Next.js 15.5.21 и 16.2.11. Они также присутствуют в предварительных выпусках 16.3.0-canary.92 и 16.3.0-preview.7.

Уязвимы ли 15.5.21 и 16.2.11?

Нет. Это исправленные версии. Уязвимые диапазоны заканчиваются на 15.5.20 и 16.2.10.

Нужно ли обновлять Next.js 14?

Да. Отдельных исправленных сборок ветки 14 в этих бюллетенях нет. Следует перейти на 15.5.21 или 16.2.11.

Любое правило rewrite позволяет провести SSRF?

Нет. Уязвимость требует внешнего адреса, имя узла которого строится из контролируемого пользователем значения. Статический адрес под условия CVE-2026-64645 не попадает.

Обход авторизации работает во всех приложениях?

Нет. Требуются Next.js 16, App Router, сборка Turbopack и ровно одна запись в config.i18n.locales. Авторизация при этом должна зависеть от Middleware или Proxy.

Затронуты ли проекты на Vercel?

Vercel официально не затронут уязвимостью оптимизации SVG. SSRF в Server Actions также не действует на управляемом размещении, где входной Host закрепляется платформой. Остальные ошибки нужно оценивать отдельно.

Может ли ошибка кэша раскрыть пользовательские данные?

Да, если приложение выполняет серверные запросы с телом, кэширует ответы и попадает под специальные условия CVE-2026-64648 или CVE-2026-64647. Ответ на один запрос может быть возвращён другому.

Достаточно ли выполнить npm install?

После обновления пакет нужно заново собрать и развернуть. Производственный процесс должен фактически работать на исправленной версии.

Известны ли реальные атаки?

Официальные бюллетени не сообщают о подтверждённых случаях эксплуатации на 23 июля 2026 года.