Сайт на Next.js может продолжать работать после обновления зависимостей и при этом оставаться уязвимым в одном конкретном сценарии: Server Action, маршрутизации, оптимизации изображений или серверном fetch. В июльском выпуске безопасности Next.js исправили четыре уязвимости высокой и пять средней степени опасности, а 3 августа вышел стабильный Next.js 16.3. Для владельца рабочего сайта это повод не запускать npm install next@latest прямо на сервере, а проверить фактическую версию, затронутые функции и план отката.
Сам номер версии не доказывает безопасность проекта. Важно подтвердить, какой код запущен в production, какие возможности Next.js реально используются и прошли ли после обновления критичные бизнес-сценарии.
Что изменилось к августу 2026 года
В июльском выпуске Next.js команда проекта рекомендовала обновить ветку 16.2 минимум до 16.2.11, а ветку 15.5 — минимум до 15.5.21. Исправления затронули App Router, Server Actions, middleware/proxy, rewrites() и redirects(), серверный fetch, Edge runtime и Image Optimization API.
Не каждая проблема применима к каждому сайту. Например, для части сценариев нужны Turbopack и определённая настройка локалей, пользовательский сервер, управляемый запросом внешний адрес или удалённые SVG-изображения. Поэтому правильная реакция состоит из двух частей: поставить исправленную версию и отдельно проверить, присутствуют ли опасные условия в архитектуре проекта.
В официальной июльской публикации также было указано, что исправления войдут в стабильную ветку 16.3. Она вышла 3 августа. Вместе с security-патчами этот релиз меняет работу сборочного кеша, серверного рендеринга, предварительной загрузки и обработки ошибок, а часть новых возможностей навигации остаётся подключаемой отдельно. Это значит, что переход на 16.3 нужно рассматривать как управляемое обновление фреймворка, а не только как замену одной цифры в package.json.
Кому это актуально
Проверка нужна проектам, где Next.js обслуживает не только статичные страницы, но и рабочие операции:
- интернет-магазинам с каталогом, корзиной, оплатой и личным кабинетом;
- B2B-порталам, CRM и внутренним панелям;
- сайтам с App Router, Server Actions или серверным кешированием;
- self-hosted-проектам за собственным reverse proxy;
- приложениям со сложными
rewrites,redirectsи внешними API; - проектам, где доступ к разделам проверяется через middleware;
- старым репозиториям без тестового контура и понятного регламента релиза.
Особенно важно не откладывать инвентаризацию, если подрядчик не может быстро назвать версию Next.js в рабочем контейнере, показать соответствующий lock-файл и объяснить, как вернуть предыдущий артефакт.
Какие риски закрывает плановое обновление
Остановка процесса из-за тяжёлого запроса
Одна из исправленных проблем связана с избыточной загрузкой процессора при специально сформированном запросе к приложению с Server Actions. Для пользователя это выглядит как долгий ответ или недоступность сайта, а для бизнеса — как потерянные входы, заявки и операции в кабинете.
Патч устраняет известный вектор, но после обновления всё равно нужны лимиты, наблюдение за временем ответа и проверка поведения приложения под ошибочными запросами. Если один процесс обслуживает все запросы, единичная тяжёлая операция не должна превращаться в незаметную остановку всего сервиса.
Обход проверки доступа
Отдельное исправление касается обхода middleware/proxy в определённой конфигурации App Router, Turbopack и локалей. Наличие middleware само по себе не является проблемой, но критичное действие не стоит защищать только на уровне раннего перенаправления.
Права нужно повторно проверять рядом с данными и бизнес-операцией: чтением заказа, изменением профиля, выгрузкой отчёта или административной командой. Тогда ошибка маршрутизации не становится единственной границей между внешним запросом и закрытой функцией.
Серверные запросы по управляемому адресу
Две уязвимости высокой степени опасности связаны с server-side request forgery — ситуацией, когда сервер можно заставить обратиться к нежелательному адресу. Условия различаются: в одном случае значение влияет на внешний адрес в правилах маршрутизации, в другом задействованы Server Actions на пользовательском сервере.
После патча полезно проверить, откуда берутся host-заголовки и адреса назначения, какие внутренние сети доступны приложению и действительно ли origin закрыт reverse proxy. Обновление фреймворка не отменяет правила минимального сетевого доступа.
Перегрузка изображениями и путаница кеша
Для self-hosted-проектов с разрешённой загрузкой удалённых изображений исправлена перегрузка Image Optimization API при обработке вредоносного SVG. Другие исправления относятся к кешированию ответов серверного fetch при запросах с телом.
Здесь недостаточно открыть главную страницу после релиза. Нужно проверить источники изображений, ограничения размера и времени обработки, а также маршруты, где тело запроса влияет на ответ: расчёт, поиск, персональные данные, корзину или интеграцию.
С какой версии начинать
Сначала определите фактическое состояние production. Сверьте версию в package.json, lock-файле, собранном контейнере или артефакте и журнале последнего деплоя. Если эти данные расходятся, обновлять «репозиторий вообще» бессмысленно: рабочий сайт может остаться на старой сборке.
Для веток из июльского бюллетеня минимальными исправленными версиями названы:
15.5.21для Maintenance LTS 15.5;16.2.11для Active LTS 16.2.
Стабильная 16.3 вышла позже и является отдельным маршрутом обновления. Если проект уже на 16.2 и хорошо покрыт тестами, можно оценить переход на 16.3. Если он находится на старой ветке, содержит пользовательский сервер или зависит от нестандартного кеширования, сначала нужен план совместимости. Команда должна выбрать поддерживаемую цель по официальной документации на дату работ, а не искать случайную версию из старого комментария.
Безопасный план обновления Next.js
1. Зафиксировать исходное состояние
Сохраните commit, lock-файл, версии Node.js и пакетного менеджера, параметры сборки и идентификатор текущего артефакта. Отдельно перечислите критичные маршруты: вход, заявка, поиск, корзина, оплата, создание заказа, webhook, обмен с CRM и административные действия.
2. Отделить security-патч от новых возможностей
Не включайте одновременно экспериментальную навигацию, новый кеш и исправления безопасности, если для этого нет отдельной задачи. Чем меньше независимых изменений в одном релизе, тем проще найти причину регрессии и выполнить откат.
3. Повторить production на тестовом контуре
Тестовая среда должна использовать тот же способ сборки, reverse proxy, важные переменные конфигурации и близкую схему интеграций. Секреты production копировать не нужно: достаточно безопасных тестовых доступов с минимальными правами.
4. Проверить затронутые участки
Помимо обычной сборки и автоматических тестов, проверьте:
- Server Actions и ограничение размера запроса;
- авторизацию в middleware и повторную проверку прав в серверной логике;
rewrites(),redirects()и пользовательский сервер;- источники изображений и маршрут
/_next/image; - серверный
fetchс телом запроса; - кеши, предварительную загрузку и поведение после повторного входа;
- внешние API, webhook и обмен с CRM.
5. Подготовить релиз и откат
Выкладывайте проверяемый артефакт, а не пересобирайте проект вручную на сервере. До начала релиза должно быть понятно, по каким признакам он останавливается, кто принимает решение и как возвращается предыдущая версия вместе с совместимой конфигурацией.
6. Наблюдать после выкладки
Проверьте ошибки 4xx/5xx, время ответа, загрузку процессора и памяти, сбои Server Actions и фактическое прохождение заявок. Технически успешный деплой не равен работающему бизнес-сценарию.
Не используйте реальную оплату, персональные данные и административные учётные записи в небезопасном тестовом окружении. Для проверки нужны подготовленные тестовые сценарии и доступы с ограниченными правами.
Как это решает OpenStart
OpenStart начинает с инвентаризации: какая версия реально работает, какие возможности Next.js задействованы, где находится авторизация, как устроены сборка, кеши, reverse proxy и интеграции. Затем обновление разбивается на проверяемые этапы: исправленная версия, тестовый контур, критичные сценарии, релиз, откат и наблюдение.
Для проекта на React и Next.js можно начать с аудита и доработки приложения. Если обновления нужно вести регулярно вместе с мониторингом, очередью задач и отчётностью, подходит техническая поддержка сайта.
Результат такой работы — не обещание, что сайт больше никогда не столкнётся с уязвимостью. Это понятный ответ на практические вопросы: что обновлено, какие риски применимы, какие маршруты проверены, как выполнен релиз и что делать при следующем бюллетене безопасности.
Что запросить у подрядчика
До согласования релиза попросите предоставить:
- фактическую версию Next.js в production и целевую версию;
- список применимых уязвимостей и объяснение условий риска;
- diff
package.jsonи lock-файла; - перечень изменений конфигурации, кеша и reverse proxy;
- отчёт по проверке входа, форм, оплаты, кабинета и интеграций;
- идентификатор собранного артефакта;
- план отката и критерии остановки релиза;
- результаты наблюдения после выкладки.
Фраза «обновили до последней версии» без этих данных не показывает, что рабочие сценарии действительно защищены.
FAQ
Нужно ли всем срочно ставить Next.js 16.3?
Не вслепую. Для веток 15.5 и 16.2 официальный июльский выпуск называет минимальные исправленные версии. Переход на стабильную 16.3 полезно оценить отдельно с учётом совместимости, сборки и тестов проекта.
Достаточно ли выполнить npm install next@latest?
Нет. Команда обновит зависимость, но не подтвердит версию в production, совместимость Node.js, работу интеграций и возможность отката. Сначала нужен тестовый релиз и проверка критичных маршрутов.
Проект на Vercel тоже нужно проверять?
Да. Управляемая платформа снимает часть инфраструктурных задач, но версия приложения, Server Actions, маршрутизация, права и бизнес-логика остаются ответственностью проекта. Self-hosted-среде дополнительно нужна проверка origin, reverse proxy и сетевого доступа.
Может ли WAF заменить обновление?
Нет. Правила веб-экрана могут временно снизить риск отдельных запросов, но не исправляют код фреймворка и не закрывают все условия эксплуатации. Патч и проверка приложения остаются обязательными.
Придётся ли переписывать сайт?
Обычно нет. Security-патч внутри поддерживаемой ветки часто можно провести как контролируемое обновление. Переработка нужна только там, где аудит выявит устаревшую ветку, небезопасную авторизацию, нестандартный сервер или накопившуюся несовместимость.
Официальные источники
- Next.js: July 2026 Security Release
- Next.js 16.3, 3 августа 2026 года
- Next.js Security Release Program
Материал проверен 17 августа 2026 года по официальным публикациям Next.js. Внутренние данные OpenStart, клиентские названия и неподтверждённые результаты не использовались.