Критические уязвимости Next.js в августе 2026: как обновить проект без остановки

25 августа 2026 года Next.js выпустил версии 15.5.24 и 16.3.3, закрывающие две критические уязвимости с возможностью удалённого выполнения кода без авторизации. Практический ответ для владельца проекта короткий: зафиксировать реальную версию в production, проверить два условия риска, обновить поддерживаемую ветку на тестовом контуре и только затем выкатывать проверяемый артефакт с планом отката.

Если проект попадает под условия официальных предупреждений, откладывать исправление нельзя. Но и запускать npm install next@latest вручную на рабочем сервере — плохой план: security-патч должен дойти до production без поломки входа, заявок, кабинета, изображений и интеграций.

Что произошло 25 августа 2026 года

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

• 15.5.24 — Maintenance LTS;
• 16.3.3 — Active LTS.

Это не одно общее предупреждение «обновитесь на всякий случай», а две разные ситуации с разными условиями применимости. Именно поэтому сначала нужна короткая инвентаризация, а затем обновление.

Удалённое выполнение кода при обработке AVIF

Предупреждение GHSA-2xp9-vwfh-vxw4 относится к библиотеке libheif, которую sharp использует в цепочке оптимизации изображений. Если встроенный Image Optimization API обрабатывает управляемое извне AVIF-изображение, уязвимость может привести к выполнению кода без авторизации.

По документации Next.js формат AVIF не включён по умолчанию: стандартное значение images.formats — image/webp. Но это не повод считать проект безопасным по памяти. Нужно проверить фактический next.config.js, пользовательские загрузки, удалённые источники изображений, собственный loader и реально собранную конфигурацию.

В исправленных версиях оптимизация AVIF временно отключена, пока исправление распространяется по цепочке зависимостей. Самостоятельно подменять отдельные вложенные пакеты на production без проверки lock-файла не стоит: можно получить сборку, которую невозможно повторить и откатить.

Удалённое выполнение кода на Windows-серверах

Уязвимость CVE-2026-75604 / GHSA-p293-qw3h-jr36 касается приложений, которые одновременно используют Pages Router и App Router без Cache Components и запущены на файловой системе Windows. Linux и macOS не затронуты именно этой проблемой, однако к ним всё ещё может относиться отдельная уязвимость обработки AVIF.

Для уязвимых Windows-конфигураций официальный advisory не указывает обходного решения: требуется обновление. Это не означает, что проект обязательно нужно срочно переносить на другую операционную систему. Сначала ставят исправленную версию и проверяют рабочие сценарии; изменение инфраструктуры — отдельное решение с собственными рисками.

Кому это актуально

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

• интернет-магазинам с каталогом, корзиной, оплатой и изображениями товаров;
• личным кабинетам, B2B-порталам и внутренним сервисам;
• сайтам с пользовательской загрузкой изображений или удалёнными медиакаталогами;
• self-hosted-приложениям на собственных серверах и в контейнерах;
• проектам, где одновременно остались Pages Router и App Router;
• старым репозиториям без воспроизводимой сборки, тестового контура и понятного отката;
• системам, связанным с CRM, внешними API, webhook и мобильными приложениями.

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

Какие риски закрывает обновление

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

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

Третий риск — ложное чувство безопасности. Обновлённый package.json ещё не подтверждает, что новая версия попала в контейнер, запущена на всех экземплярах и прошла проверку после выкладки.

Безопасная первичная проверка

1. Зафиксировать фактическую версию

Сверьте package.json, lock-файл, журнал сборки, образ контейнера и запущенный артефакт. Если значения расходятся, сначала восстановите цепочку «исходный код → сборка → production». Иначе команда может обновить репозиторий, а сайт продолжит работать на старом образе.

Для поддерживаемых веток целевыми исправленными версиями из августовского выпуска являются:

npm install next@15.5.24
# или
npm install next@16.3.3

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

2. Проверить условия риска без эксплуатации

Для AVIF-сценария посмотрите:

• есть ли image/avif в images.formats;
• принимает ли сайт изображения от пользователей;
• может ли внешний адрес попасть в оптимизатор изображений;
• применяются ли remotePatterns, собственный loader или медиапрокси;
• какой код реально обслуживает маршрут /_next/image.

Для Windows-сценария зафиксируйте операционную систему production-хоста, наличие Pages Router и App Router и использование Cache Components. Проверять это нужно по конфигурации и артефакту, а не отправкой публичного proof of concept на рабочий сайт.

Не запускайте эксплойты и специально сформированные вредоносные изображения против production. Безопасная первичная проверка — это инвентаризация версии и условий. Активное тестирование допустимо только в изолированном контуре и с явным разрешением владельца системы.

3. Отделить патч от других доработок

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

4. Повторить критичные сценарии на тестовом контуре

Минимальная проверка должна охватывать:

• сборку и запуск приложения тем же способом, что на production;
• вход, выход и восстановление сессии;
• права доступа в Pages Router и App Router;
• загрузку и выдачу локальных и удалённых изображений;
• карточки товара, поиск, корзину и оформление заказа;
• формы, уведомления, CRM и webhook;
• серверный рендеринг, кеш и повторную загрузку страниц;
• ошибки 4xx/5xx и поведение при недоступной интеграции.

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

5. Подготовить выкладку и откат

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

6. Наблюдать после обновления

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

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

Когда можно обойтись без OpenStart

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

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

Как это решает OpenStart

OpenStart начинает не с обещания «быстро обновить пакет», а с карты применимости: версия в production, операционная система, обработка изображений, роутеры, кеш, сборка, интеграции и доступный откат. Затем изменение разбивается на проверяемые этапы: исправленная зависимость, тестовый артефакт, приёмка критичных сценариев, выкладка и наблюдение.

Для разового разбора Next.js-проекта подходит аудит и доработка приложения. Если обновления зависимостей, мониторинг и проверка заявок должны стать регулярным процессом, полезно выстроить техническую поддержку сайта.

Результат такой работы — не гарантия отсутствия будущих уязвимостей. Это проверяемый ответ: какая версия запущена, какие условия риска найдены, какие сценарии приняты и как команда вернёт рабочее состояние при регрессии.

Что запросить у подрядчика

До согласования релиза попросите предоставить:

• фактическую и целевую версии Next.js;
• перечень применимых advisories с условиями, а не только их названия;
• результат проверки images.formats, источников изображений и /_next/image;
• операционную систему хоста и карту Pages Router / App Router;
• diff package.json и lock-файла;
• идентификатор собранного артефакта;
• протокол проверки входа, форм, кабинета, изображений и интеграций;
• план отката и критерии остановки релиза;
• результаты наблюдения после выкладки.

Фраза «поставили последнюю версию» без этих данных не показывает, что исправление дошло до production и рабочие сценарии сохранились.

FAQ

Нужно ли обновляться, если AVIF не включён и сервер работает на Linux?

Условия двух уязвимостей могут к проекту не относиться одновременно, но поддерживаемую ветку всё равно следует привести к официальной исправленной версии. Сначала подтвердите конфигурацию, затем проведите обычное контролируемое обновление. Linux не затронут Windows-уязвимостью, но операционная система сама по себе ничего не говорит о медиаконтуре.

Можно ли просто отключить AVIF?

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

Достаточно ли веб-экрана или правила CDN?

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

Нужно ли переносить Windows-проект на Linux?

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

Когда нужен разбор инцидента, а не обычное обновление?

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

Официальные источники

• Next.js: August 2026 Security Release
• GitHub Advisory: AVIF Image Optimization API
• GitHub Advisory: Windows-hosted servers
• Next.js Image: настройка форматов

Материал проверен 29 августа 2026 года по официальным публикациям Next.js и GitHub. Внутренние данные OpenStart, клиентские названия и неподтверждённые результаты не использовались.

Если версия production, медиаконтур или откат не подтверждены, следующий соразмерный шаг — техническая диагностика Next.js-проекта: сначала определить применимость advisories и безопасный маршрут обновления, а уже затем менять рабочую систему.