25 августа 2026 года команда Next.js выпустила версии 15.5.24 и 16.3.3 для двух критических уязвимостей, способных привести к удалённому выполнению кода без аутентификации. Одна связана с обработкой AVIF-изображений, вторая — с размещением Next.js на Windows. Владельцу рабочего сервиса важно быстро проверить фактическую версию и условия эксплуатации, но обновлять production следует через тестовый контур, проверку бизнес-сценариев и готовый откат.
Если проект попадает в затронутый диапазон, не откладывайте проверку. При этом сам номер версии ещё не доказывает компрометацию: сначала подтвердите конфигурацию, журналы и целостность среды, а затем проводите контролируемое обновление.
Что произошло 25 августа 2026 года
В официальном сообщении Next.js опубликованы исправления 16.3.3 для Active LTS и 15.5.24 для Maintenance LTS. Выпуск перенесли на день раньше первоначального плана после обнаружения второй критической проблемы.
Первая уязвимость описана в GHSA-2xp9-vwfh-vxw4. Она находится в цепочке Next.js → sharp → libheif и проявляется, когда Image Optimization API обрабатывает AVIF. Специально подготовленное изображение может привести к выполнению кода на сервере. В исправленных версиях оптимизация AVIF временно отключена до распространения исправления нижележащей библиотеки.
Вторая уязвимость — GHSA-p293-qw3h-jr36 / CVE-2026-75604. Она затрагивает приложения с Pages Router или App Router без Cache Components, если сервер работает на файловой системе Windows. Для уязвимых Windows-конфигураций разработчики не указывают обходного решения и рекомендуют немедленно обновиться.
Кому это актуально
Проверка нужна владельцам и техническим руководителям проектов, где Next.js обслуживает доступные из интернета сценарии:
- серверный рендеринг страниц и личные кабинеты;
- каталоги, поиск, корзину и оформление заказа;
- API сайта или мобильного приложения;
- авторизацию, формы, платежи и обмен с CRM;
- загрузку или преобразование пользовательских изображений;
- собственный Windows-сервер, виртуальную машину или контейнер с Windows-файловой системой.
Даже если главная страница выглядит статической, приложение может использовать API Routes, Server Actions, middleware или /_next/image. Проверять нужно production-сборку и инфраструктуру, а не название технологии в старом техническом задании.
Если инвентаризация подтверждает, что Next.js в production нет, AVIF не проходит через Image Optimization API, а сервер не работает на Windows, срочность именно этих двух сценариев ниже. Но вывод стоит зафиксировать ссылкой на конфигурацию и версию: предположение «у нас это вроде не используется» не является проверкой.
Какие риски закрывает управляемое обновление
Выполнение чужого кода на сервере
Обе опубликованные проблемы относятся к удалённому выполнению кода. Потенциальные последствия включают чтение или изменение файлов, запуск процессов, нарушение работы сервиса и развитие атаки в пределах доступных приложению прав. Конкретный ущерб зависит от окружения, поэтому права процесса, секреты, сетевые доступы и изоляцию контейнера нужно оценивать отдельно.
Простой после поспешного патча
Сайт может вернуть HTTP 200 после обновления, но перестать создавать заказ, сохранять сессию, обрабатывать изображение или передавать заявку в CRM. Проверка одной страницы создаёт ложное чувство безопасности. Нужен короткий набор тестов, повторяющий путь пользователя и данных.
Ложное подтверждение версии
Версия из локального package.json не всегда совпадает с тем, что запущено на сервере. Старый lock-файл, кеш сборки, другой контейнер или ручной запуск процесса могут оставить production на уязвимой сборке даже после принятого pull request.
Потеря доказательств при подозрении на атаку
Если в журналах уже есть необычные запросы, неизвестные процессы или изменения файлов, обычная переустановка пакета может затруднить расследование. Сначала сохраните журналы, временную шкалу, контрольные суммы и снимок затронутой среды; не публикуйте секреты и не продолжайте работу на потенциально скомпрометированном узле.
Что проверить в первую очередь
1. Фактическую версию и способ запуска
Проверяйте тот образ и процесс, которые обслуживают production. Для первичной инвентаризации пригодятся:
node --version
npm ls next sharpСопоставьте вывод с package.json, lock-файлом, Dockerfile, базовым образом, менеджером процессов и журналом последней выкладки. Результат должен отвечать на три вопроса: какая версия реально запущена, где собран артефакт и какую сборку можно вернуть.
2. Попадает ли проект в условия уязвимости
Для AVIF-сценария уведомление указывает Next.js от 10.0.0 до 15.5.23 включительно и ветку 16.x до 16.3.2 включительно. Проверьте, используется ли встроенный Image Optimization API и может ли недоверенный AVIF попасть в обработку.
Для Windows-сценария затронуты версии от 13.4 до 15.5.23 и от 16.0 до 16.3.2 при размещении на Windows и использовании Pages Router либо App Router без Cache Components. Для этой конфигурации официальный advisory не предлагает временного обхода.
3. Поддерживаемую линию обновления
Проект на Next.js 15.x следует переводить как минимум на 15.5.24, а проект на 16.x — как минимум на 16.3.3. Старые основные версии нельзя механически перескочить одной командой на рабочем сервере: сначала оцените несовместимости и подготовьте миграцию на поддерживаемую ветку.
Не устанавливайте случайные форки или пакеты с похожими названиями. Сверяйте версию с официальным реестром и advisory, фиксируйте lock-файл и собирайте новый артефакт в доверенном контуре.
4. Критичные маршруты
Составьте список сценариев, которые нельзя потерять: вход, восстановление доступа, заявка, заказ, оплата, загрузка изображения, API для мобильного приложения, вебхук, очередь и передача данных в CRM. Рядом укажите ожидаемый результат и место подтверждения — интерфейс, журнал приложения, тестовую очередь или безопасный стенд интеграции.
Как обновить Next.js без остановки сервиса
- Создайте отдельную ветку и обновите Next.js до исправленной версии в подходящей поддерживаемой линии.
- Пересоберите проект с зафиксированным lock-файлом и чистым кешем.
- Запустите модульные, интеграционные и браузерные тесты.
- Разверните сборку на staging, сходном с production по ОС, прокси и способу запуска.
- Проверьте критичные маршруты, обработку изображений, API, фоновые задачи и интеграции.
- Сохраните предыдущий образ и однозначное условие отката.
- Выпустите обновление в согласованное окно, по возможности постепенно.
- Повторно подтвердите фактическую версию в production и наблюдайте ошибки, время ответа, перезапуски и очереди.
После обновления AVIF может отдаваться без оптимизации — это ожидаемое защитное поведение исправленных версий на момент публикации advisory. Проверьте не только безопасность, но и размер изображений, скорость страниц, нагрузку и работу CDN, чтобы временное изменение не стало неожиданной проблемой для пользователей.
Если обнаружены признаки компрометации, одного обновления недостаточно. Нужны изоляция узла, сохранение доказательств, смена доступных приложению секретов из чистого контура, проверка целостности кода и зависимостей, восстановление из доверенного источника и наблюдение после возврата в работу.
Как это решает OpenStart
OpenStart может провести диагностику Next.js- или Node.js-проекта как отдельную задачу либо включить её в регулярное сопровождение. Начинаем с фактических версий и карты критичных сценариев, проверяем применимость официальных уведомлений, готовим тестовый выпуск, откат и контроль после релиза.
Для серверного рендеринга, API, очередей и интеграций подходит разработка и поддержка Node.js-проектов. Если проблема шире одной зависимости и нужен постоянный процесс обновлений, мониторинга и отчётности, следующий шаг — техническая поддержка сайта.
Мы не считаем работу завершённой только потому, что пакет установился. Результат подтверждают версия в production, пройденные бизнес-сценарии, отсутствие новых ошибок в журналах и понятный отчёт с оставшимися рисками.
Что запросить у подрядчика
- фактические версии Next.js, Node.js и
sharpво всех production-компонентах; - ссылку на официальный advisory и таблицу применимости к вашей конфигурации;
- перечень критичных маршрутов и протокол их проверки;
- описание staging без production-секретов и персональных данных;
- точную целевую версию и зафиксированный lock-файл;
- план выкладки, предыдущий артефакт и условие отката;
- результаты проверки журналов и целостности, если были признаки атаки;
- итоговый отчёт с версиями, тестами и оставшимися ограничениями.
Фраза «все зависимости обновлены» без перечня версий и результатов тестов не даёт владельцу проекта контроля. Хороший отчёт позволяет другому специалисту понять, что изменилось и как действовать при следующем уведомлении.
Частые вопросы
Нужно ли обновлять Next.js немедленно?
Если production попадает в затронутый диапазон, проверку и подготовку релиза нужно начать сразу. Для уязвимой Windows-конфигурации официального обходного решения нет. Сам выпуск проводите контролируемо: с тестами, предыдущим артефактом и наблюдением после релиза.
Достаточно ли отключить AVIF?
Исправленные версии временно отключают оптимизацию AVIF, но ручную настройку нельзя считать универсальной заменой обновлению. Сначала примените официальный патч, затем проверьте фактический путь изображений, CDN и производительность.
Уязвим ли любой сайт на Next.js?
Нет. Применимость зависит от версии, Image Optimization API, формата входных изображений, операционной системы и конфигурации роутера. Но эту неприменимость нужно подтвердить по production-среде, а не предполагать.
Нужно ли одновременно обновлять Node.js?
Не обязательно в одном релизе, однако фактическую версию Node.js и её поддержку проверить нужно. Next.js-патч не исправляет уязвимости runtime, а обновление Node.js не заменяет исправление Next.js.
Как понять, что обновление прошло успешно?
Нужны три группы подтверждений: в production работает ожидаемая версия, критичные пользовательские и интеграционные сценарии пройдены, а журналы и метрики не показывают новых ошибок или деградации. Зелёная главная страница этого не доказывает.
Вывод
Августовский выпуск Next.js — не повод переписывать проект в панике, но и не обычное обновление «когда будет время». Зафиксируйте версию и конфигурацию, сопоставьте их с двумя официальными advisory, подготовьте исправленную сборку на staging и подтвердите работу заявок, заказов, API и изображений после релиза.
Если у команды нет карты зависимостей, тестового контура или проверенного отката, начните с технической диагностики. Она поможет отделить подтверждённый риск от предположений и провести срочное изменение без потери управляемости.