Имя плагина	@nuxt/nitro-server
Тип уязвимости	Межсайтовый скриптинг (XSS)
Номер CVE	CVE-2026-46342
Срочность	Низкий
Дата публикации CVE	2026-05-20
Исходный URL-адрес	CVE-2026-46342

Порча общего кэша ‘__nuxt_island’ Nuxt Nitro (CVE-2026-46342) — что нужно знать владельцам сайтов на WordPress

Автор: Команда безопасности WP-Firewall
Дата: 2026-05-20
Теги: безопасность, WordPress, WAF, Nuxt, безголовый, CVE-2026-46342

Краткое содержание: Недавно раскрытая уязвимость в сервере Nuxt Nitro затрагивает версии >= 4.2.0 и <= 4.4.5. Это может привести к порче общего кэша и межсайтовому скриптингу (XSS) через __nuxt_island конечную точку. Проблема исправлена в 4.4.6. Если ваш сайт на WordPress интегрируется с JavaScript фронтендами, безголовыми архитектурами, рендерингом на краевых CDN или использует компоненты Nuxt/Nitro в вашем инструментальном наборе, это уведомление объясняет риск, методы обнаружения, меры по смягчению (включая экстренные правила брандмауэра/края) и стратегии укрепления цепочки поставок в долгосрочной перспективе.

---

Почему это важно для владельцев сайтов на WordPress

Большинство сайтов на WordPress используют PHP-шаблоны и рендеринг на стороне сервера через стек WordPress. Однако все большее количество сайтов на WordPress интегрируется с современными JavaScript фронтендами (Nuxt, Next, Remix) для повышения производительности и удобства разработчиков — это “безголовая” или “разделенная” архитектура. Эти фронтенды обычно полагаются на серверы на базе Node, промежуточное ПО Nitro и краевые кэши/CDN.

Сообщенная проблема (CVE-2026-46342) затрагивает конечную точку сервера Nitro, используемую фронтендами Nuxt: __nuxt_island. Когда сервер не связывает ответы плотно с свойствами исходного запроса, общий кэш может предоставить ответ, созданный для одного пользователя, другому пользователю. Если этот ответ содержит контент, контролируемый злоумышленником (например, несанизированный HTML или фрагменты скриптов), злоумышленник может отравить кэши и вызвать межсайтовый скриптинг для многих посетителей сайта.

Даже если ваш бэкенд WordPress не работает напрямую на Node, системы WordPress могут быть затронуты, когда:

• Ваш сайт на WordPress использует фронтенд Nuxt или Nitro, который получает данные из REST API WordPress или GraphQL.
• Ваша хостинг-среда использует рендеринг на стороне сервера или услуги рендеринга на крае, которые включают компоненты на базе Nitro.
• Ваш CI/CD, конвейер сборки или сторонние сервисы используют уязвимый пакет для генерации предварительных просмотров, развертывания фронтендов или рендеринга страниц на крае.

Это уведомление написано с точки зрения безопасности WordPress. Мы сосредоточимся на практических шагах по обнаружению и устранению, которые вы можете применить немедленно, а также на долгосрочных стратегиях укрепления и рекомендациях по WAF/правилам края.

---

Технический обзор — что сломано

На высоком уровне:

• The __nuxt_island конечная точка отвечает за рендеринг или гидратацию изолированных компонентов (маленьких интерактивных фрагментов) в гибридной модели рендеринга Nuxt.
• Уязвимое поведение: ответы, возвращаемые конечной точкой, недостаточно связаны со свойствами запроса (источник, заголовки, куки, параметры запроса). Если уровень кэширования (CDN, обратный прокси или общий кэш на стороне сервера) сохраняет этот ответ без соответствующих заголовков Vary/Cache-Control или ключей кэша, кэшированный ответ может быть предоставлен другим запросам, которые отличаются по критическим свойствам запроса.
• Если злоумышленник может создать запрос, который включает контролируемый злоумышленником контент (например, через внедренные свойства, полезные нагрузки в параметрах запроса или отраженные данные из ответов API) и заставить этот ответ быть закэшированным, злоумышленник может отравить общий кэш. Когда другие пользователи получают этот кэшированный ответ, любой вредоносный скрипт внутри будет выполняться в их браузерах (сценарий отраженного или сохраненного XSS) — что приведет к широкомасштабному воздействию, поскольку кэши обслуживают многих пользователей.

Конечный результат: один эксплойт может превратиться в массовый XSS через одну отравленную кэшированную страницу или фрагмент острова.

---

Поверхность атаки для сайтов на WordPress

Вот общие схемы интеграции, которые подвергают сайты на WordPress этой проблеме:

• Headless WordPress + фронтенд на Nuxt:
  • WordPress предоставляет контент через REST API / GraphQL.
  • Фронтенд на Nuxt использует Nitro для серверного рендеринга островов, которые включают контент из WP.
  • Уязвимый пакет Nitro, используемый в процессе фронтенда, может вызвать отравление кэша.
• Рендеринг на краю / предварительный просмотр CDN / генерация OG-изображений:
  • Некоторые генераторы предварительного просмотра на краю или конечные точки изображений включают рендеринг на основе Nitro.
  • Если ваш хостинг-провайдер или CI использует компоненты Nitro, эти конечные точки могут быть затронуты.
• Инструменты для разработчиков:
  • Системы сборки и предварительного просмотра (storybook, SSR-превью, генераторы статических сайтов), которые устанавливают уязвимую зависимость, могут создавать или загружать отравленные артефакты или кэшированный вывод.
• Интеграции с третьими сторонами:
  • Поставщики плагинов, разработчики тем или поставщики headless-сервисов могут запускать предварительные просмотры на основе Nitro. Если они скомпрометированы или используют уязвимые версии, сайты клиентов могут быть затронуты косвенно.

Если ваш сайт на WordPress является чисто классическим (без headless-фронтенда, без инструментов Node в развертываниях), риск значительно ниже. Но в современных DevOps-средах стоит проверить.

---

Как злоумышленники могут это эксплуатировать (практические сценарии)

• Отраженный XSS через кэшированный фрагмент острова:
  • Злоумышленник отправляет специально подготовленный запрос на __nuxt_island с параметром, контролируемым злоумышленником.
  • Nitro генерирует фрагмент, содержащий параметр, без соответствующей санитарной обработки.
  • CDN кэширует фрагмент для общего ключа.
  • Последующие посетители получают кэшированный фрагмент; вредоносный JavaScript выполняется в их браузере.
• Хранение, подобное отравлению, через данные верхнего уровня:
  • Если фронтенд отображает данные из стороннего API или из системы комментариев, которая принимает пользовательский ввод, злоумышленник сохраняет вредоносный ввод в этом источнике.
  • Сервер отображает остров с вредоносным контентом; ответ кэшируется и позже предоставляется другим.
• Масштабное злоупотребление:
  • Кэши на краю означают, что один кэшированный объект может повлиять на тысячи посетителей. Злоумышленники предпочитают маршруты отравления кэша, поскольку влияние усиливается.

---

Патч и обновление — самое важное исправление

Если вы используете Nuxt/Nitro в любой части вашего стека, немедленно обновите затронутый пакет:

• Затронутый: @nuxt/nitro-server ≥ 4.2.0 и ≤ 4.4.5
• Исправлено в: 4.4.6 (обновитесь до 4.4.6 или более поздней версии)

Действия:

1. Для проектов, использующих npm/yarn/pnpm:
   • Запустите npm install @nuxt/nitro-server@^4.4.6 (или обновите ваш package.json и запустите ваш менеджер пакетов).
   • Обновите файлы блокировки (package-lock.json, yarn.lock, pnpm-lock.yaml) и зафиксируйте их.
2. Для контейнеризованных сборок:
   • Восстановите образы и разверните их после обновления пакета и lockfile.
   • Избегайте полагаться на неявные последние версии — используйте зафиксированные версии и часто восстанавливайте образы.
3. Для сервисов на краю или предварительных, которые вы не контролируете:
   • Свяжитесь с вашим провайдером или владельцем сервиса и запросите подтверждение патча.
   • Попросите их обновить до 4.4.6+ и аннулировать кэши после патча.

Если вы не можете обновить немедленно, используйте приведенные ниже меры.

---

Немедленные меры, которые вы можете применить сейчас (даже до патча)

Это практические меры, которые вы можете быстро реализовать для снижения уязвимости.

1. Отключите общий кэш для конечной точки острова
   • Убедитесь, что ответы от __nuxt_island помечены как некэшируемые общими кэшами:
   • Установите Cache-Control: частный, без кэша, без хранения, необходимо повторно проверять (выберите подходящую директиву для вашей среды).
   • Добавлять Варьируйте заголовки, чтобы включить cookies/авторизацию/хост, если ответы зависят от них: Vary: Cookie, Authorization, Accept-Encoding, Host.
   • Если вы контролируете правила CDN, создайте правило для обхода кэша для любого пути, соответствующего /__nuxt_island или что-то подобное.
2. Виртуальное патчирование с вашими правилами WAF / на краю
   • Создайте одно или несколько правил брандмауэра для блокировки или проверки запросов к /__nuxt_island которые содержат подозрительные полезные нагрузки:
   • Блокируйте запросы, содержащие <script, onerror=, загрузка=, закодированные токены скриптов (например, <script), или явные шаблоны XSS в строках запроса.
   • Ограничьте скорость или используйте CAPTCHA для аномальных запросов к этому пути.
   • Если возможно, блокируйте запросы, где Принять заголовки указывают на рендеринг HTML плюс подозрительные значения запроса.
   • Пример правила в стиле ModSecurity (концептуально):

   SecRule REQUEST_URI "@contains /__nuxt_island" "id:100001,phase:1,log,deny,ctl:forceRequestBodyVariable=On,msg:'Block suspicious island requests'"
   SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS|REQUEST_COOKIES "(?i)(<script|onerror=|onload=|javascript:|%3Cscript)" "id:100002,phase:2,log,deny,msg:'XSS pattern in request args targeting island endpoint'"
         

   Адаптируйте идентификаторы и уровень серьезности к вашей среде. Тестируйте перед блокировкой в производстве.

3. Очистите кэши
   • Если вы считаете, что произошло отравление (или в качестве меры предосторожности), очистите кэши на всех уровнях:
     • Кэши на краю CDN
     • Кэши обратного прокси (Varnish)
     • Кэши приложений (если есть)
   • Используйте заголовки для разрушения кэша или версионирование для фрагментов острова, если необходимо.
4. Добавьте политику безопасности контента (CSP)
   • Реализуйте или ужесточите CSP для страниц, которые включают фрагменты острова:
     • Пример: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none'; base-uri 'self';
     • Строгий CSP может ограничить влияние XSS, даже если злоумышленник внедрит тег скрипта.
5. Увеличьте проверку/санитизацию ответов
   • На стороне сервера (Nuxt или downstream-сервисы) убедитесь, что любые данные, включенные в ответы, правильно экранированы или очищены перед тем, как они будут включены в HTML, рендеренный на сервере.
6. Мониторинг журналов и трафика
   • Ищите резкие увеличения запросов к __nuxt_island.
   • Проверьте на наличие повторяющихся шаблонов в строках запроса или телах POST, которые содержат токены скриптов.
   • Мониторьте шаблоны попаданий в кэш на краю и ключи кэша.

---

Предложения по правилам WAF и краевым правилам (конкретные)

Ниже приведены практические правила, которые вы можете адаптировать. Они намеренно общие и должны быть протестированы сначала на этапе подготовки.

Фрагмент Nginx для установки заголовков кэша для конечной точки острова:

location ~* /__nuxt_island {

Простые правила ModSecurity (концептуальные):

# Deny requests containing obvious XSS patterns to island endpoint
SecRule REQUEST_URI "@contains /__nuxt_island" "phase:2,chain,id:900100,msg:'Block XSS patterns to island endpoint'"
  SecRule REQUEST_BODY|ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_HEADERS "(?i)(<script|%3Cscript|onerror=|onload=|javascript:)" "t:none,deny,log"

Укрепление ответа через краевого работника (псевдокод):

• Перехватить ответы для /__nuxt_island.
• Если ответ содержит <script или подозрительный встроенный JS И запрос не имеет надлежащей аутентификации или ожидаемого заголовка, отклонить/оспорить ответ и не кэшировать.
• В противном случае убедитесь, что ответ имеет Cache-Control: частный.

Укрепление ключа кэша:

• Убедитесь, что ключи кэша включают свойства, специфичные для пользователя, где контент варьируется (Cookie, заголовок Authorization, Accept-Language и т. д.). Неправильно настроенный ключ кэша, который игнорирует куки, является основной причиной отравления.

Ограничение скорости:

• Применяйте ограничения по количеству запросов к __nuxt_island, например, 5 запросов в минуту на IP, чтобы уменьшить вероятность попыток отравления.

Помните: принимайте поэтапные меры на этапе подготовки и следите за ложными срабатываниями. Правила WAF являются грубыми инструментами; тестируйте, чтобы избежать нарушения легитимного трафика.

---

Обнаружение: как узнать, затронуты ли вы

1. Проверьте свой стек
   • Поиск в вашем коде, конфигурациях CI/CD и журналах сборки на наличие ссылок на @nuxt/nitro-server, nuxt, nitro, и __nuxt_island.
   • Использовать npm ls @nuxt/nitro-server или эквивалент для перечисления установленных версий.
   • Проверять package-lock.json, yarn.lock, pnpm-lock.yaml чтобы найти временные зависимости.
2. Проверьте журналы сервера и CDN
   • Ищите трафик к путям, таким как /__nuxt_island (или аналогичные конечные точки острова/гидратации).
   • Ищите запросы с подозрительными строками запроса, содержащими скрипт, onerror, или закодированные варианты (%3C, <).
3. Просмотрите кэшированные ответы
   • Получите кэшированный HTML для страниц и проверьте на наличие внедренных <script> тегов или встроенных обработчиков событий, которые вы не создавали.
   • Если ваш CDN поддерживает проверку кэша, проверьте кэшированные объекты на наличие необычного контента.
4. Автоматизированное сканирование
   • Запустите сканеры зависимостей (npm audit, инструменты SCA), чтобы найти уязвимые версии пакетов.
   • Используйте веб-сканеры (детекторы XSS), чтобы безопасно проверять конечные точки рендеринга на этапе тестирования.

---

Если вы думаете, что вас атаковали — немедленные шаги по реагированию на инциденты

1. Уберите уязвимую конечную точку из публичного кэширования:
   • Временно установить Cache-Control: no-store на конечных точках острова.
   • Очистить кэши по всему CDN и прокси.
2. Пересобрать и запатчить:
   • Обновлять @nuxt/nitro-server до 4.4.6+.
   • Пересобрать контейнеры и развернуть заново.
3. Сдерживать и расследовать:
   • Изолировать подозрительные серверы или процессы.
   • Сохранить логи за период подозреваемого отравления.
   • Определить и перечислить затронутые ключи кэша и очистить их.
4. Очистите и укрепите:
   • Удалить или очистить любые вредоносные нагрузки, сохраненные в источниках данных.
   • Поменять секреты, которые могли быть раскрыты.
   • Переоценить CSP и очистку ввода.
5. Сообщите:
   • Если данные пользователей были под угрозой или эксплойт стал публичным, следуйте вашей политике раскрытия инцидентов и уведомите заинтересованные стороны.

---

Долгосрочное укрепление цепочки поставок и развертывания для владельцев WordPress

• Поддерживать инвентаризацию зависимостей:
  • Отслеживать зависимости Node и PHP, используемые вашим сайтом и вашим CI-пайплайном.
  • Периодически проводить сканирование SCA (Анализ состава программного обеспечения) по всем пакетам.
• Закрепить и заблокировать зависимости:
  • Используйте точные версии в пакет.json для критически важных пакетов.
  • Коммитите файлы блокировок и регулярно выполняйте пересборки.
• Автоматизируйте обновления:
  • Используйте автоматизированные инструменты (в стиле renovate или запланированные аудиты) для предложения обновлений; тестируйте и разворачивайте регулярно.
  • Рассмотрите возможность автоматизированного конвейера, который пересобирает образы и выполняет интеграционные тесты, когда выходят патчи зависимостей.
• Ограничьте поверхность кэширования:
  • Включайте агрессивное общее кэширование только для действительно статических ресурсов.
  • Для динамических фрагментов или персонализированных фрагментов пользователей используйте Cache-Control: частный или обходите кэширование.
• Укрепите рендеринг на стороне клиента:
  • Убедитесь, что фрагменты, рендеренные на сервере, по умолчанию экранируют пользовательские данные.
  • Используйте шаблонные движки, которые автоматически экранируют, или явно очищайте опасные поля.
• Требуйте безопасные заголовки:
  • CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, Strict-Transport-Security — обеспечьте их соблюдение на всем сайте.
• Мониторинг и ведение журнала:
  • Сводные журналы для доступа к конечным точкам и поведения кэша помогают быстрее обнаруживать аномалии.
  • Мониторьте события WAF/edge и регулярно пересматривайте правила.

---

Конкретные рекомендации для WordPress (практический контрольный список)

• Если ваш сайт безголовый:
  • Подтвердите, какие версии и пакеты фронтенда используются; обновите Nitro при необходимости.
  • Убедитесь, что ваши ответы REST API WordPress правильно кодируют и очищают HTML-поля.
  • Убедитесь, что среды предварительного просмотра и CI так же защищены, как и производственная среда.
• Если ваш сайт использует Jamstack или SSR-пipeline (например, Netlify, Vercel, другие провайдеры):
  • Свяжитесь с вашим провайдером для подтверждения статуса пакета Nitro в их средах.
  • Очищайте кэши на краях после обновлений.
• Если ваш сайт — это классический WordPress, но вы полагаетесь на сторонние плагины или сервисы, которые могут рендерить страницы на краю:
  • Проверьте уведомления и обновления у поставщиков плагинов.
  • Спросите команды хостинга или платформы о использовании Nitro в их стеке.

---

Сигналы мониторинга, на которые стоит обратить внимание в ближайшие недели

• Увеличение количества запросов __nuxt_island с полезными нагрузками, которые включают закодированные <script> формы.
• Внезапное появление встроенных скриптов в кэшированном HTML, предоставляемом вашим CDN.
• Повышенное количество срабатываний правил WAF/edge, связанных с конечными точками острова.
• Сообщения о всплывающих окнах, перенаправлениях или неожиданном javascript на страницах, которые ранее были статичными.

Если вы видите эти признаки, относитесь к ним серьезно: очищайте кэши, применяйте виртуальные патчи и обновляйте пакеты.

---

Защитите свой сайт бесплатно — начните с WP-Firewall Basic

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

Что вы получаете с базовым (бесплатным) планом:

• Управляемый брандмауэр, защищающий общие поверхности атак
• WAF для блокировки распространенных инъекций и XSS-шаблонов
• Сканер вредоносного ПО для обнаружения подозрительных внедренных полезных нагрузок
• Неограниченная пропускная способность и непрерывное сканирование
• Покрытие рисков, связанных с 10 основными рисками OWASP

Зарегистрируйтесь и активируйте бесплатный план, чтобы добавить защитный слой, пока вы применяете патч Nuxt/Nitro и шаги по усилению безопасности: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Пример: Как мы бы реагировали на уровне WAF (оперативная инструкция)

1. Триаж:
   • Определите, использует ли сайт уязвимые версии Nitro.
   • Если да, немедленно включите набор правил WAF, нацеленный на шаблоны XSS для island-path.
2. Примените правила виртуального патча:
   • Временно пометьте /__nuxt_island ответы как некэшируемые для общих кэшей через край.
   • Добавьте входящие правила для блокировки запросов, содержащих токены скриптов.
3. Уведомление:
   • Уведомите владельцев сайтов и разработчиков об обновлении до 4.4.6+.
   • Запланируйте окно развертывания для обновления зависимостей и пересборки контейнеров.
4. Проверка:
   • После развертывания обновления + правил WAF запустите автоматизированный тестовый пакет и смоделированные XSS-пробы на этапе тестирования.
   • После успешного прохождения тестов удалите чрезмерно строгие правила WAF, которые могут блокировать действительный трафик, и полагайтесь на исправление на стороне сервера.
5. Посмертный анализ:
   • Проверьте, почему ключ кэша или заголовки Vary были неправильно настроены.
   • Улучшите контроль развертывания, чтобы обеспечить более быстрое применение обновлений зависимостей.

---

Часто задаваемые вопросы (кратко)

В: Мой сайт — классический WordPress без фронтенда на Node — я подвержен риску?
О: Если в вашем стеке нет компонентов Nuxt/Nitro, ваше прямое воздействие минимально. Но проверьте инструменты разработчика, службы предварительного просмотра или CDN, используемые вашим сайтом, на наличие использования Nitro.

В: Я обновился до 4.4.6, но все еще вижу подозрительные скрипты на кэшированных страницах — что дальше?
О: Очистите кэши на всех уровнях (край, CDN, обратный прокси). Обновление может не удалить ранее закэшированные зараженные ресурсы автоматически.

В: Может ли Политика безопасности контента полностью устранить это?
О: CSP снижает влияние внедренных скриптов, но не решает проблему отравления кэша. Используйте CSP + управление кэшем + патчи для полного устранения.

В: Насколько срочно это обновление?
О: Это важно: уязвимость имеет низкую степень серьезности по CVSS, но может быть использована для масштабируемых атак отравления кэша, которые затрагивают многих пользователей. Приоритизируйте патчи, если вы используете Nuxt/Nitro в любой части вашей цепочки поставок.

---

Окончательные рекомендации — контрольный список приоритетов

1. Инвентаризация: Ищите использование Nitro/Nuxt на вашем сайте, в CI и у провайдера хостинга.
2. Патч: Обновите @nuxt/nitro-server до 4.4.6+ везде, где это появляется.
3. Защита: Применяйте правила WAF и устанавливайте заголовки Cache-Control/Vary, чтобы предотвратить использование общего кэша для динамических фрагментов.
4. Очистка: Очищайте кэши на CDN и на краевых уровнях.
5. Укрепление: Реализуйте/усильте CSP, очищайте контент, рендеренный на сервере, и убедитесь, что ключи кэша различаются по заголовкам, чувствительным к пользователю.
6. Автоматизация: Добавьте рутинные сканирования SCA и автоматические обновления зависимостей в ваш конвейер.

---

Если вы хотите получить оперативный справочник, адаптированный к вашей архитектуре хостинга WordPress (классический против безголового против гибридного), наша команда безопасности может сопоставить шаги с вашим стеком и предоставить рекомендуемые фрагменты правил WAF и тестовые скрипты, которые вы можете запустить на этапе тестирования перед развертыванием в производственной среде.