Nom du plugin	@nuxt/nitro-server
Type de vulnérabilité	Scripts intersites (XSS)
Numéro CVE	CVE-2026-46342
Urgence	Faible
Date de publication du CVE	2026-05-20
URL source	CVE-2026-46342

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

Auteur: Équipe de sécurité WP-Firewall
Date: 2026-05-20
Mots clés: security, WordPress, WAF, Nuxt, headless, CVE-2026-46342

Résumé: 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.

---

Pourquoi cela importe pour les propriétaires de sites WordPress

Most WordPress sites use PHP templates and server-side rendering via the WordPress stack. However, an increasing number of WordPress sites are integrated with modern JavaScript front-ends (Nuxt, Next, Remix) for performance and developer experience — 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 the server fails to bind responses tightly to the originating request properties, a shared cache can serve a response created for one user to another user. 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 is written from a WordPress security perspective. We’ll focus on practical detection and remediation steps you can apply immediately, plus longer-term hardening and WAF/edge-rule guidance.

---

Technical overview — what’s broken

À un niveau élevé :

• Le __nuxt_island endpoint is responsible for rendering or hydrating islanded components (small interactive fragments) in Nuxt’s hybrid rendering model.
• The vulnerable behavior: responses returned by the endpoint are not sufficiently bound to the request props (origin, headers, cookies, query parameters). If a caching layer (CDN, reverse proxy, or server-side shared cache) 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, payloads in query params, or reflected data from API responses) and cause that response to be cached, the attacker can poison the shared cache. When other users receive that cached response, any malicious script inside will execute in their browsers (reflected or stored XSS scenario) — resulting in widespread impact since caches serve many users.

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

---

Attack surface for WordPress sites

Here are 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.
• Intégrations tierces :
  • Plugin vendors, theme builders, or headless-service providers could be running Nitro-based previews. If they are compromised or use 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 pays to check.

---

How attackers can exploit it (practical scenarios)

• Reflected XSS via cached island fragment:
  • Attacker sends a specially 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 browser.
• Stored-like poisoning via upstream data:
  • If the front-end renders data from a third-party API or from a comment system that accepts user input, an attacker stores malicious input in that source.
  • 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. Attackers prefer cache-poisoning routes since impact is amplified.

---

Patch and update — the single most important fix

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

• Affecté: @nuxt/nitro-server ≥ 4.2.0 and ≤ 4.4.5
• Patched in: 4.4.6 (upgrade to 4.4.6 or later)

Actions :

1. For projects that use npm/yarn/pnpm:
   • Exécutez npm install @nuxt/nitro-server@^4.4.6 (or update your 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.
   • Instruct them to update to 4.4.6+ and to invalidate caches after patching.

If you cannot update immediately, use the mitigations below.

---

Immediate mitigations you can apply now (even before patching)

These are 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:
   • Définir Cache-Control: private, no-cache, no-store, must-revalidate (choose appropriate directive for your environment).
   • Ajouter 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 ou similaire.
2. Virtual patching with your WAF / edge rules
   • Create one or more firewall rules to block or challenge requests to /__nuxt_island that contain suspicious payloads:
   • Bloquer les requêtes contenant <script, onerror=, onload=, encoded script tokens (e.g., <script), or blatant XSS patterns in query strings.
   • Rate-limit or CAPTCHA-challenge anomalous requests to that path.
   • If feasible, block requests where Accept headers indicate HTML rendering plus suspicious query values.
   • Exemple de règle de style ModSecurity (conceptuelle) :

   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 you believe poisoning has occurred (or as a precaution), purge caches at all tiers:
     • CDN edge caches
     • Reverse proxy caches (Varnish)
     • Application caches (if any)
   • Use cache-busting headers or versioning for island fragments if necessary.
4. Ajoutez une politique de sécurité du contenu (CSP)
   • Implement or tighten CSP for pages that include island fragments:
     • Exemple: 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 that any data bound into responses is properly escaped or sanitized before it is included in server-rendered HTML.
6. Surveiller les journaux et le trafic
   • 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 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";
}

Simple ModSecurity rules (conceptual):

# 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.
• If response contains <script or suspicious inline JS AND the request has no proper authentication or expected header, 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.

Limitation de taux :

• Apply rate limits on requests to __nuxt_island, e.g., 5 requests per minute per IP, to reduce the feasibility of poisoning attempts.

Rappelez-vous : take incremental steps in staging and monitor false positives. WAF rules are blunt instruments; test 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, et __nuxt_island.
   • Utiliser npm ls @nuxt/nitro-server or equivalent to list installed versions.
   • Vérifier 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 scénario, une erreur, ou variantes encodées (%3C, <).
3. Review cached responses
   • Fetch cached edge HTML for pages and inspect for injected 5. tags or inline event handlers that you did not author.
   • If your CDN supports cache inspection, verify cached objects for unusual content.
4. Analyse automatisée
   • 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:
   • Mise à jour @nuxt/nitro-server to 4.4.6+.
   • Rebuild containers and redeploy.
3. Contain and investigate:
   • Isolate suspicious servers or processes.
   • Dump logs for the time window of suspected poisoning.
   • Identify and list affected cache keys and purge them.
4. Nettoyez et renforcez :
   • Remove or sanitize any malicious payloads persisted in upstream data sources.
   • Rotate secrets that may have been exposed.
   • Reassess CSP and input sanitization.
5. Communiquez :
   • If user data was at risk or exploit was 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 your CI pipeline.
  • Periodically run SCA (Software Composition Analysis) scans across all packages.
• Pin and lock dependencies:
  • Use exact version pins in package.json for production-critical packages.
  • Commit lockfiles and run regular rebuilds.
• Automate updates:
  • Use automated tools (renovate-style or scheduled audits) to propose updates; test and deploy regularly.
  • Consider an automated pipeline that rebuilds images and runs integration tests when dependency 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 — keep these enforced across the site.
• Surveillez et enregistrez :
  • 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 (e.g., Netlify, Vercel, other providers):
  • Reach out to your provider for confirmation of Nitro package status in their environments.
  • Purge edge caches after updates.
• If your site is classic WordPress but you rely on third-party plugins or services that might render pages 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 5. 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.

---

Secure Your Site for Free — Start with WP-Firewall Basic

If you want a simple, effective starting point for protecting WordPress while you validate and patch upstream components, consider our Basic (Free) plan. It gives you essential protections that reduce exposure to web application threats while you implement the targeted mitigations above.

Ce que vous obtenez avec le plan Basic (Gratuit) :

• Managed firewall protecting common attack surfaces
• WAF to block common injection and XSS patterns
• Malware scanner to detect suspicious injected payloads
• Bande passante illimitée et analyse continue
• Couverture d'atténuation des risques les plus importants selon l'OWASP

Sign up and activate the free plan to add a protective layer while you apply the Nuxt/Nitro patch and hardening steps: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Example: How we would respond at the WAF layer (operational playbook)

1. Triage :
   • Identify whether the site uses vulnerable Nitro versions.
   • If yes, immediately enable WAF rule set that targets island-path XSS patterns.
2. Apply virtual patch rules:
   • Temporarily mark /__nuxt_island responses as non-cacheable for shared caches via the edge.
   • Add inbound rules to block requests containing script tokens.
3. Alert:
   • Notify site owners and developers to update to 4.4.6+.
   • Schedule a deployment window to update dependency and rebuild containers.
4. Vérification :
   • After deploying update + WAF rules, run automated test suite and simulated XSS probes in staging.
   • After passing tests, remove overly restrictive WAF rules that may block valid traffic and rely on the upstream fix.
5. Post-mortem :
   • Review why cache key or Vary headers were misconfigured.
   • Improve deployment controls to ensure dependency updates are applied faster.

---

Questions fréquemment posées (courtes)

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

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

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

Q : Quelle est l'urgence de cette mise à jour ?
A: It’s important: the exploit is low-severity on CVSS but can be used for scalable cache-poisoning attacks that affect many users. Prioritize patching if you run Nuxt/Nitro in any part of your delivery chain.

---

Recommandations finales — liste de contrôle priorisée

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 Cache-Control/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’d like an operations playbook tailored to your WordPress hosting architecture (classic vs. headless vs. hybrid), our security team can map the steps to your stack and provide recommended WAF rule snippets and testing scripts you can run in staging before production rollout.