Nuxt Nitro ‘__nuxt_island’ Shared-Cache Poisoning (CVE-2026-46342) — What WordPress Site Owners Need to Know

Resumen: A recently disclosed vulnerability in the Nuxt Nitro server impacts versions ≥ 4.2.0 and ≤ 4.4.5. It can lead to shared-cache poisoning and Cross-Site Scripting (XSS) via the __nuxt_island endpoint. El problema se corrige en 4.4.6. Si su sitio de WordPress se integra con front-ends de JavaScript, arquitecturas sin cabeza, renderizado en el borde de CDN, o utiliza componentes de Nuxt/Nitro en su cadena de herramientas, este aviso explica el riesgo, métodos de detección, mitigaciones (incluidas reglas de firewall/edge de emergencia) y estrategias de endurecimiento de la cadena de suministro a largo plazo.

Por qué esto es importante para los propietarios de sitios de WordPress

La mayoría de las implementaciones de WordPress siguen siendo basadas en PHP con renderizado del lado del servidor desde la pila de WordPress. Sin embargo, cada vez más, los operadores en Hong Kong y la región están utilizando front-ends modernos de JavaScript (Nuxt, Next, Remix) para mejorar el rendimiento y los flujos de trabajo de desarrollo — una arquitectura sin cabeza o desacoplada. Esos front-ends comúnmente dependen de servidores basados en Node, middleware de Nitro y cachés/CDNs en el borde.

El problema reportado (CVE-2026-46342) afecta a un endpoint del servidor Nitro utilizado por front-ends de Nuxt: __nuxt_island. Cuando las respuestas no están estrechamente vinculadas a las propiedades de la solicitud de origen, una caché compartida puede servir una respuesta creada para un usuario a otro. Si esa respuesta contiene contenido controlado por el atacante (por ejemplo, HTML no sanitizado o fragmentos de script), un atacante puede envenenar cachés y activar Cross-Site Scripting para muchos visitantes del sitio.

Incluso si su backend de WordPress no está ejecutando directamente Node, los sistemas de WordPress pueden verse afectados cuando:

• Su sitio de WordPress utiliza un front-end de Nuxt o Nitro que extrae datos de la API REST de WordPress o GraphQL.
• Su entorno de hosting utiliza servicios de renderizado del lado del servidor o renderizado en el borde que incluyen componentes basados en Nitro.
• Su CI/CD, pipeline de construcción o servicios de terceros utilizan el paquete vulnerable para generar vistas previas, desplegar front-ends o renderizar páginas en el borde.

Este aviso adopta una postura pragmática con un tono de experto en seguridad de Hong Kong: directo, operativo y centrado en lo que los propietarios y operadores de sitios deben hacer ahora.

Technical overview — what’s broken

• El __nuxt_island el endpoint renderiza o hidrata componentes aislados (pequeños fragmentos interactivos) en el modelo de renderizado híbrido de Nuxt.
• El comportamiento vulnerable: las respuestas del endpoint no están suficientemente vinculadas a las propiedades de la solicitud (origen, encabezados, cookies, parámetros de consulta). Si una capa de caché almacena esa respuesta sin los encabezados Vary/Cache-Control apropiados o claves de caché, la respuesta en caché puede ser servida a otras solicitudes que difieren en propiedades críticas de la solicitud.
• Si un atacante puede crear una solicitud que incluya contenido controlado por el atacante (por ejemplo, a través de propiedades inyectadas o datos reflejados) y hacer que esa respuesta sea almacenada en caché, el atacante puede envenenar la caché compartida. Cuando otros usuarios reciben esa respuesta en caché, cualquier script malicioso se ejecutará en sus navegadores — resultando en un impacto potencialmente generalizado.

El resultado final: un solo exploit exitoso puede convertirse en un XSS masivo a través de un fragmento de isla en caché envenenado.

Superficie de ataque para sitios de WordPress

Patrones de integración comunes que exponen a los sitios impulsados por WordPress a este problema:

• WordPress sin cabeza + front-end de Nuxt:
  • WordPress sirve contenido a través de REST API / GraphQL.
  • El front-end de Nuxt utiliza Nitro para renderizar en el servidor islas que incluyen contenido de WP.
  • Un paquete de Nitro vulnerable utilizado en el proceso del front-end puede causar envenenamiento de caché.
• Renderizado en el borde / vista previa de CDN / generación de imágenes OG:
  • Algunos generadores de vista previa en el borde o puntos finales de imágenes incluyen renderizado basado en Nitro.
  • Si su proveedor de hosting o CI utiliza componentes de Nitro, esos puntos finales pueden verse afectados.
• Herramientas para desarrolladores:
  • Sistemas de construcción y vista previa (storybook, vistas previas de SSR, generadores de sitios estáticos) que instalan la dependencia vulnerable pueden crear o cargar artefactos envenenados o salida en caché.
• Integraciones de terceros:
  • Los proveedores de plugins, constructores de temas o proveedores de servicios sin cabeza podrían estar ejecutando vistas previas basadas en Nitro. Si están utilizando versiones vulnerables, los sitios de los clientes pueden verse afectados indirectamente.

If your WordPress site is purely classic (no headless front-end, no Node tooling in deployments), the risk is much lower. But in modern DevOps environments it’s worth checking.

Cómo los atacantes pueden explotarlo (escenarios prácticos)

• XSS reflejado a través de fragmento de isla en caché:
  • El atacante envía una solicitud manipulada a __nuxt_island con un parámetro controlado por el atacante.
  • Nitro genera un fragmento que contiene el parámetro sin la sanitización adecuada.
  • La CDN almacena en caché el fragmento para una clave compartida.
  • Los visitantes posteriores reciben el fragmento en caché; el JavaScript del atacante se ejecuta en sus navegadores.
• Envenenamiento similar al almacenado a través de datos ascendentes:
  • Si el front-end renderiza datos de una API de terceros o entrada de usuario (por ejemplo, comentarios), un atacante almacena entrada maliciosa en la parte superior.
  • El servidor renderiza la isla con el contenido malicioso; la respuesta se almacena en caché y luego se sirve a otros.
• Abuso a gran escala: Las cachés de borde significan que un solo objeto en caché puede afectar a miles de visitantes; las rutas de envenenamiento de caché amplifican el impacto.

Parchear y actualizar: la solución más importante.

Si usas Nuxt/Nitro en alguna parte de tu pila, actualiza el paquete afectado de inmediato:

• Afectados: @nuxt/nitro-server ≥ 4.2.0 and ≤ 4.4.5
• Corregido en: 4.4.6 — actualiza a 4.4.6 o posterior

Acciones:

1. Para proyectos que usan npm/yarn/pnpm:
   • Ejecuta npm install @nuxt/nitro-server@^4.4.6 (o actualiza package.json y ejecuta tu gestor de paquetes).
   • Actualiza los archivos de bloqueo (package-lock.json, yarn.lock, pnpm-lock.yaml) y confírmalos.
2. Para construcciones en contenedores:
   • Reconstruye las imágenes y vuelve a desplegar después de actualizar el paquete y el archivo de bloqueo.
   • Evita depender de versiones implícitas más recientes: usa versiones fijas y reconstruye imágenes con frecuencia.
3. Para servicios de borde o de vista previa que no controlas:
   • Contacta a tu proveedor o propietario del servicio y solicita confirmación de la aplicación del parche.
   • Pídeles que actualicen a 4.4.6+ y que invaliden las cachés después de aplicar el parche.

Si no puedes actualizar de inmediato, aplica las mitigaciones a continuación.

Mitigaciones inmediatas que puedes aplicar ahora (incluso antes de aplicar parches)

Medidas prácticas que puedes implementar rápidamente para reducir la exposición:

1. Deshabilitar el almacenamiento en caché compartido para el punto final de la isla
   • Asegúrate de que las respuestas de __nuxt_island estén marcadas como no almacenables en caché por cachés compartidos:
     • Establecer Cache-Control: privado, sin caché, sin almacenamiento, debe volver a validar (elige las directivas apropiadas para tu entorno).
     • Agregar Vary encabezados para incluir cookies/autorización/anfitrión si las respuestas dependen de ellas: Vary: Cookie, Autorización, Aceptar-Codificación, Host.
   • Si controlas las reglas de CDN, crea una regla para omitir la caché para cualquier ruta que coincida con /__nuxt_island o similar.
2. Patching virtual con WAF / reglas de borde
   • Crea reglas de firewall para bloquear o desafiar solicitudes a /__nuxt_island que contengan cargas útiles sospechosas:
     • Bloquee solicitudes que contengan <script, onerror=, onload=, encoded script tokens (%3Cscript), or obvious XSS patterns in query strings.
     • Rate-limit or CAPTCHA-challenge anomalous requests to that path.
   • Ejemplo de reglas estilo ModSecurity (conceptuales):

   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'"
   

   Adapt IDs and severity to your environment. Test before production-blocking.

3. Purge caches
   • If poisoning may have occurred (or as precaution), purge caches at all tiers:
     • CDN edge caches
     • Reverse proxy caches (Varnish)
     • Application caches
   • Use cache-busting headers or versioning for island fragments if necessary.
4. Add Content Security Policy (CSP)
   • Implement or tighten CSP for pages that include island fragments:
     • Ejemplo: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none'; base-uri 'self';
   • A strict CSP can limit the impact of XSS even if an attacker injects a script tag.
5. Increase response validation/sanitization
   • On the server side (Nuxt or downstream services), ensure any data bound into responses is properly escaped or sanitized before inclusion in server-rendered HTML.
6. Monitorear registros y tráfico
   • Look for sudden increases in requests to __nuxt_island.
   • Inspect for recurring patterns in query strings or POST bodies that include script tokens.
   • Monitor edge cache hit patterns and cache keys.

WAF and edge rule suggestions (concrete)

Below are practical rules and snippets you can adapt. They are intentionally generic and should be tested in staging first.

Nginx snippet to set cache headers for island endpoint:

location ~* /__nuxt_island {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    add_header Cache-Control "private, no-cache, no-store, must-revalidate";
    add_header Vary "Cookie, Authorization, Accept-Encoding, Host";
}

Regla conceptual de 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"

Response-hardening via edge worker (pseudo-code):

• Intercept responses for /__nuxt_island.
• Si la respuesta contiene <script or suspicious inline JS AND the request lacks expected authentication or headers, drop/challenge response and do not cache.
• Otherwise, ensure response has Cache-Control: private.

Cache key hardening: Ensure cache keys include user-specific properties where content varies (Cookie, Authorization header, Accept-Language, etc.). A misconfigured cache key that ignores cookies is a major root cause of poisoning.

Limitación de tasa: Apply rate limits on requests to __nuxt_island, e.g., 5 requests per minute per IP, to reduce poisoning feasibility.

Note: WAF rules are blunt instruments — take incremental steps in staging and monitor for false positives to avoid breaking legitimate traffic.

Detection: how to know if you are affected

1. Inventory your stack
   • Search your codebase, CI/CD configurations, and build logs for references to @nuxt/nitro-server, nuxt, nitro, y __nuxt_island.
   • Uso npm ls @nuxt/nitro-server or equivalent to list installed versions.
   • Check lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) to find transient dependencies.
2. Inspect server and CDN logs
   • Look for traffic to paths like /__nuxt_island (or similar island/hydration endpoints).
   • Look for requests with suspicious query strings containing script, onerror, or encoded variants (%3C, <).
3. Review cached responses
   • Fetch cached edge HTML for pages and inspect for injected <script> tags or inline event handlers that you did not author.
   • If your CDN supports cache inspection, verify cached objects for unusual content.
4. Escaneo automatizado
   • Run dependency scanners (npm audit, SCA tools) to locate vulnerable package versions.
   • Use web scanners (XSS detectors) to probe render endpoints safely in staging.

If you think you’ve been hit — immediate incident steps

1. Take the vulnerable endpoint out of public caching
   • Temporarily set Cache-Control: no-store on island endpoints.
   • Purge caches across CDN and proxies.
2. Rebuild & patch
   • Actualiza @nuxt/nitro-server to 4.4.6+.
   • Rebuild containers and redeploy.
3. Contener e investigar
   • Isolate suspicious servers or processes.
   • Dump logs for the time window of suspected poisoning.
   • Identify and list affected cache keys and purge them.
4. Limpiar y endurecer
   • Remove or sanitize any malicious payloads persisted in upstream data sources.
   • Rotate secrets that may have been exposed.
   • Reassess CSP and input sanitization.
5. Comunicar
   • If user data was at risk or exploit went public, follow your incident disclosure policy and notify stakeholders.

Long-term supply-chain and deployment hardening for WordPress owners

• Maintain a dependency inventory: Track Node and PHP dependencies used by your site and CI pipeline. Periodically run SCA scans across all packages.
• Fijar y bloquear dependencias: Use exact version pins in package.json for production-critical packages. Commit lockfiles and run regular rebuilds.
• Automate updates: Use automated tools to propose updates; test and deploy regularly. Consider pipelines that rebuild images and run integration tests when patches are released.
• Limit caching surface: Only enable aggressive shared caching for truly static assets. For dynamic fragments or user-personalized fragments, use Cache-Control: private or bypass caching.
• Harden front-end rendering: Ensure server-rendered fragments escape user data by default. Adopt template engines that auto-escape, or explicitly sanitize dangerous fields.
• Require secure headers: CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, Strict-Transport-Security — enforce these across the site.
• Monitorea y registra: Aggregated logs for endpoint access and cache behavior help detect anomalies sooner. Monitor WAF/edge events and keep rules under review.

Specific WordPress recommendations (practical checklist)

• If your site is headless:
  • Confirm which front-end versions and packages are used; upgrade Nitro where necessary.
  • Ensure your WordPress REST API responses encode and sanitize HTML fields properly.
  • Ensure preview and CI environments are as secured as production.
• If your site uses a Jamstack or SSR pipeline (Netlify, Vercel, other providers):
  • Contact your provider for confirmation of Nitro package status in their environments.
  • Purge edge caches after updates.
• If your site is classic WordPress but relies on third-party plugins or services that might render at the edge:
  • Check plugin vendors for notifications and updates.
  • Ask hosting or platform teams about Nitro usage in their stack.

Monitoring signals to watch for in the coming weeks

• Increased requests hitting __nuxt_island with payloads that include encoded <script forms.
• Sudden appearance of inline scripts in cached HTML served by your CDN.
• Elevated WAF/edge rule hits tied to island endpoints.
• Reports of popups, redirects, or unexpected JavaScript on pages that were previously static.

If you see these signs, treat them seriously: purge caches, apply virtual patches, and update packages.

Preguntas frecuentes (corto)

P: My site is classic WordPress with no Node front-end — am I affected?
R: If no Nuxt/Nitro components are in your stack, direct exposure is minimal. But check developer tools, preview services, or CDNs used by your site for Nitro usage.

P: I updated to 4.4.6 but still see suspicious scripts in cached pages — what next?
R: Purge caches across all tiers (edge, CDN, reverse proxy). An update may not remove previously cached poisoned assets automatically.

P: Can Content Security Policy fully mitigate this?
R: CSP reduces the impact of injected scripts but doesn’t solve cache poisoning. Use CSP + cache-control + patching for full mitigation.

P: How urgent is this update?
R: Prioritise patching if you run Nuxt/Nitro in any part of your delivery chain. The CVE is low-severity by CVSS but enables scalable cache-poisoning attacks that can affect many users.

Recomendaciones finales — lista de verificación priorizada

1. Inventory: Search for Nitro/Nuxt usage across your site, CI, and hosting provider.
2. Patch: Update @nuxt/nitro-server to 4.4.6+ everywhere it appears.
3. Protect: Apply WAF rules and set appropriate Cache-Control and Vary headers to prevent shared cache usage for dynamic fragments.
4. Purge: Clear caches at CDN and edge layers.
5. Harden: Implement/strengthen CSP, sanitize server-rendered content, and ensure cache keys vary on user-sensitive headers.
6. Automate: Add routine SCA scans and automated dependency updates to your pipeline.

If you would like an operations playbook tailored to your WordPress hosting architecture (classic vs. headless vs. hybrid), I can provide one that maps the steps to your stack and includes WAF rule snippets and testing scripts you can run in staging before production rollout. Reply with details of your architecture and I will prepare a practical playbook.