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’ Poisonnement de Cache Partagé (CVE-2026-46342) — Ce que les Propriétaires de Sites WordPress Doivent Savoir

Auteur: Équipe de sécurité WP-Firewall
Date: 2026-05-20
Mots clés: sécurité, WordPress, WAF, Nuxt, sans tête, CVE-2026-46342

Résumé: Une vulnérabilité récemment divulguée dans le serveur Nuxt Nitro impacte les versions >= 4.2.0 et <= 4.4.5. Elle peut conduire à un empoisonnement de cache partagé et à des scripts intersites (XSS) via le __nuxt_island point de terminaison. Le problème est corrigé dans la version 4.4.6. Si votre site WordPress s'intègre avec des front-ends JavaScript, des architectures sans tête, du rendu en bord CDN, ou utilise des composants Nuxt/Nitro dans votre chaîne d'outils, cet avis explique le risque, les méthodes de détection, les atténuations (y compris les règles d'urgence de pare-feu/de bord), et des stratégies de durcissement de la chaîne d'approvisionnement à long terme.

---

Pourquoi cela importe pour les propriétaires de sites WordPress

La plupart des sites WordPress utilisent des modèles PHP et un rendu côté serveur via la pile WordPress. Cependant, un nombre croissant de sites WordPress sont intégrés avec des front-ends JavaScript modernes (Nuxt, Next, Remix) pour la performance et l'expérience développeur — une architecture “sans tête” ou “découplée”. Ces front-ends s'appuient généralement sur des serveurs basés sur Node, des middleware Nitro, et des caches/CDN en bord.

Le problème signalé (CVE-2026-46342) affecte un point de terminaison du serveur Nitro utilisé par les front-ends Nuxt : __nuxt_island. Lorsque le serveur ne parvient pas à lier étroitement les réponses aux propriétés de la requête d'origine, un cache partagé peut servir une réponse créée pour un utilisateur à un autre utilisateur. Si cette réponse contient du contenu contrôlé par un attaquant (par exemple, du HTML non assaini ou des fragments de script), un attaquant peut empoisonner les caches et déclencher des scripts intersites pour de nombreux visiteurs du site.

Même si votre backend WordPress ne fonctionne pas directement sous Node, les systèmes WordPress peuvent être impactés lorsque :

• Votre site WordPress utilise un front-end Nuxt ou Nitro qui extrait des données de l'API REST WordPress ou de GraphQL.
• Votre environnement d'hébergement utilise des services de rendu côté serveur ou de rendu en bord qui incluent des composants basés sur Nitro.
• Votre CI/CD, pipeline de construction, ou services tiers utilisent le package vulnérable pour générer des aperçus, déployer des front-ends, ou rendre des pages en bord.

Cet avis est rédigé d'un point de vue de sécurité WordPress. Nous nous concentrerons sur des étapes pratiques de détection et de remédiation que vous pouvez appliquer immédiatement, ainsi que sur des conseils de durcissement à long terme et de règles WAF/de bord.

---

Vue d'ensemble technique — ce qui est cassé

À un niveau élevé :

• Le __nuxt_island Le point de terminaison est responsable du rendu ou de l'hydratation des composants isolés (petits fragments interactifs) dans le modèle de rendu hybride de Nuxt.
• Le comportement vulnérable : les réponses retournées par le point de terminaison ne sont pas suffisamment liées aux propriétés de la requête (origine, en-têtes, cookies, paramètres de requête). Si une couche de mise en cache (CDN, proxy inverse, ou cache partagé côté serveur) stocke cette réponse sans les en-têtes Vary/Cache-Control appropriés ou les clés de cache, la réponse mise en cache peut être servie à d'autres requêtes qui diffèrent dans des propriétés de requête critiques.
• Si un attaquant peut créer une requête qui inclut du contenu contrôlé par l'attaquant (par exemple, via des propriétés injectées, des charges utiles dans des paramètres de requête, ou des données réfléchies des réponses API) et provoquer la mise en cache de cette réponse, l'attaquant peut empoisonner le cache partagé. Lorsque d'autres utilisateurs reçoivent cette réponse mise en cache, tout script malveillant à l'intérieur s'exécutera dans leurs navigateurs (scénario XSS réfléchi ou stocké) — entraînant un impact généralisé puisque les caches servent de nombreux utilisateurs.

Le résultat final : une seule exploitation peut se transformer en XSS de masse via une page mise en cache ou un fragment isolé empoisonné.

---

Surface d'attaque pour les sites WordPress

Voici des modèles d'intégration courants qui exposent les sites alimentés par WordPress à ce problème :

• WordPress sans tête + front-end Nuxt :
  • WordPress sert du contenu via l'API REST / GraphQL.
  • Le front-end Nuxt utilise Nitro pour rendre des îlots qui incluent du contenu de WP.
  • Un package Nitro vulnérable utilisé dans le processus front-end peut causer une contamination du cache.
• Rendu en bordure / aperçu CDN / génération d'images OG :
  • Certains générateurs d'aperçu en bordure ou points de terminaison d'images incluent un rendu basé sur Nitro.
  • Si votre fournisseur d'hébergement ou CI utilise des composants Nitro, ces points de terminaison peuvent être affectés.
• Outils de développement :
  • Les systèmes de construction et d'aperçu (storybook, aperçus SSR, générateurs de sites statiques) qui installent la dépendance vulnérable peuvent créer ou télécharger des artefacts contaminés ou des sorties mises en cache.
• Intégrations tierces :
  • Les fournisseurs de plugins, les constructeurs de thèmes ou les fournisseurs de services sans tête pourraient exécuter des aperçus basés sur Nitro. S'ils sont compromis ou utilisent des versions vulnérables, les sites des clients peuvent être impactés indirectement.

Si votre site WordPress est purement classique (sans front-end sans tête, sans outils Node dans les déploiements), le risque est beaucoup plus faible. Mais dans les environnements DevOps modernes, il est judicieux de vérifier.

---

Comment les attaquants peuvent l'exploiter (scénarios pratiques)

• XSS réfléchi via un fragment d'île mis en cache :
  • L'attaquant envoie une requête spécialement conçue à __nuxt_island avec un paramètre contrôlé par l'attaquant.
  • Nitro génère un fragment contenant le paramètre sans désinfection appropriée.
  • Le CDN met en cache le fragment pour une clé partagée.
  • Les visiteurs suivants reçoivent le fragment mis en cache ; le JavaScript de l'attaquant s'exécute dans leur navigateur.
• Poisonnement de type stocké via des données en amont :
  • Si le front-end rend des données d'une API tierce ou d'un système de commentaires qui accepte les entrées des utilisateurs, un attaquant stocke une entrée malveillante dans cette source.
  • Le serveur rend l'île avec le contenu malveillant ; la réponse est mise en cache et servie plus tard à d'autres.
• Abus à grande échelle :
  • Les caches en bordure signifient qu'un seul objet mis en cache peut affecter des milliers de visiteurs. Les attaquants préfèrent les routes de poisonnement de cache car l'impact est amplifié.

---

Patch et mise à jour — la correction la plus importante

Si vous utilisez Nuxt/Nitro dans une partie de votre pile, mettez à jour le package affecté immédiatement :

• Affecté: @nuxt/nitro-server ≥ 4.2.0 et ≤ 4.4.5
• Corrigé dans : 4.4.6 (mettez à niveau vers 4.4.6 ou une version ultérieure)

Actions :

1. Pour les projets qui utilisent npm/yarn/pnpm :
   • Exécutez npm install @nuxt/nitro-server@^4.4.6 (ou mettez à jour votre package.json et exécutez votre gestionnaire de packages).
   • Mettez à jour les fichiers de verrouillage (package-lock.json, yarn.lock, pnpm-lock.yaml) et engagez-les.
2. Pour les builds conteneurisées :
   • Reconstruisez les images et redéployez après avoir mis à jour le package et le fichier de verrouillage.
   • Évitez de vous fier aux dernières versions implicites — utilisez des versions figées et reconstruisez les images fréquemment.
3. Pour les services en bordure ou de prévisualisation que vous ne contrôlez pas :
   • Contactez votre fournisseur ou le propriétaire du service et demandez une confirmation de la correction.
   • Instruisez-les à mettre à jour vers 4.4.6+ et à invalider les caches après la correction.

Si vous ne pouvez pas mettre à jour immédiatement, utilisez les atténuations ci-dessous.

---

Atténuations immédiates que vous pouvez appliquer maintenant (même avant de patcher)

Ce sont des mesures pratiques que vous pouvez mettre en œuvre rapidement pour réduire l'exposition.

1. Désactivez le cache partagé pour le point de terminaison de l'île
   • Assurez-vous que les réponses de __nuxt_island sont marquées comme non mises en cache par les caches partagés :
   • Définir Cache-Control : privé, no-cache, no-store, must-revalidate (choisissez la directive appropriée pour votre environnement).
   • Ajouter Varier les en-têtes pour inclure les cookies/l'autorisation/l'hôte si les réponses en dépendent : Vary : Cookie, Authorization, Accept-Encoding, Host.
   • Si vous contrôlez les règles CDN, créez une règle pour contourner le cache pour tout chemin correspondant à /__nuxt_island ou similaire.
2. Patching virtuel avec vos règles WAF / edge
   • Créez une ou plusieurs règles de pare-feu pour bloquer ou défier les demandes à /__nuxt_island qui contiennent des charges utiles suspectes :
   • Bloquer les requêtes contenant <script, onerror=, onload=, des jetons de script encodés (par exemple, <script), ou des motifs XSS flagrants dans les chaînes de requête.
   • Limitez le taux ou défiez par CAPTCHA les demandes anormales vers ce chemin.
   • Si possible, bloquez les demandes où Accepter Les en-têtes indiquent le rendu HTML plus des valeurs de requête suspectes.
   • 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'"
         

   Adaptez les ID et la gravité à votre environnement. Testez avant de bloquer en production.

3. Purger les caches
   • Si vous pensez qu'un empoisonnement a eu lieu (ou par précaution), purgez les caches à tous les niveaux :
     • Caches de bord CDN
     • Caches de proxy inverse (Varnish)
     • Caches d'application (le cas échéant)
   • Utilisez des en-têtes de contournement de cache ou un versionnage pour les fragments d'île si nécessaire.
4. Ajoutez une politique de sécurité du contenu (CSP)
   • Mettez en œuvre ou renforcez CSP pour les pages qui incluent des fragments d'île :
     • Exemple: Content-Security-Policy : default-src 'self' ; script-src 'self' 'nonce-...' ; object-src 'none' ; base-uri 'self' ;
     • Un CSP strict peut limiter l'impact de XSS même si un attaquant injecte une balise script.
5. Augmentez la validation/sanitisation des réponses
   • Du côté serveur (Nuxt ou services en aval), assurez-vous que toutes les données liées aux réponses sont correctement échappées ou assainies avant d'être incluses dans le HTML rendu par le serveur.
6. Surveiller les journaux et le trafic
   • Recherchez des augmentations soudaines des requêtes vers __nuxt_island.
   • Inspectez les motifs récurrents dans les chaînes de requête ou les corps POST qui incluent des jetons de script.
   • Surveillez les motifs de hits de cache de bord et les clés de cache.

---

Suggestions de règles WAF et de bord (concrètes)

Voici des règles pratiques que vous pouvez adapter. Elles sont intentionnellement génériques et doivent d'abord être testées en préproduction.

Extrait Nginx pour définir des en-têtes de cache pour le point de terminaison de l'île :

location ~* /__nuxt_island {

Règles simples de ModSecurity (conceptuel) :

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

Renforcement de la réponse via un worker de bord (pseudo-code) :

• Intercepter les réponses pour /__nuxt_island.
• Si la réponse contient <script ou du JS inline suspect ET que la requête n'a pas d'authentification appropriée ou d'en-tête attendu, rejeter/contester la réponse et ne pas mettre en cache.
• Sinon, s'assurer que la réponse a Cache-Control : privé.

Renforcement de la clé de cache :

• S'assurer que les clés de cache incluent des propriétés spécifiques à l'utilisateur où le contenu varie (Cookie, en-tête d'autorisation, Accept-Language, etc.). Une clé de cache mal configurée qui ignore les cookies est une cause majeure de contamination.

Limitation de taux :

• Appliquer des limites de taux sur les requêtes à __nuxt_island, par exemple, 5 requêtes par minute par IP, pour réduire la faisabilité des tentatives de contamination.

Rappelez-vous : prendre des mesures progressives en staging et surveiller les faux positifs. Les règles WAF sont des instruments grossiers ; tester pour éviter de casser le trafic légitime.

---

Détection : comment savoir si vous êtes affecté

1. Inventorier votre stack
   • Rechercher dans votre code, configurations CI/CD et journaux de construction des références à @nuxt/nitro-server, nuxt, nitro, et __nuxt_island.
   • Utiliser npm ls @nuxt/nitro-server ou équivalent pour lister les versions installées.
   • Vérifier package-lock.json, yarn.lock, pnpm-lock.yaml pour trouver les dépendances transitoires.
2. Inspecter les journaux du serveur et du CDN
   • Rechercher du trafic vers des chemins comme /__nuxt_island (ou des points de terminaison d'île/hydratation similaires).
   • Rechercher des requêtes avec des chaînes de requête suspectes contenant scénario, une erreur, ou variantes encodées (%3C, <).
3. Examiner les réponses mises en cache
   • Récupérer le HTML de bord mis en cache pour les pages et inspecter les 5. balises ou gestionnaires d'événements en ligne que vous n'avez pas créés.
   • Si votre CDN prend en charge l'inspection du cache, vérifiez les objets mis en cache pour un contenu inhabituel.
4. Analyse automatisée
   • Exécutez des analyseurs de dépendances (npm audit, outils SCA) pour localiser les versions de packages vulnérables.
   • Utilisez des analyseurs web (détecteurs XSS) pour sonder les points de terminaison de rendu en toute sécurité dans l'environnement de staging.

---

Si vous pensez avoir été touché — étapes immédiates de l'incident

1. Retirez le point de terminaison vulnérable du cache public :
   • Définissez temporairement Cache-Control : no-store sur les points de terminaison d'île.
   • Purgez les caches à travers le CDN et les proxies.
2. Reconstruire et patcher :
   • Mise à jour @nuxt/nitro-server à 4.4.6+.
   • Reconstruire les conteneurs et redéployer.
3. Contenir et enquêter :
   • Isoler les serveurs ou processus suspects.
   • Dump des journaux pour la fenêtre temporelle de suspicion de contamination.
   • Identifier et lister les clés de cache affectées et les purger.
4. Nettoyez et renforcez :
   • Supprimer ou assainir toute charge utile malveillante persistante dans les sources de données en amont.
   • Faire tourner les secrets qui ont pu être exposés.
   • Réévaluer la CSP et l'assainissement des entrées.
5. Communiquez :
   • Si les données utilisateur étaient à risque ou si l'exploitation était publique, suivez votre politique de divulgation d'incidents et informez les parties prenantes.

---

Renforcement à long terme de la chaîne d'approvisionnement et du déploiement pour les propriétaires de WordPress.

• Maintenir un inventaire des dépendances :
  • Suivre les dépendances Node et PHP utilisées par votre site et votre pipeline CI.
  • Exécuter périodiquement des analyses SCA (Analyse de Composition Logicielle) sur tous les paquets.
• Fixer et verrouiller les dépendances :
  • Utiliser des versions exactes dans package.json pour les paquets critiques en production.
  • Commiter les fichiers de verrouillage et exécuter des reconstructions régulières.
• Automatiser les mises à jour :
  • Utiliser des outils automatisés (style renovate ou audits programmés) pour proposer des mises à jour ; tester et déployer régulièrement.
  • Considérez un pipeline automatisé qui reconstruit des images et exécute des tests d'intégration lorsque des correctifs de dépendance sont publiés.
• Limitez la surface de mise en cache :
  • Activez uniquement la mise en cache partagée agressive pour les actifs véritablement statiques.
  • Pour les fragments dynamiques ou les fragments personnalisés par l'utilisateur, utilisez Cache-Control : privé ou contournez la mise en cache.
• Renforcez le rendu front-end :
  • Assurez-vous que les fragments rendus par le serveur échappent les données utilisateur par défaut.
  • Adoptez des moteurs de template qui échappent automatiquement, ou assainissez explicitement les champs dangereux.
• Exigez des en-têtes sécurisés :
  • CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, Strict-Transport-Security — maintenez ces règles appliquées sur l'ensemble du site.
• Surveillez et enregistrez :
  • Les journaux agrégés pour l'accès aux points de terminaison et le comportement de mise en cache aident à détecter les anomalies plus tôt.
  • Surveillez les événements WAF/edge et gardez les règles sous révision.

---

Recommandations spécifiques pour WordPress (liste de contrôle pratique)

• Si votre site est sans tête :
  • Confirmez quelles versions et packages front-end sont utilisés ; mettez à niveau Nitro si nécessaire.
  • Assurez-vous que les réponses de votre API REST WordPress encodent et assainissent correctement les champs HTML.
  • Assurez-vous que les environnements de prévisualisation et CI sont aussi sécurisés que la production.
• Si votre site utilise un pipeline Jamstack ou SSR (par exemple, Netlify, Vercel, autres fournisseurs) :
  • Contactez votre fournisseur pour confirmer l'état du package Nitro dans leurs environnements.
  • Purgez les caches edge après les mises à jour.
• Si votre site est un WordPress classique mais que vous dépendez de plugins ou de services tiers qui pourraient rendre des pages à la périphérie :
  • Vérifiez les fournisseurs de plugins pour des notifications et des mises à jour.
  • Demandez aux équipes d'hébergement ou de plateforme concernant l'utilisation de Nitro dans leur pile.

---

Signaux de surveillance à surveiller dans les semaines à venir

• Augmentation des requêtes reçues __nuxt_island avec des charges utiles qui incluent des 5. formulaires encodés.
• Apparition soudaine de scripts en ligne dans le HTML mis en cache servi par votre CDN.
• Augmentation des frappes de règles WAF/périphérie liées aux points de terminaison insulaires.
• Rapports de popups, redirections ou javascript inattendu sur des pages qui étaient auparavant statiques.

Si vous voyez ces signes, prenez-les au sérieux : purgez les caches, appliquez des correctifs virtuels et mettez à jour les paquets.

---

Sécurisez votre site gratuitement — Commencez avec WP-Firewall Basic

Si vous voulez un point de départ simple et efficace pour protéger WordPress tout en validant et en corrigeant les composants en amont, envisagez notre plan de base (gratuit). Il vous offre des protections essentielles qui réduisent l'exposition aux menaces des applications web pendant que vous mettez en œuvre les atténuations ciblées ci-dessus.

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

• Pare-feu géré protégeant les surfaces d'attaque courantes
• WAF pour bloquer les modèles d'injection et XSS courants
• Scanner de malware pour détecter les charges utiles injectées suspectes
• Bande passante illimitée et analyse continue
• Couverture d'atténuation des risques les plus importants selon l'OWASP

Inscrivez-vous et activez le plan gratuit pour ajouter une couche de protection pendant que vous appliquez le correctif Nuxt/Nitro et les étapes de durcissement : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Exemple : Comment nous répondrions au niveau du WAF (manuel opérationnel)

1. Triage :
   • Identifiez si le site utilise des versions Nitro vulnérables.
   • Si oui, activez immédiatement l'ensemble de règles WAF qui cible les modèles XSS de chemin insulaire.
2. Appliquer les règles de patch virtuel :
   • Marquer temporairement /__nuxt_island les réponses comme non-cacheables pour les caches partagés via l'edge.
   • Ajouter des règles entrantes pour bloquer les demandes contenant des jetons de script.
3. Alerte :
   • Informer les propriétaires de sites et les développeurs de mettre à jour vers 4.4.6+.
   • Planifier une fenêtre de déploiement pour mettre à jour les dépendances et reconstruire les conteneurs.
4. Vérification :
   • Après avoir déployé la mise à jour + les règles WAF, exécuter la suite de tests automatisés et des sondes XSS simulées en staging.
   • Après avoir réussi les tests, supprimer les règles WAF trop restrictives qui pourraient bloquer le trafic valide et s'appuyer sur le correctif en amont.
5. Post-mortem :
   • Examiner pourquoi la clé de cache ou les en-têtes Vary étaient mal configurés.
   • Améliorer les contrôles de déploiement pour garantir que les mises à jour des dépendances sont appliquées plus rapidement.

---

Questions fréquemment posées (courtes)

Q : Mon site est un WordPress classique sans front-end Node — suis-je affecté ?
A : Si aucun composant Nuxt/Nitro n'est dans votre stack, votre exposition directe est minimale. Mais vérifiez les outils de développement, les services de prévisualisation ou les CDN utilisés par votre site pour l'utilisation de Nitro.

Q : J'ai mis à jour vers 4.4.6 mais je vois toujours des scripts suspects dans les pages mises en cache — que faire ensuite ?
A : Purger les caches sur tous les niveaux (edge, CDN, proxy inverse). La mise à jour peut ne pas supprimer automatiquement les actifs empoisonnés mis en cache précédemment.

Q : La politique de sécurité du contenu peut-elle complètement atténuer cela ?
A : CSP réduit l'impact des scripts injectés mais ne résout pas le problème de l'empoisonnement du cache. Utilisez CSP + contrôle de cache + patching pour une atténuation complète.

Q : Quelle est l'urgence de cette mise à jour ?
A : Il est important : l'exploitation est de faible gravité sur CVSS mais peut être utilisée pour des attaques d'empoisonnement de cache évolutives qui affectent de nombreux utilisateurs. Priorisez le patching si vous exécutez Nuxt/Nitro dans une partie de votre chaîne de livraison.

---

Recommandations finales — liste de contrôle priorisée

1. Inventaire : Recherchez l'utilisation de Nitro/Nuxt sur votre site, CI et fournisseur d'hébergement.
2. Patch : Mettre à jour @nuxt/nitro-server à 4.4.6+ partout où cela apparaît.
3. Protéger : Appliquer les règles WAF et définir les en-têtes Cache-Control/Vary pour empêcher l'utilisation de caches partagés pour les fragments dynamiques.
4. Purger : Effacer les caches au niveau du CDN et des couches de périphérie.
5. Renforcer : Mettre en œuvre/renforcer CSP, assainir le contenu rendu par le serveur et s'assurer que les clés de cache varient en fonction des en-têtes sensibles à l'utilisateur.
6. Automatiser : Ajouter des analyses SCA de routine et des mises à jour automatiques des dépendances à votre pipeline.

---

Si vous souhaitez un manuel d'opérations adapté à votre architecture d'hébergement WordPress (classique vs. sans tête vs. hybride), notre équipe de sécurité peut cartographier les étapes de votre pile et fournir des extraits de règles WAF recommandés et des scripts de test que vous pouvez exécuter en préproduction avant le déploiement en production.