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. The issue is patched in 4.4.6. If your WordPress site integrates with JavaScript front-ends, headless architectures, CDN edge rendering, or uses Nuxt/Nitro components in your toolchain, this advisory explains the risk, detection methods, mitigations (including emergency firewall/edge rules), and longer-term supply-chain hardening strategies.

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

Most WordPress deployments remain PHP-based with server-side rendering from the WordPress stack. Increasingly, however, operators in Hong Kong and the region are using modern JavaScript front-ends (Nuxt, Next, Remix) for performance and improved developer workflows — a headless or decoupled architecture. Those front-ends commonly rely on Node-based servers, Nitro middleware, and edge caches/CDNs.

The reported issue (CVE-2026-46342) affects a Nitro server endpoint used by Nuxt front-ends: __nuxt_island. When responses are not tightly bound to the originating request properties, a shared cache can serve a response created for one user to another. If that response contains attacker-controlled content (for example, unsanitized HTML or script fragments), an attacker can poison caches and trigger Cross-Site Scripting for many site visitors.

Even if your WordPress backend is not directly running Node, WordPress systems can be impacted when:

• Your WordPress site uses a Nuxt or Nitro front-end that pulls data from the WordPress REST API or GraphQL.
• Your hosting environment uses server-side rendering or edge-rendering services that include Nitro-based components.
• Your CI/CD, build pipeline, or third-party services use the vulnerable package to generate previews, deploy front-ends, or render pages at the edge.

This advisory takes a pragmatic stance with a Hong Kong security expert tone: direct, operational, and focused on what site owners and operators must do now.

Technical overview — what’s broken

• El __nuxt_island endpoint renders or hydrates islanded components (small interactive fragments) in Nuxt’s hybrid rendering model.
• The vulnerable behavior: responses from the endpoint are not sufficiently bound to request properties (origin, headers, cookies, query parameters). If a caching layer stores that response without appropriate Vary/Cache-Control headers or cache keys, the cached response may be served to other requests that differ in critical request properties.
• If an attacker can craft a request that includes attacker-controlled content (e.g., via injected properties or reflected data) and cause that response to be cached, the attacker can poison the shared cache. When other users receive that cached response, any malicious script will execute in their browsers — resulting in potentially widespread impact.

The end result: a single successful exploit can turn into mass XSS via one poisoned cached island fragment.

Attack surface for WordPress sites

Common integration patterns that expose WordPress-powered sites to this issue:

• Headless WordPress + Nuxt front-end:
  • WordPress serves content via REST API / GraphQL.
  • Nuxt front-end uses Nitro to server-render islands that include content from WP.
  • Vulnerable Nitro package used in the front-end process can cause cache poisoning.
• Edge rendering / CDN preview/OG image generation:
  • Some edge preview generators or image endpoints include Nitro-based rendering.
  • If your hosting provider or CI uses Nitro components, those endpoints may be affected.
• Developer tooling:
  • Build and preview systems (storybook, SSR previews, static site generators) that install the vulnerable dependency can create or upload poisoned artifacts or cached output.
• Integraciones de terceros:
  • Plugin vendors, theme builders, or headless-service providers could be running Nitro-based previews. If they are using vulnerable versions, clients’ sites may be impacted indirectly.

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.

How attackers can exploit it (practical scenarios)

• Reflected XSS via cached island fragment:
  • Attacker sends a crafted request to __nuxt_island with attacker-controlled parameter.
  • Nitro generates a fragment containing the parameter without appropriate sanitization.
  • The CDN caches the fragment for a shared key.
  • Subsequent visitors receive the cached fragment; attacker JavaScript runs in their browsers.
• Stored-like poisoning via upstream data:
  • If the front-end renders data from a third-party API or user input (e.g., comments), an attacker stores malicious input upstream.
  • The server renders the island with the malicious content; the response is cached and later served to others.
• Large-scale abuse: Edge caches mean a single cached object can affect thousands of visitors; cache-poisoning routes amplify impact.

Patch and update — the single most important fix

If you use Nuxt/Nitro anywhere in your stack, update the affected package immediately:

• Afectados: @nuxt/nitro-server ≥ 4.2.0 and ≤ 4.4.5
• Corregido en: 4.4.6 — upgrade to 4.4.6 or later

Acciones:

1. For projects that use npm/yarn/pnpm:
   • Run npm install @nuxt/nitro-server@^4.4.6 (or update package.json and run your package manager).
   • Update lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) and commit them.
2. For containerized builds:
   • Rebuild images and redeploy after updating the package and lockfile.
   • Avoid relying on implicit latest versions — use pinned versions and rebuild images frequently.
3. For edge or preview services you don’t control:
   • Contact your provider or service owner and request confirmation of patching.
   • Ask them to update to 4.4.6+ and to invalidate caches after patching.

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

Immediate mitigations you can apply now (even before patching)

Practical measures you can implement quickly to reduce exposure:

1. Disable shared caching for the island endpoint
   • Ensure responses from __nuxt_island are marked not cacheable by shared caches:
     • Establecer Cache-Control: private, no-cache, no-store, must-revalidate (choose appropriate directives for your environment).
     • Agregar Vary headers to include cookies/authorization/host if responses depend on them: Vary: Cookie, Authorization, Accept-Encoding, Host.
   • If you control CDN rules, create a rule to bypass cache for any path matching /__nuxt_island o similar.
2. Virtual patching with WAF / edge rules
   • Create firewall rules to block or challenge requests to /__nuxt_island that contain suspicious payloads:
     • Bloquee solicitudes que contengan , onerror=, onload=, encoded script tokens (%3Cscript), or obvious XSS patterns in query strings.
     • Rate-limit or CAPTCHA-challenge anomalous requests to that path.
   • Example ModSecurity-style rules (conceptual):

   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)(

   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:
     • Example: 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. Monitor logs and traffic
   • 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.

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";
}

# 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)(