Nome del plugin	@nuxt/nitro-server
Tipo di vulnerabilità	Script tra siti (XSS)
Numero CVE	CVE-2026-46342
Urgenza	Basso
Data di pubblicazione CVE	2026-05-20
URL di origine	CVE-2026-46342

Nuxt Nitro ‘__nuxt_island’ Avvelenamento della Cache Condivisa (CVE-2026-46342) — Cosa Devono Sapere i Proprietari di Siti WordPress

Autore: Team di sicurezza WP-Firewall
Data: 2026-05-20
Etichette: sicurezza, WordPress, WAF, Nuxt, headless, CVE-2026-46342

Riepilogo: Una vulnerabilità recentemente divulgata nel server Nuxt Nitro colpisce le versioni >= 4.2.0 e <= 4.4.5. Può portare all'avvelenamento della cache condivisa e Cross-Site Scripting (XSS) tramite il __nuxt_island endpoint. Il problema è stato corretto nella versione 4.4.6. Se il tuo sito WordPress si integra con front-end JavaScript, architetture headless, rendering edge CDN, o utilizza componenti Nuxt/Nitro nella tua toolchain, questo avviso spiega il rischio, i metodi di rilevamento, le mitigazioni (inclusi regole di firewall/edge di emergenza) e strategie di indurimento della supply chain a lungo termine.

---

Perché questo è importante per i proprietari di siti WordPress

La maggior parte dei siti WordPress utilizza template PHP e rendering lato server tramite lo stack WordPress. Tuttavia, un numero crescente di siti WordPress è integrato con moderni front-end JavaScript (Nuxt, Next, Remix) per prestazioni e esperienza dello sviluppatore — un'architettura “headless” o “decoupled”. Quei front-end si basano comunemente su server basati su Node, middleware Nitro e cache/CDN edge.

Il problema segnalato (CVE-2026-46342) colpisce un endpoint del server Nitro utilizzato dai front-end Nuxt: __nuxt_island. Quando il server non riesce a legare strettamente le risposte alle proprietà della richiesta originale, una cache condivisa può servire una risposta creata per un utente a un altro utente. Se quella risposta contiene contenuti controllati dall'attaccante (ad esempio, HTML non sanitizzato o frammenti di script), un attaccante può avvelenare le cache e attivare Cross-Site Scripting per molti visitatori del sito.

Anche se il tuo backend WordPress non esegue direttamente Node, i sistemi WordPress possono essere colpiti quando:

• Il tuo sito WordPress utilizza un front-end Nuxt o Nitro che estrae dati dall'API REST di WordPress o da GraphQL.
• Il tuo ambiente di hosting utilizza servizi di rendering lato server o rendering edge che includono componenti basati su Nitro.
• Il tuo CI/CD, pipeline di build o servizi di terze parti utilizzano il pacchetto vulnerabile per generare anteprime, distribuire front-end o rendere pagine all'edge.

Questo avviso è scritto da una prospettiva di sicurezza WordPress. Ci concentreremo su passaggi pratici di rilevamento e rimedio che puoi applicare immediatamente, oltre a strategie di indurimento a lungo termine e indicazioni sulle regole WAF/edge.

---

Panoramica tecnica — cosa è rotto

Ad alto livello:

• IL __nuxt_island L'endpoint è responsabile del rendering o dell'idratazione dei componenti isolati (piccoli frammenti interattivi) nel modello di rendering ibrido di Nuxt.
• Il comportamento vulnerabile: le risposte restituite dall'endpoint non sono sufficientemente legate alle proprietà della richiesta (origine, intestazioni, cookie, parametri di query). Se uno strato di caching (CDN, proxy inverso o cache condivisa lato server) memorizza quella risposta senza appropriati header Vary/Cache-Control o chiavi di cache, la risposta memorizzata può essere servita ad altre richieste che differiscono in proprietà critiche della richiesta.
• Se un attaccante può creare una richiesta che include contenuti controllati dall'attaccante (ad es., tramite proprietà iniettate, payload nei parametri di query o dati riflessi dalle risposte API) e causare che quella risposta venga memorizzata nella cache, l'attaccante può avvelenare la cache condivisa. Quando altri utenti ricevono quella risposta memorizzata, qualsiasi script malevolo al suo interno verrà eseguito nei loro browser (scenario XSS riflesso o memorizzato) — risultando in un impatto diffuso poiché le cache servono molti utenti.

Il risultato finale: un singolo exploit può trasformarsi in un massiccio XSS tramite una pagina memorizzata nella cache avvelenata o un frammento isolato.

---

Superficie di attacco per i siti WordPress

Ecco modelli di integrazione comuni che espongono i siti alimentati da WordPress a questo problema:

• WordPress headless + front-end Nuxt:
  • WordPress serve contenuti tramite REST API / GraphQL.
  • Il front-end Nuxt utilizza Nitro per il rendering server-side di isole che includono contenuti da WP.
  • Un pacchetto Nitro vulnerabile utilizzato nel processo front-end può causare avvelenamento della cache.
• Rendering edge / anteprima CDN / generazione di immagini OG:
  • Alcuni generatori di anteprima edge o endpoint di immagini includono rendering basato su Nitro.
  • Se il tuo fornitore di hosting o CI utilizza componenti Nitro, quegli endpoint potrebbero essere interessati.
• Strumenti per sviluppatori:
  • Sistemi di build e anteprima (storybook, anteprime SSR, generatori di siti statici) che installano la dipendenza vulnerabile possono creare o caricare artefatti avvelenati o output memorizzati nella cache.
• Integrazioni di terze parti:
  • I fornitori di plugin, i costruttori di temi o i fornitori di servizi headless potrebbero eseguire anteprime basate su Nitro. Se sono compromessi o utilizzano versioni vulnerabili, i siti dei clienti potrebbero essere colpiti indirettamente.

Se il tuo sito WordPress è puramente classico (nessun front-end headless, nessun strumento Node nei deployment), il rischio è molto più basso. Ma negli ambienti DevOps moderni conviene controllare.

---

Come gli attaccanti possono sfruttarlo (scenari pratici)

• XSS riflesso tramite frammento di isola memorizzato nella cache:
  • L'attaccante invia una richiesta appositamente creata a __nuxt_island con un parametro controllato dall'attaccante.
  • Nitro genera un frammento contenente il parametro senza una corretta sanificazione.
  • La CDN memorizza nella cache il frammento per una chiave condivisa.
  • I visitatori successivi ricevono il frammento memorizzato nella cache; il JavaScript dell'attaccante viene eseguito nel loro browser.
• Avvelenamento simile a quello memorizzato tramite dati upstream:
  • Se il front-end rende i dati da un'API di terze parti o da un sistema di commenti che accetta input degli utenti, un attaccante memorizza input dannosi in quella fonte.
  • Il server rende l'isola con il contenuto dannoso; la risposta viene memorizzata nella cache e successivamente servita ad altri.
• Abuso su larga scala:
  • Le cache edge significano che un singolo oggetto memorizzato nella cache può influenzare migliaia di visitatori. Gli attaccanti preferiscono le rotte di avvelenamento della cache poiché l'impatto è amplificato.

---

Patch e aggiornamento — la correzione più importante

Se utilizzi Nuxt/Nitro in qualsiasi parte del tuo stack, aggiorna immediatamente il pacchetto interessato:

• Ricercato: @nuxt/nitro-server ≥ 4.2.0 e ≤ 4.4.5
• Corretto in: 4.4.6 (aggiorna a 4.4.6 o versioni successive)

Azioni:

1. Per progetti che utilizzano npm/yarn/pnpm:
   • Esegui npm install @nuxt/nitro-server@^4.4.6 (o aggiorna il tuo package.json e esegui il tuo gestore di pacchetti).
   • Aggiorna i lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) e impegnali.
2. Per build containerizzate:
   • Ricostruisci le immagini e ridistribuisci dopo aver aggiornato il pacchetto e il lockfile.
   • Evita di fare affidamento su versioni implicite più recenti — utilizza versioni bloccate e ricostruisci frequentemente le immagini.
3. Per servizi edge o di anteprima che non controlli:
   • Contatta il tuo fornitore o proprietario del servizio e richiedi conferma della patch.
   • Istruiscili ad aggiornare a 4.4.6+ e a invalidare le cache dopo la patch.

Se non puoi aggiornare immediatamente, utilizza le mitigazioni qui sotto.

---

Mitigazioni immediate che puoi applicare ora (anche prima di applicare la patch)

Queste sono misure pratiche che puoi implementare rapidamente per ridurre l'esposizione.

1. Disabilita la cache condivisa per l'endpoint dell'isola
   • Assicurati che le risposte da __nuxt_island siano contrassegnate come non memorizzabili dalle cache condivise:
   • Impostare Cache-Control: privato, no-cache, no-store, deve-rivalidare (scegli la direttiva appropriata per il tuo ambiente).
   • Aggiungere Varia le intestazioni per includere cookie/autenticazione/host se le risposte dipendono da esse: Vary: Cookie, Autorizzazione, Accept-Encoding, Host.
   • Se controlli le regole CDN, crea una regola per bypassare la cache per qualsiasi percorso che corrisponda a /__nuxt_island o simili.
2. Patch virtuale con le tue regole WAF / edge
   • Crea una o più regole del firewall per bloccare o sfidare le richieste a /__nuxt_island che contengono payload sospetti:
   • Blocca le richieste contenenti <script, unerrore=, carico=, token di script codificati (ad es., <script), o modelli XSS evidenti nelle stringhe di query.
   • Limita la velocità o sfida con CAPTCHA le richieste anomale a quel percorso.
   • Se possibile, blocca le richieste dove Accetta Le intestazioni indicano il rendering HTML più valori di query sospetti.
   • Esempio di regola in stile ModSecurity (concettuale):

   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:|script)" "id:100002,phase:2,log,deny,msg:'XSS pattern in request args targeting island endpoint'"
         

   Adatta gli ID e la severità al tuo ambiente. Testa prima di bloccare in produzione.

3. Pulisci le cache
   • Se credi che si sia verificata una contaminazione (o per precauzione), pulisci le cache a tutti i livelli:
     • Cache edge CDN
     • Cache del proxy inverso (Varnish)
     • Cache dell'applicazione (se presenti)
   • Usa intestazioni di invalidazione della cache o versioning per i frammenti dell'isola se necessario.
4. Aggiungi una Content Security Policy (CSP)
   • Implementa o stringi CSP per le pagine che includono frammenti dell'isola:
     • Esempio: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none'; base-uri 'self';
     • Una CSP rigorosa può limitare l'impatto di XSS anche se un attaccante inietta un tag script.
5. Aumenta la validazione/sanitizzazione della risposta
   • Lato server (Nuxt o servizi downstream), assicurati che qualsiasi dato legato alle risposte sia correttamente eseguito o sanitizzato prima di essere incluso nell'HTML renderizzato dal server.
6. Monitoraggio dei log e del traffico
   • Cerca aumenti improvvisi nelle richieste a __nuxt_island.
   • Ispeziona per schemi ricorrenti nelle stringhe di query o nei corpi POST che includono token di script.
   • Monitora i modelli di hit della cache edge e le chiavi della cache.

---

Suggerimenti per regole WAF e edge (concreti)

Di seguito ci sono regole pratiche che puoi adattare. Sono intenzionalmente generiche e dovrebbero essere testate prima in staging.

Frammento Nginx per impostare le intestazioni della cache per l'endpoint isola:

posizione ~* /__nuxt_island {

Regole ModSecurity semplici (concettuali):

# 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|script|onerror=|onload=|javascript:)" "t:none,deny,log"

Indurimento della risposta tramite edge worker (pseudo-codice):

• Intercettare le risposte per /__nuxt_island.
• Se la risposta contiene <script o JS inline sospetto E la richiesta non ha una corretta autenticazione o intestazione prevista, scartare/mettere in sfida la risposta e non memorizzare nella cache.
• Altrimenti, assicurati che la risposta abbia Cache-Control: privato.

Indurimento della chiave di cache:

• Assicurati che le chiavi di cache includano proprietà specifiche per l'utente dove il contenuto varia (Cookie, intestazione Authorization, Accept-Language, ecc.). Una chiave di cache mal configurata che ignora i cookie è una causa principale di avvelenamento.

Limitazione della velocità:

• Applicare limiti di frequenza sulle richieste a __nuxt_island, ad esempio, 5 richieste al minuto per IP, per ridurre la fattibilità dei tentativi di avvelenamento.

Ricorda: fare passi incrementali in staging e monitorare i falsi positivi. Le regole WAF sono strumenti imprecisi; testare per evitare di interrompere il traffico legittimo.

---

Rilevamento: come sapere se sei colpito

1. Inventaria il tuo stack
   • Cerca nel tuo codice sorgente, nelle configurazioni CI/CD e nei log di build riferimenti a @nuxt/nitro-server, nuxt, nitro, E __nuxt_island.
   • Utilizzo npm ls @nuxt/nitro-server o equivalente per elencare le versioni installate.
   • Controllo package-lock.json, yarn.lock, pnpm-lock.yaml per trovare dipendenze transitorie.
2. Ispeziona i log del server e del CDN
   • Cerca traffico verso percorsi come /__nuxt_island (o endpoint simili di island/hydration).
   • Cerca richieste con stringhe di query sospette contenenti script, un errore, o varianti codificate (%3C, <).
3. Rivedi le risposte memorizzate nella cache
   • Recupera l'HTML della cache edge per le pagine e ispeziona per iniezioni di 6. tag o gestori di eventi inline che non hai creato.
   • Se il tuo CDN supporta l'ispezione della cache, verifica gli oggetti memorizzati nella cache per contenuti insoliti.
4. Scansione automatizzata
   • Esegui scanner di dipendenze (npm audit, strumenti SCA) per localizzare versioni di pacchetti vulnerabili.
   • Usa scanner web (rilevatori XSS) per sondare gli endpoint di rendering in modo sicuro in staging.

---

Se pensi di essere stato colpito — passi immediati per l'incidente

1. Rimuovi l'endpoint vulnerabile dalla cache pubblica:
   • Imposta temporaneamente Cache-Control: no-store sugli endpoint island.
   • Pulisci le cache su CDN e proxy.
2. Ricostruisci e applica patch:
   • Aggiornamento @nuxt/nitro-server a 4.4.6+.
   • Ricostruire i contenitori e ridistribuire.
3. Contenere e indagare:
   • Isolare server o processi sospetti.
   • Dumpare i log per la finestra temporale di sospetta contaminazione.
   • Identificare e elencare le chiavi di cache interessate e purgarle.
4. Pulisci e rinforza:
   • Rimuovere o sanificare eventuali payload dannosi persistenti nelle fonti di dati upstream.
   • Ruotare i segreti che potrebbero essere stati esposti.
   • Rivalutare CSP e sanificazione degli input.
5. Comunicare:
   • Se i dati degli utenti erano a rischio o l'exploit era pubblico, seguire la vostra politica di divulgazione degli incidenti e notificare le parti interessate.

---

Indurimento a lungo termine della catena di fornitura e del deployment per i proprietari di WordPress

• Mantenere un inventario delle dipendenze:
  • Tracciare le dipendenze di Node e PHP utilizzate dal tuo sito e dalla tua pipeline CI.
  • Eseguire periodicamente scansioni SCA (Analisi della Composizione del Software) su tutti i pacchetti.
• Bloccare e fissare le dipendenze:
  • Utilizzare pin di versione esatti in pacchetto.json per pacchetti critici per la produzione.
  • Impegnare i lockfile e eseguire ricostruzioni regolari.
• Automatizzare gli aggiornamenti:
  • Utilizzare strumenti automatizzati (stile renovate o audit programmati) per proporre aggiornamenti; testare e distribuire regolarmente.
  • Considera una pipeline automatizzata che ricostruisce le immagini e esegue test di integrazione quando vengono rilasciate patch di dipendenza.
• Limita la superficie di caching:
  • Abilita solo il caching condiviso aggressivo per asset veramente statici.
  • Per frammenti dinamici o frammenti personalizzati per l'utente, utilizza Cache-Control: privato o salta il caching.
• Indurire il rendering front-end:
  • Assicurati che i frammenti renderizzati dal server escano i dati dell'utente per impostazione predefinita.
  • Adotta motori di template che eseguono l'auto-escape, o sanitizza esplicitamente i campi pericolosi.
• Richiedi intestazioni sicure:
  • CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, Strict-Transport-Security — mantieni queste forzate in tutto il sito.
• Monitora e registra:
  • I log aggregati per l'accesso agli endpoint e il comportamento della cache aiutano a rilevare anomalie prima.
  • Monitora gli eventi WAF/edge e mantieni le regole sotto revisione.

---

Raccomandazioni specifiche per WordPress (lista di controllo pratica)

• Se il tuo sito è headless:
  • Conferma quali versioni e pacchetti front-end sono utilizzati; aggiorna Nitro dove necessario.
  • Assicurati che le risposte della tua API REST di WordPress codifichino e sanitizzino correttamente i campi HTML.
  • Assicurati che gli ambienti di anteprima e CI siano sicuri come la produzione.
• Se il tuo sito utilizza una pipeline Jamstack o SSR (ad es., Netlify, Vercel, altri fornitori):
  • Contatta il tuo fornitore per confermare lo stato del pacchetto Nitro nei loro ambienti.
  • Pulisci le cache edge dopo gli aggiornamenti.
• Se il tuo sito è un WordPress classico ma fai affidamento su plugin o servizi di terze parti che potrebbero generare pagine al limite:
  • Controlla i fornitori di plugin per notifiche e aggiornamenti.
  • Chiedi ai team di hosting o piattaforma riguardo all'uso di Nitro nel loro stack.

---

Segnali di monitoraggio da tenere d'occhio nelle prossime settimane

• Aumento delle richieste in arrivo __nuxt_island con payload che includono codificati 6. moduli.
• Apparizione improvvisa di script inline nell'HTML memorizzato nella cache servito dal tuo CDN.
• Aumenti dei colpi delle regole WAF/edge legati agli endpoint isolati.
• Segnalazioni di popup, reindirizzamenti o javascript inaspettati su pagine che erano precedentemente statiche.

Se vedi questi segnali, trattali seriamente: svuota le cache, applica patch virtuali e aggiorna i pacchetti.

---

Proteggi il tuo sito gratuitamente — Inizia con WP-Firewall Basic

Se desideri un punto di partenza semplice ed efficace per proteggere WordPress mentre convalidi e applichi patch ai componenti upstream, considera il nostro piano Basic (Gratuito). Ti offre protezioni essenziali che riducono l'esposizione alle minacce delle applicazioni web mentre implementi le mitigazioni mirate sopra.

Cosa ottieni con il piano Basic (Gratuito):

• Firewall gestito che protegge le superfici di attacco comuni
• WAF per bloccare modelli comuni di iniezione e XSS
• Scanner malware per rilevare payload sospetti iniettati
• Larghezza di banda illimitata e scansione continua
• Copertura di mitigazione per i 10 principali rischi OWASP

Iscriviti e attiva il piano gratuito per aggiungere uno strato protettivo mentre applichi la patch Nuxt/Nitro e i passaggi di indurimento: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Esempio: Come risponderemmo a livello WAF (manuale operativo)

1. Triaggio:
   • Identifica se il sito utilizza versioni vulnerabili di Nitro.
   • Se sì, abilita immediatamente il set di regole WAF che mira ai modelli XSS a percorso isolato.
2. Applica le regole di patch virtuali:
   • Contrassegna temporaneamente /__nuxt_island le risposte come non memorizzabili per le cache condivise tramite l'edge.
   • Aggiungi regole in entrata per bloccare le richieste contenenti token di script.
3. Avviso:
   • Notifica i proprietari del sito e gli sviluppatori di aggiornare a 4.4.6+.
   • Pianifica una finestra di distribuzione per aggiornare le dipendenze e ricostruire i contenitori.
4. Verifica:
   • Dopo aver distribuito l'aggiornamento + le regole WAF, esegui la suite di test automatizzati e le sonde XSS simulate in staging.
   • Dopo aver superato i test, rimuovi le regole WAF eccessivamente restrittive che potrebbero bloccare il traffico valido e fai affidamento sulla correzione upstream.
5. Post mortem:
   • Rivedi perché la chiave della cache o le intestazioni Vary erano configurate in modo errato.
   • Migliora i controlli di distribuzione per garantire che gli aggiornamenti delle dipendenze vengano applicati più rapidamente.

---

Domande frequenti (brevi)

D: Il mio sito è un WordPress classico senza front-end Node — sono colpito?
R: Se non ci sono componenti Nuxt/Nitro nel tuo stack, la tua esposizione diretta è minima. Ma controlla gli strumenti per sviluppatori, i servizi di anteprima o le CDN utilizzate dal tuo sito per l'uso di Nitro.

D: Ho aggiornato a 4.4.6 ma vedo ancora script sospetti nelle pagine memorizzate nella cache — cosa fare dopo?
R: Pulisci le cache su tutti i livelli (edge, CDN, proxy inverso). L'aggiornamento potrebbe non rimuovere automaticamente le risorse avvelenate memorizzate nella cache in precedenza.

D: La Content Security Policy può mitigare completamente questo?
R: CSP riduce l'impatto degli script iniettati ma non risolve il problema dell'avvelenamento della cache. Usa CSP + cache-control + patching per una mitigazione completa.

D: Quanto è urgente questo aggiornamento?
R: È importante: l'exploit ha una gravità bassa su CVSS ma può essere utilizzato per attacchi di avvelenamento della cache scalabili che colpiscono molti utenti. Dai priorità alla patch se esegui Nuxt/Nitro in qualsiasi parte della tua catena di distribuzione.

---

Raccomandazioni finali — checklist prioritaria

1. Inventario: Cerca l'uso di Nitro/Nuxt nel tuo sito, CI e fornitore di hosting.
2. Patch: Aggiorna @nuxt/nitro-server a 4.4.6+ ovunque appaia.
3. Proteggi: Applica le regole WAF e imposta gli header Cache-Control/Vary per prevenire l'uso della cache condivisa per frammenti dinamici.
4. Pulisci: Cancella le cache nei livelli CDN e edge.
5. Indurisci: Implementa/rinforza CSP, sanitizza i contenuti renderizzati dal server e assicurati che le chiavi della cache varino in base agli header sensibili per l'utente.
6. Automatizza: Aggiungi scansioni SCA di routine e aggiornamenti automatici delle dipendenze al tuo pipeline.

---

Se desideri un playbook operativo personalizzato per la tua architettura di hosting WordPress (classica vs. headless vs. ibrida), il nostro team di sicurezza può mappare i passaggi al tuo stack e fornire frammenti di regole WAF consigliati e script di test che puoi eseguire in staging prima del rollout in produzione.