__nuxt_island cache poisoning and XSS — why WordPress sites using Nuxt frontends must act now

Par : Expert en sécurité de Hong Kong

Résumé : Nuxt fixed a vulnerability where the __nuxt_island endpoint did not bind responses to request props, allowing shared-cache poisoning that can lead to stored or reflected cross-site scripting (XSS) for sites using Nuxt SSR or islands with shared caches. WordPress backends paired with Nuxt frontends (headless, hybrid, JAMstack) or sites behind shared CDNs/proxies are at risk. This article explains the issue, realistic exploitation scenarios, and practical mitigations for WordPress teams from a Hong Kong security practitioner’s perspective.

CVE : CVE-2026-46342 — Avis : GHSA-g8wj-3cr3-6w7v — Affected nuxt versions: >= 4.0.0-alpha.1, <= 4.4.5 — Corrigé dans : 4.4.6

Why WordPress site owners should care (even if WordPress itself is not Nuxt)

In Hong Kong and globally, WordPress is used in diverse delivery architectures:

• Traditional: WordPress renders HTML server-side and serves it directly.
• Headless / Hybrid: WordPress is the content backend (REST API / GraphQL) and a JS framework (like Nuxt) renders the frontend with SSR, incremental regeneration, or “islands”.
• CDN and cache-heavy setups: Sites sit behind CDNs and reverse proxies that cache responses for performance.

If your WordPress site uses a Nuxt frontend, or if Nuxt-managed routes are served from the same hostname and caching layer as WordPress content, a Nuxt cache-poisoning issue can inject malicious HTML/JS that browsers execute when pages load. Consequences include XSS, credential theft, ad injection, or further compromise. Even pure-WordPress sites should be aware: mixed stacks sharing a CDN or proxy can suffer cross-impact from a vulnerable Nuxt route.

What exactly went wrong: technical explanation (plain and detailed)

Nuxt’s island architecture exposes an endpoint: __nuxt_island. This endpoint accepts requests carrying “props” used to render islands (small SSR fragments). The bug combines two failures:

1. Nuxt returned rendered HTML for __nuxt_island demandes.
2. The response cache key used by intermediate caches (CDNs, reverse proxies, edge caches) did not reliably include the request props, so different requests could map to the same cache entry.

As a result, a response produced for one set of props could be stored in a shared cache and later served to other visitors who requested the same path but with different props. If props contain attacker-controlled values that are rendered without proper encoding, an attacker can craft a request whose response is cached and then served to many visitors — classic cache poisoning enabling widespread XSS.

Points techniques clés :

• A cache key must distinguish user-specific or request-specific responses. If it doesn’t, users receive content intended for others.
• For SSR endpoints that render dynamic fragments, the cache key must include the props or the endpoint must opt out of shared caching (Cache-Control: private / no-store).
• XSS happens when untrusted input reaches HTML/JS without correct escaping; shared caches multiply the effect.

Realistic attack scenario against a WordPress + Nuxt frontend

Common deployment:

• WordPress serves content via REST API.
• Nuxt frontend performs SSR, requesting data and rendering islands via __nuxt_island.
• Site is served from a common domain using a CDN that caches responses from the Nuxt server.

Exploit steps an attacker could take:

1. Find a __nuxt_island endpoint that accepts attacker-controlled input via query parameters or request body used as props.
2. Craft props containing an XSS payload that will be rendered into the fragment without escaping.
3. Send the request through the CDN and cause the CDN to cache the response under a shared key.
4. Subsequent visitors receive the poisoned HTML and the attacker’s script executes in their browsers.

Conséquences potentielles :

• Credential theft if cookies are present.
• Session theft for admins or editors visiting the front-end.
• SEO and brand damage from inserted ads or redirects.
• Distribution of malware via injected scripts or redirects.

Immediate steps (what to do today — prioritized)

If your site could be affected (you use Nuxt frontends, or a CDN/proxy that serves Nuxt routes), follow this sequence immediately:

1. Upgrade Nuxt to the patched release (4.4.6 or later). This is the definitive fix; coordinate with frontend teams and schedule the upgrade now.
2. Disable shared caching pour __nuxt_island endpoints at CDN/edge/proxy: configure path-based rules to bypass cache or set Cache-Control à no-store / privé until you upgrade.
3. Set origin response headers for island routes: use Cache-Control: private, no-store, max-age=0 ou s-maxage=0, and add appropriate Vary headers for headers/cookies you vary on.
4. Deploy WAF rules (or CDN edge filtering) to block or monitor suspicious props: flag or block requests containing script tags or encoded script patterns in query/body.
5. Purge caches and audit logs: remove any cached island responses, and search logs for suspicious __nuxt_island requests containing payloads like or encoded equivalents.
6. Review server-side rendering paths that use user input and ensure proper escaping/encoding of props.
7. Inform stakeholders (developers, hosting, CDN admins) about the vulnerability and actions taken.

IF request.path CONTAINS "__nuxt_island"
AND request.method IN ("GET","POST")
AND (
  request.query_string CONTAINS "
2. Reject serialized HTML/JS in props
IF request.path CONTAINS "__nuxt_island"
AND request.params.props MATCHES "(<[^>]+>|%3C[^%]+%3E|javascript:|on[a-z]+=)"
THEN log & block
3. Enforce origin cache-control for island routes
For responses to __nuxt_island, set:

Cache-Control: private, no-store, max-age=0
Surrogate-Control: no-store (for CDNs that honor it)

4. Rate-limit suspicious island requests
IF request.path CONTAINS "__nuxt_island"
AND requests_from_ip > 10 per minute
THEN rate-limit or block
5. Monitor for inline scripts in cached responses
Alert on edge logs where responses for island routes include inline 
			
				
			
					

							

			
			
			





		

		
					
				 
 
   
 
  
 
 Vérifiez ma commande
 0 
 
 
  
 
 
  
 
 
 
 Sous-total
 
Taxes et frais de port calculés à la caisse
 
 
  
 
 
 
   Passer à la caisse