__nuxt_island empoisonnement de cache et XSS — pourquoi les sites WordPress utilisant des frontends Nuxt doivent agir maintenant

Par : Expert en sécurité de Hong Kong

Résumé : Nuxt a corrigé une vulnérabilité où le __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 — Versions nuxt affectées : >= 4.0.0-alpha.1, <= 4.4.5 — Corrigé dans : 4.4.6

Pourquoi les propriétaires de sites WordPress devraient s'en soucier (même si WordPress lui-même n'est pas Nuxt)

À Hong Kong et dans le monde, WordPress est utilisé dans diverses architectures de livraison :

• Traditionnelle : WordPress rend le HTML côté serveur et le sert directement.
• 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”.
• Configurations lourdes en CDN et cache : Les sites se trouvent derrière des CDN et des proxies inverses qui mettent en cache les réponses pour des performances optimales.

Si votre site WordPress utilise un frontend Nuxt, ou si des routes gérées par Nuxt sont servies depuis le même nom d'hôte et la même couche de cache que le contenu WordPress, un problème d'empoisonnement de cache Nuxt peut injecter du HTML/JS malveillant que les navigateurs exécutent lors du chargement des pages. Les conséquences incluent XSS, vol d'identifiants, injection de publicités ou compromission supplémentaire. Même les sites purement WordPress devraient être conscients : des stacks mixtes partageant un CDN ou un proxy peuvent subir un impact croisé d'une route Nuxt vulnérable.

Que s'est-il exactement passé : explication technique (simple et détaillée)

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 a renvoyé du HTML rendu pour __nuxt_island demandes.
2. La clé de cache de réponse utilisée par les caches intermédiaires (CDNs, proxies inverses, caches de périphérie) n'incluait pas de manière fiable les propriétés de la requête, de sorte que différentes requêtes pouvaient correspondre à la même entrée de cache.

En conséquence, une réponse produite pour un ensemble de props pourrait être stockée dans un cache partagé et ensuite servie à d'autres visiteurs qui ont demandé le même chemin mais avec des props différents. Si les props contiennent des valeurs contrôlées par un attaquant qui sont rendues sans encodage approprié, un attaquant peut créer une requête dont la réponse est mise en cache et ensuite servie à de nombreux visiteurs — classique empoisonnement de cache permettant un XSS généralisé.

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.
• Pour les points de terminaison SSR qui rendent des fragments dynamiques, la clé de cache doit inclure les props ou le point de terminaison doit renoncer au cache partagé (Cache-Control : privé / no-store).
• Le XSS se produit lorsque des entrées non fiables atteignent HTML/JS sans échappement correct ; les caches partagés multiplient l'effet.

Scénario d'attaque réaliste contre un frontend WordPress + Nuxt

Déploiement commun :

• WordPress sert du contenu via l'API REST.
• Le frontend Nuxt effectue du SSR, demandant des données et rendant des îlots via __nuxt_island.
• Le site est servi depuis un domaine commun utilisant un CDN qui met en cache les réponses du serveur Nuxt.

Étapes d'exploitation qu'un attaquant pourrait suivre :

1. Trouver un __nuxt_island point de terminaison qui accepte des entrées contrôlées par l'attaquant via des paramètres de requête ou le corps de la requête utilisés comme props.
2. Créer des props contenant une charge utile XSS qui sera rendue dans le fragment sans échappement.
3. Envoyer la requête via le CDN et provoquer le CDN à mettre en cache la réponse sous une clé partagée.
4. Subsequent visitors receive the poisoned HTML and the attacker’s script executes in their browsers.

Conséquences potentielles :

• Vol de données d'identification si des cookies sont présents.
• Vol de session pour les administrateurs ou les éditeurs visitant le frontend.
• Dommages SEO et à la marque dus à des publicités ou des redirections insérées.
• Distribution de logiciels malveillants via des scripts ou des redirections injectés.

Étapes immédiates (que faire aujourd'hui — priorisées)

1. Si votre site peut être affecté (vous utilisez des frontends Nuxt, ou un CDN/proxy qui sert des routes Nuxt), suivez cette séquence immédiatement :

1. 2. Mettez à jour Nuxt 3. vers la version corrigée (4.4.6 ou ultérieure). C'est la solution définitive ; coordonnez-vous avec les équipes frontend et planifiez la mise à jour maintenant.
2. 4. Désactivez le cache partagé pour __nuxt_island 5. des points de terminaison au CDN/edge/proxy : configurez des règles basées sur le chemin pour contourner le cache ou définissez Cache-Control à 6. no-store / privé 7. jusqu'à ce que vous mettiez à jour.
3. 8. Définissez les en-têtes de réponse d'origine 9. pour les routes d'île : utilisez 10. Cache-Control : private, no-store, max-age=0 ou 11. s-maxage=0, 12. , et ajoutez les Variez 13. en-têtes appropriés pour les en-têtes/cookies que vous variez.
4. 14. Déployez des règles WAF 15. (ou filtrage CDN edge) pour bloquer ou surveiller les propriétés suspectes : signalez ou bloquez les requêtes contenant des balises script ou des motifs de script encodés dans la requête/le corps.
5. 16. Purgez les caches et les journaux d'audit : 17. supprimez toutes les réponses d'île mises en cache, et recherchez dans les journaux des requêtes suspectes contenant des charges utiles comme __nuxt_island des requêtes contenant des charges utiles comme <script ou encodés.
6. Review server-side rendering paths that use user input and ensure proper escaping/encoding of props.
7. Informer les parties prenantes (developers, hosting, CDN admins) about the vulnerability and actions taken.

WAF strategy & sample rules (practical examples)

Below are conservative example rules to use as a starting point. Test in detection mode before blocking to avoid false positives.

1. Block or challenge requests with script-like content

IF request.path CONTAINS "__nuxt_island"
AND request.method IN ("GET","POST")
AND (
  request.query_string CONTAINS "<script" OR
  request.body CONTAINS "<script" OR
  request.query_string MATCHES "(%3Cscript|%3C%2Fscript)"
)
THEN block or challenge

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:

• 10. 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 <script> tags or external script references to unfamiliar hosts.

Always run rules in monitoring mode first, tune them against real traffic, and escalate to blocking only after validating low false-positive rates.

Cache configuration recommendations

• For server-rendered fragments that depend on per-request data (cookies, auth, props), use Cache-Control: private ou Cache-Control: no-store. Shared caches should not store user-specific content.
• If you allow caching, ensure the cache key includes any user- or request-specific identifier used by Nuxt props. Many CDNs allow custom cache key composition — include only the minimal, necessary identifiers to avoid cache collisions.
• Utilisez Vary: headers correctly. If responses depend on Cookie ou Authorization, include Vary: Cookie lorsque cela est applicable.
• Avoid caching raw HTML fragments that contain unescaped user content.
• Regularly sample cached content to check for integrity and absence of injected scripts.

Detecting if you’ve been hit (indicators of compromise)

• Unexpected inline scripts or external JS from unfamiliar hosts.
• User reports of redirects, popups, or strange behavior on Nuxt-served pages.
• CDN edge logs showing __nuxt_island requests with unusual query strings or bodies followed by many cached GET responses.
• Traffic spikes to island paths with new inline scripts.
• Security scanners/site-monitoring alerts flagging injected scripts.

Étapes d'enquête :

1. Save HTML snapshots of affected pages for forensic analysis.
2. Purge CDN caches for impacted paths.
3. Recherchez dans les journaux pour __nuxt_island des requêtes contenant des charges utiles comme <script, onerror=, javascript :, or URL-encoded variants.
4. Look for single IPs issuing many island requests — likely testers or attackers.
5. Check origin logs to confirm the origin server was not compromised; often the issue is cache configuration rather than origin breach.

Secure coding practices to eliminate similar risks

• Never render untrusted data into HTML without proper escaping.
• Use established templating and escaping libraries; avoid hand-rolled encoders.
• Treat any user data used in SSR as untrusted, even from internal APIs.
• Prefer JSON data endpoints for props and let the frontend escape/sanitize before injecting into HTML.
• Implement Content Security Policy (CSP) to limit the impact of injected scripts (e.g., disallow inline scripts and restrict script sources).
• Validate and sanitize input at the boundaries; assume an attacker can craft any props payload.

Why the CVSS score can be low but still important

The advisory lists a low CVSS because exploitation requires specific conditions: islands used, props derived from user input, and shared caching. Low CVSS does not mean low risk. When the architecture matches the exploitation conditions, caches amplify impact and attacks scale quickly. Treat low-base-severity issues with urgency when your environment meets those constraints.

Layered defences and how to get help

Practical layered controls you can implement or request from your CDN/hosting/operations teams:

• Immediate Nuxt upgrade and cache bypass for island endpoints.
• Edge filtering / WAF rules to block common script injection patterns in island props.
• Response header enforcement to prevent shared caching of user-specific fragments.
• Monitoring and alerting on island routes, plus log retention for incident investigation.
• Engage frontend and ops teams to verify proper escaping in SSR paths.

If you need assistance, contact your CDN or WAF provider, hosting support, or an experienced security consultant who understands mixed WordPress + JS frontend architectures. Ask them to deploy emergency edge rules, help purge caches, and audit cache key configuration.

Long-term mitigation (beyond immediate fixes)

• Keep dependencies updated and run regular audits for frontend and backend packages.
• Include cache and WAF configuration in threat models for mixed stacks.
• Add automated security tests in CI to detect unsafe rendering of props or missing cache headers.
• Treat SSR endpoints that render user content as non-cacheable by default; only allow caching with strict cache-key rules.
• Train frontend developers on secure SSR practices — many templating issues are accidental and preventable.
• Monitor advisories and include dependency upgrades in maintenance planning.

Example incident response checklist (concise)

1. Upgrade Nuxt to >= 4.4.6.
2. Purge CDN caches for paths matching *__nuxt_island*.
3. Configure CDN/proxy to bypass caching for island endpoints.
4. Deploy WAF/edge rules to block script-like props for island endpoints.
5. Audit and escape any props rendered into HTML templates.
6. Review logs and identify suspicious requests; notify affected users if needed.
7. Add detection for repeated island requests or inline script responses.
8. Run site-wide scans and a post-incident pentest if you suspect compromise.

Practical checklist for WordPress administrators

• Do we use Nuxt or another JS frontend that does SSR/islands? If yes, check versions and update.
• Is our site behind a CDN? If yes, do we have path rules to bypass caching on dynamic SSR endpoints? If not, implement them.
• Are any props or path parameters user-controlled and inserted into rendered HTML? If yes, escape or sanitize.
• Can our WAF/edge filtering block or monitor __nuxt_island suspicious requests? If not, add rules now.
• Do we keep backups and an incident plan? If not, prepare one.

Final notes — why rapid action matters

This Nuxt issue highlights how hybrid stacks create new threat surfaces: SSR, dynamic rendering, and shared caching are common in high-performance WordPress sites, and together they can be abused without direct admin compromise. An attacker can leverage the rendering layer and caches to distribute malicious content widely.

Action priority: 1) upgrade Nuxt, 2) block shared caching for island endpoints, 3) deploy edge/WAF filtering and monitoring, 4) audit SSR rendering for proper escaping. For teams in Hong Kong and beyond, coordinate across development, operations, and CDN/hosting stakeholders to implement these steps quickly.

Stay vigilant, prioritise the upgrade, and ensure your caching and edge rules prevent shared-cache poisoning while you remediate the root cause.