Cloudflare WAF для Next.js RCE: beta-правила в Block

Cloudflare WAF для Next.js RCE получил важное обновление 8 сентября 2026 года. Cloudflare сообщил, что активные beta-сигнатуры для двух сценариев удалённого выполнения кода в Next.js были объединены с базовыми правилами Managed Ruleset, а действие для beta-правил изменилось с Log на Block.

Речь идёт о защите от CVE-2026-75604 и отдельной критической уязвимости Next.js Image Optimizer, связанной с обработкой специально подготовленных AVIF-изображений. Для владельцев self-hosted Next.js это хороший повод проверить сразу два слоя: версию самого Next.js и фактическую конфигурацию WAF.

Что именно изменил Cloudflare 8 сентября

В официальном changelog Cloudflare указано, что две beta-сигнатуры, которые ранее работали в режиме журналирования, теперь переведены в Block и объединены с основными правилами.

beta-правило для Next.js Image Optimizer Remote Code Execution через crafted AVIF объединено с исходным правилом защиты от этой уязвимости;
beta-правило для Next.js Remote Code Execution, связанное с CVE-2026-75604, объединено с базовым правилом для этого CVE;
для обеих beta-сигнатур действие изменено с Log на Block.

Это не означает, что Cloudflare «починил Next.js». WAF анализирует входящие запросы и может блокировать известные вредоносные шаблоны. Исправление самой уязвимости остаётся задачей обновления приложения.

Почему это продолжение августовского emergency-релиза

26 августа Cloudflare выпустил экстренное обновление WAF: существующая сигнатура Next.js RCE была уточнена для обнаружения CVE-2026-75604, а для уязвимости Image Optimizer через AVIF появилось отдельное правило. В сентябрьском релизе Cloudflare уже консолидировал beta-детекторы с базовыми сигнатурами.

По данным Cloudflare, CVE-2026-75604 относится к Windows-hosted Next.js-приложениям с определённой комбинацией Pages Router и App Router без Cache Components. Уязвимость может приводить к неаутентифицированному удалённому выполнению кода.

Что известно об AVIF-уязвимости Next.js

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

В официальном advisory указаны исправленные версии 15.5.24 и 16.3.3. Для ветки 15 уязвимыми указаны версии от 10.0.0 до 15.5.23, а для ветки 16 — версии до 16.3.3.

Почему WAF нельзя считать заменой обновлению

Managed WAF полезен как дополнительный слой, особенно когда приложение нельзя обновить в ту же минуту. Но он находится перед приложением и работает по правилам обнаружения. Сам уязвимый код при этом остаётся в проекте.

Надёжная последовательность для production выглядит так: сначала определить, затронута ли текущая версия, затем обновить Next.js до исправленной версии, прогнать тесты и deployment, а WAF оставить как дополнительную защиту на периметре.

Что проверить владельцу Next.js-приложения

точную установленную версию пакета next в lock-файле и production-сборке;
где реально работает приложение — на Windows, Linux или managed-платформе;
используется ли Image Optimization для AVIF и может ли источник изображения контролироваться внешним пользователем;
обновлён ли Next.js минимум до исправленной версии своей ветки;
включён ли Cloudflare Managed Ruleset для нужной зоны;
нет ли собственных overrides или exceptions, которые возвращают нужное правило в Log/Skip;
есть ли в Security Events срабатывания по Next.js RCE после обновления правил.

Как проверить версию без догадок

Не стоит ориентироваться только на запись в package.json. Диапазон вроде ^16.2.0 сам по себе не говорит, какая версия сейчас развернута. Проверять лучше lock-файл, результат установки зависимостей и фактический build/deployment.

Если проект собирается в CI, полезно зафиксировать вывод версии на этапе сборки и убедиться, что production действительно получил новый deployment. Обновлённый репозиторий и старый работающий контейнер — две разные реальности.

Что проверить в Cloudflare

Сам факт использования Cloudflare DNS ещё не означает, что конкретное приложение защищается нужным Managed Ruleset. Нужно смотреть настройки зоны, активные managed rules и исключения.

Если ранее beta-сигнатуры стояли в Log для наблюдения, после релиза 8 сентября стоит проверить фактическое действие уже объединённых базовых правил. Особенно это важно в проектах с собственными overrides, где действие могло быть изменено вручную.

Нужно ли отключать AVIF

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

Самостоятельно строить долгосрочную защиту только вокруг блокировки одного формата не стоит. Уязвимая зависимость должна быть устранена обновлением.

Что делать, если обновление нельзя поставить сразу

Если production зависит от старой версии и немедленное обновление требует тестирования, можно временно усилить периметр: проверить Managed WAF, ограничить ненужные публичные точки входа и внимательно следить за security-событиями. Но такой режим должен быть временным.

После обновления важно проверить не только старт приложения, но и критические маршруты, Server Actions, кеширование, Image Optimization и собственные middleware. Для сложных проектов лучше прогнать smoke-тесты до переключения трафика.

Что этот релиз показывает о современной веб-безопасности

Один production-проект часто защищается сразу несколькими слоями: исправлениями фреймворка, зависимостями, CI/CD, WAF, сетевыми ограничениями и мониторингом. Ошибка возникает, когда один слой начинают считать полной заменой всем остальным.

Cloudflare быстро добавляет и уточняет сигнатуры, а Next.js выпускает исправленные версии. Владелец приложения должен связать эти действия в собственный процесс обновления: узнать о проблеме, проверить применимость, обновить код, развернуть сборку и оставить дополнительную защиту на edge.

Я уже писал о том, как команда Next.js использует автоматизацию и проверяемые процессы при работе с большим техническим backlog: Next.js и AI-агент для GitHub issues. А практический пример использования Cloudflare Workers как отдельного инфраструктурного слоя есть в кейсе VK-бота без собственного VPS.

Частые вопросы

Cloudflare теперь автоматически защищает любой Next.js-сайт?

Нет. Релиз относится к правилам Cloudflare Managed Ruleset. Защита конкретного проекта зависит от того, проходит ли трафик через Cloudflare, включены ли соответствующие managed rules и нет ли исключений или переопределений.

Можно не обновлять Next.js, если WAF стоит в Block?

Нет. WAF — дополнительная мера. Основное исправление — обновление Next.js до версии, в которой уязвимость устранена.

Какие версии указаны как исправленные для AVIF RCE?

Официальный advisory Next.js указывает версии 15.5.24 и 16.3.3.

Что изменилось именно 8 сентября?

Cloudflare объединил активные beta-сигнатуры для двух Next.js RCE-сценариев с базовыми правилами и перевёл действие beta-правил из Log в Block.

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

Итог

Релиз Cloudflare от 8 сентября — не новая уязвимость, а усиление и консолидация уже добавленной защиты для двух критических Next.js RCE-сценариев. Для self-hosted проектов правильная реакция состоит из двух действий: установить исправленный Next.js и проверить, что WAF действительно работает в ожидаемом режиме.

Если нужно разобрать production-конфигурацию, обновление приложения или безопасный deployment без догадок, можно описать задачу A.S Groups и приложить текущую версию, схему хостинга и способ развёртывания.

Следующий шаг

Нужно решить похожую задачу?

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

Обсудить задачу