Plugin-navn	@nuxt/nitro-server
Type af sårbarhed	Cross-Site Scripting (XSS)
CVE-nummer	CVE-2026-46342
Hastighed	Lav
CVE-udgivelsesdato	2026-05-20
Kilde-URL	CVE-2026-46342

Nuxt Nitro ‘__nuxt_island’ Delt-Cache Forgiftning (CVE-2026-46342) — Hvad WordPress-webstedsejere Skal Vide

Forfatter: WP-Firewall Sikkerhedsteam
Dato: 2026-05-20
Tags: sikkerhed, WordPress, WAF, Nuxt, headless, CVE-2026-46342

Oversigt: En nyligt offentliggjort sårbarhed i Nuxt Nitro-serveren påvirker versioner >= 4.2.0 og <= 4.4.5. Det kan føre til delt-cache forgiftning og Cross-Site Scripting (XSS) via __nuxt_island endpoint. Problemet er rettet i 4.4.6. Hvis dit WordPress-websted integrerer med JavaScript front-end, headless arkitekturer, CDN edge rendering, eller bruger Nuxt/Nitro komponenter i din værktøjslinje, forklarer denne rådgivning risikoen, detektionsmetoder, afbødninger (inklusive nød-firewall/edge regler) og langsigtede forsyningskæde-hærdningsstrategier.

---

Hvorfor dette er vigtigt for ejere af WordPress-websteder

De fleste WordPress-websteder bruger PHP-skabeloner og server-side rendering via WordPress-stakken. Dog er et stigende antal WordPress-websteder integreret med moderne JavaScript front-ends (Nuxt, Next, Remix) for ydeevne og udvikleroplevelse — en “headless” eller “decoupled” arkitektur. Disse front-ends er almindeligvis afhængige af Node-baserede servere, Nitro middleware og edge caches/CDNs.

Det rapporterede problem (CVE-2026-46342) påvirker en Nitro server endpoint, der bruges af Nuxt front-ends: __nuxt_island. Når serveren ikke formår at binde svar tæt til de oprindelige anmodnings egenskaber, kan en delt cache servere et svar, der er oprettet til én bruger, til en anden bruger. Hvis det svar indeholder angriber-kontrolleret indhold (for eksempel usanitiseret HTML eller scriptfragmenter), kan en angriber forgifte caches og udløse Cross-Site Scripting for mange websted besøgende.

Selv hvis din WordPress backend ikke direkte kører Node, kan WordPress-systemer blive påvirket, når:

• Dit WordPress-websted bruger en Nuxt eller Nitro front-end, der henter data fra WordPress REST API eller GraphQL.
• Dit hostingmiljø bruger server-side rendering eller edge-rendering tjenester, der inkluderer Nitro-baserede komponenter.
• Din CI/CD, build pipeline, eller tredjeparts tjenester bruger den sårbare pakke til at generere forhåndsvisninger, implementere front-ends, eller render sider ved kanten.

Denne rådgivning er skrevet fra et WordPress sikkerhedsperspektiv. Vi vil fokusere på praktiske detektions- og afhjælpningsmetoder, du kan anvende med det samme, plus langsigtet hærdning og WAF/edge-regel vejledning.

---

Teknisk oversigt — hvad der er brudt

På et højt niveau:

• De __nuxt_island endpoint er ansvarlig for at renderere eller hydrere isolerede komponenter (små interaktive fragmenter) i Nuxt’s hybride rendering model.
• Den sårbare adfærd: svar, der returneres af endpoint, er ikke tilstrækkeligt bundet til anmodnings egenskaber (oprindelse, headers, cookies, forespørgselsparametre). Hvis et caching lag (CDN, reverse proxy, eller server-side delt cache) gemmer det svar uden passende Vary/Cache-Control headers eller cache nøgler, kan det cachede svar blive serveret til andre anmodninger, der adskiller sig i kritiske anmodnings egenskaber.
• Hvis en angriber kan udforme en anmodning, der inkluderer angriber-kontrolleret indhold (f.eks. via injicerede egenskaber, payloads i forespørgselsparametre, eller reflekterede data fra API-svar) og få det svar til at blive cachet, kan angriberen forgifte den delte cache. Når andre brugere modtager det cachede svar, vil ethvert ondsindet script inde i det blive udført i deres browsere (reflekteret eller gemt XSS-scenarie) — hvilket resulterer i omfattende påvirkning, da caches serverer mange brugere.

Det endelige resultat: et enkelt udnyttelse kan blive til masse XSS via en forgiftet cachet side eller ø-fragment.

---

Angrebsoverflade for WordPress-websteder

Her er almindelige integrationsmønstre, der udsætter WordPress-drevne websteder for dette problem:

• Headless WordPress + Nuxt front-end:
  • WordPress leverer indhold via REST API / GraphQL.
  • Nuxt front-end bruger Nitro til server-rendering af øer, der inkluderer indhold fra WP.
  • Sårbar Nitro-pakke brugt i front-end-processen kan forårsage cache-forgiftning.
• Edge rendering / CDN forhåndsvisning/OG billedegenerering:
  • Nogle edge forhåndsvisningsgeneratorer eller billede-endpoints inkluderer Nitro-baseret rendering.
  • Hvis din hostingudbyder eller CI bruger Nitro-komponenter, kan disse endpoints blive påvirket.
• Udviklerværktøjer:
  • Bygge- og forhåndsvisningssystemer (storybook, SSR forhåndsvisninger, statiske site-generatorer), der installerer den sårbare afhængighed, kan oprette eller uploade forgiftede artefakter eller cachet output.
• Tredjepartsintegrationer:
  • Plugin-leverandører, tema-byggerne eller headless-serviceudbydere kan køre Nitro-baserede forhåndsvisninger. Hvis de er kompromitteret eller bruger sårbare versioner, kan klienternes websteder blive påvirket indirekte.

Hvis dit WordPress-websted er rent klassisk (ingen headless front-end, ingen Node-værktøjer i implementeringer), er risikoen meget lavere. Men i moderne DevOps-miljøer kan det betale sig at tjekke.

---

Hvordan angribere kan udnytte det (praktiske scenarier)

• Reflekteret XSS via cachet ø-fragment:
  • Angriberen sender en særligt udformet anmodning til __nuxt_island med angriber-kontrolleret parameter.
  • Nitro genererer et fragment, der indeholder parameteren uden passende sanitering.
  • CDN cacher fragmentet for en delt nøgle.
  • Efterfølgende besøgende modtager det cachede fragment; angriberens JavaScript kører i deres browser.
• Opbevaringslignende forgiftning via upstream-data:
  • Hvis front-end'en gengiver data fra et tredjeparts-API eller fra et kommentarsystem, der accepterer brugerinput, gemmer en angriber ondsindet input i den kilde.
  • Serveren gengiver øen med det ondsindede indhold; svaret caches og serveres senere til andre.
• Storskala misbrug:
  • Edge-cacher betyder, at et enkelt cachet objekt kan påvirke tusindvis af besøgende. Angribere foretrækker cache-forgiftning ruter, da virkningen forstærkes.

---

Patch og opdater — den vigtigste løsning

Hvis du bruger Nuxt/Nitro i nogen del af din stak, opdater den berørte pakke straks:

• Påvirket: @nuxt/nitro-server ≥ 4.2.0 og ≤ 4.4.5
• Patch'et i: 4.4.6 (opgrader til 4.4.6 eller senere)

Handlinger:

1. For projekter, der bruger npm/yarn/pnpm:
   • Kør npm install @nuxt/nitro-server@^4.4.6 (eller opdater din package.json og kør din pakkeadministrator).
   • Opdater låse-filer (package-lock.json, yarn.lock, pnpm-lock.yaml) og commit dem.
2. For containeriserede builds:
   • Genopbyg billeder og genudfør efter opdatering af pakken og låsefilen.
   • Undgå at stole på implicitte seneste versioner - brug fastlåste versioner og genopbyg billeder ofte.
3. For kant- eller forhåndsvisningstjenester, som du ikke kontrollerer:
   • Kontakt din udbyder eller tjeneste ejer og anmod om bekræftelse af patching.
   • Instruktioner til dem om at opdatere til 4.4.6+ og at invalidere caches efter patching.

Hvis du ikke kan opdatere med det samme, brug de nedenstående afbødninger.

---

Umiddelbare afbødninger, du kan anvende nu (selv før patching)

Disse er praktiske foranstaltninger, du hurtigt kan implementere for at reducere eksponering.

1. Deaktiver delt caching for ø-endenpunktet
   • Sørg for, at svar fra __nuxt_island er markeret som ikke-cachebare af delte caches:
   • Indstil Cache-Control: privat, no-cache, no-store, must-revalidate (vælg passende direktiv til dit miljø).
   • Tilføje Variér overskrifter for at inkludere cookies/autorisation/vært, hvis svar afhænger af dem: Variér: Cookie, Authorization, Accept-Encoding, Host.
   • Hvis du kontrollerer CDN-regler, opret en regel for at omgå cache for enhver sti, der matcher /__nuxt_island eller lignende.
2. Virtuel patching med dine WAF / kantregler
   • Opret en eller flere firewall-regler for at blokere eller udfordre anmodninger til /__nuxt_island der indeholder mistænkelige payloads:
   • Blokeringsanmodninger, der indeholder <script, en fejl=, onload=, kodede script tokens (f.eks., <script), eller åbenlyse XSS mønstre i forespørgselsstrenge.
   • Ratebegræns eller CAPTCHA-udfordr anomaløse anmodninger til den sti.
   • Hvis det er muligt, blokér anmodninger hvor Accepter headers angiver HTML rendering plus mistænkelige forespørgselsværdier.
   • Eksempel på ModSecurity-stil regel (konceptuel):

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

   Tilpas ID'er og alvorlighed til dit miljø. Test før produktionsblokering.

3. Ryd caches
   • Hvis du mener, at forurening er sket (eller som en forholdsregel), ryd caches på alle niveauer:
     • CDN kantcaches
     • Reverse proxy caches (Varnish)
     • Applikationscaches (hvis nogen)
   • Brug cache-busting headers eller versionering for ø-fragmenter, hvis nødvendigt.
4. Tilføj Content Security Policy (CSP)
   • Implementer eller stram CSP for sider, der inkluderer ø-fragmenter:
     • Eksempel: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none'; base-uri 'self';
     • En striks CSP kan begrænse virkningen af XSS, selvom en angriber injicerer et script-tag.
5. Øg svarvalidering/sanitering
   • På serversiden (Nuxt eller downstream tjenester), sørg for, at alle data bundet i svar er korrekt undsluppet eller saniteret, før det inkluderes i server-renderet HTML.
6. Overvåg logs og trafik
   • Se efter pludselige stigninger i anmodninger til __nuxt_island.
   • Inspicer for tilbagevendende mønstre i forespørgselsstrenge eller POST-kroppe, der inkluderer skript tokens.
   • Overvåg edge cache hit mønstre og cache nøgler.

---

WAF og edge regel forslag (konkrete)

Nedenfor er praktiske regler, du kan tilpasse. De er bevidst generiske og bør testes i staging først.

Nginx snippet til at indstille cache headers for ø-ende point:

location ~* /__nuxt_island {

Enkle ModSecurity regler (konceptuelle):

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

Respons-hærdning via edge worker (pseudo-kode):

• Intercept respons for /__nuxt_island.
• Hvis responsen indeholder <script eller mistænkelig inline JS OG forespørgslen har ingen korrekt autentificering eller forventet header, drop/udfordre responsen og cache ikke.
• Ellers, sørg for at responsen har Cache-Control: privat.

Cache nøgle hærdning:

• Sørg for, at cache nøgler inkluderer bruger-specifikke egenskaber, hvor indholdet varierer (Cookie, Authorization header, Accept-Language, osv.). En forkert konfigureret cache nøgle, der ignorerer cookies, er en væsentlig årsag til forgiftning.

Ratebegrænsning:

• Anvend hastighedsbegrænsninger på forespørgsler til __nuxt_island, f.eks. 5 forespørgsler pr. minut pr. IP, for at reducere muligheden for forgiftningsforsøg.

Husk: tag gradvise skridt i staging og overvåg falske positiver. WAF regler er stumpe instrumenter; test for at undgå at bryde legitim trafik.

---

Detektion: hvordan man ved, om du er påvirket

1. Gennemgå din stak
   • Søg i din kodebase, CI/CD-konfigurationer og build logs for referencer til @nuxt/nitro-server, nuxt, nitro, og __nuxt_island.
   • Bruge npm ls @nuxt/nitro-server eller tilsvarende for at liste installerede versioner.
   • Check package-lock.json, yarn.lock, pnpm-lock.yaml for at finde transiente afhængigheder.
2. Inspicer server- og CDN-logs
   • Se efter trafik til stier som /__nuxt_island (eller lignende ø/hydrering endpoints).
   • Se efter anmodninger med mistænkelige forespørgselsstrenge, der indeholder script, en fejl, eller kodede varianter (%3C, <).
3. Gennemgå cachede svar
   • Hent cachet edge HTML for sider og inspicer for injicerede . tags eller inline event handlers, som du ikke har skrevet.
   • Hvis din CDN understøtter cacheinspektion, skal du verificere cachede objekter for usædvanligt indhold.
4. Automatiseret scanning
   • Kør afhængighedsscannere (npm audit, SCA værktøjer) for at finde sårbare pakkeversioner.
   • Brug webscannere (XSS detektorer) til sikkert at undersøge render endpoints i staging.

---

Hvis du tror, du er blevet ramt — øjeblikkelige hændelsestrin

1. Tag den sårbare endpoint ud af offentlig caching:
   • Midlertidigt indstillet Cache-Control: no-store på ø-enderpunkter.
   • Ryd caches på tværs af CDN og proxyer.
2. Genopbyg & patch:
   • Opdatering @nuxt/nitro-server til 4.4.6+.
   • Genopbyg containere og genudsend.
3. Indhold og undersøg:
   • Isoler mistænkelige servere eller processer.
   • Dump logs for tidsvinduet af mistænkt forgiftning.
   • Identificer og list berørte cache-nøgler og ryd dem.
4. Ryd op og hårdned:
   • Fjern eller saner eventuelle ondsindede payloads, der er bevaret i upstream datakilder.
   • Rotér hemmeligheder, der kan være blevet eksponeret.
   • Vurder CSP og input-sanitering igen.
5. Kommuniker:
   • Hvis brugerdata var i fare eller udnyttelsen var offentlig, følg din hændelsesoffentliggørelsespolitik og underret interessenter.

---

Langsigtet forsyningskæde og implementeringshærdning for WordPress-ejere

• Vedligehold et afhængighedsinventar:
  • Spor Node- og PHP-afhængigheder, der bruges af dit site og din CI-pipeline.
  • Kør periodisk SCA (Software Composition Analysis) scanninger på tværs af alle pakker.
• Fastlåse og låse afhængigheder:
  • Brug nøjagtige versionslåse i package.json til produktionskritiske pakker.
  • Forpligt lockfiler og kør regelmæssige genopbygninger.
• Automatiser opdateringer:
  • Brug automatiserede værktøjer (renovate-stil eller planlagte revisioner) til at foreslå opdateringer; test og implementer regelmæssigt.
  • Overvej en automatiseret pipeline, der genopbygger billeder og kører integrationstest, når afhængighedspatches frigives.
• Begræns cache-overfladen:
  • Aktivér kun aggressiv delt caching for virkelig statiske aktiver.
  • For dynamiske fragmenter eller bruger-personaliserede fragmenter, brug Cache-Control: privat eller omgå caching.
• Hærd front-end rendering:
  • Sørg for, at server-renderede fragmenter undgår brugerdata som standard.
  • Vedtag skabelonmotorer, der automatisk undgår, eller eksplicit renser farlige felter.
• Kræv sikre headers:
  • CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, Strict-Transport-Security — hold disse håndhævet på tværs af siden.
• Overvåg og log:
  • Aggregerede logs for endpoint-adgang og cacheadfærd hjælper med at opdage anomalier tidligere.
  • Overvåg WAF/edge-begivenheder og hold reglerne under gennemgang.

---

Specifikke WordPress-anbefalinger (praktisk tjekliste)

• Hvis din side er headless:
  • Bekræft, hvilke front-end versioner og pakker der bruges; opgrader Nitro hvor nødvendigt.
  • Sørg for, at dine WordPress REST API-svar korrekt koder og renser HTML-felter.
  • Sørg for, at preview- og CI-miljøer er lige så sikre som produktion.
• Hvis din side bruger en Jamstack eller SSR-pipeline (f.eks. Netlify, Vercel, andre udbydere):
  • Kontakt din udbyder for bekræftelse af Nitro-pakkens status i deres miljøer.
  • Ryd edge-cacher efter opdateringer.
• Hvis din side er klassisk WordPress, men du er afhængig af tredjeparts plugins eller tjenester, der muligvis gengiver sider ved kanten:
  • Tjek plugin-leverandører for meddelelser og opdateringer.
  • Spørg hosting- eller platformteams om Nitro-brug i deres stack.

---

Overvågningssignaler at holde øje med i de kommende uger

• Øgede anmodninger rammer __nuxt_island med nyttelaster, der inkluderer kodede . formularer.
• Pludselig fremkomst af inline-scripts i cachet HTML, der serveres af dit CDN.
• Forhøjede WAF/edge-regel hits knyttet til ø-enderpunkter.
• Rapporteringer om popups, omdirigeringer eller uventet javascript på sider, der tidligere var statiske.

Hvis du ser disse tegn, så tag dem alvorligt: ryd cacher, anvend virtuelle patches og opdater pakker.

---

Sikre din side gratis — Start med WP-Firewall Basic

Hvis du ønsker et simpelt, effektivt udgangspunkt for at beskytte WordPress, mens du validerer og patcher upstream-komponenter, så overvej vores Basic (gratis) plan. Den giver dig essentielle beskyttelser, der reducerer eksponeringen for webapplikationstrusler, mens du implementerer de målrettede afbødninger ovenfor.

Hvad du får med Basic-abonnementet (gratis):

• Administreret firewall, der beskytter almindelige angrebsoverflader
• WAF til at blokere almindelige injektions- og XSS-mønstre
• Malware scanner til at opdage mistænkelige injicerede payloads
• Ubegribelig båndbredde og kontinuerlig scanning
• Afbødende dækning for OWASP Top 10 risici

Tilmeld dig og aktiver den gratis plan for at tilføje et beskyttende lag, mens du anvender Nuxt/Nitro-patchen og hærdningstrinene: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Eksempel: Hvordan vi ville reagere på WAF-laget (driftsmanual)

1. Triage:
   • Identificer om siden bruger sårbare Nitro-versioner.
   • Hvis ja, aktiver straks WAF-regelsættet, der målretter mod island-path XSS-mønstre.
2. Anvend virtuelle patch-regler:
   • Midlertidigt marker /__nuxt_island svar som ikke-cachebare for delte caches via kanten.
   • Tilføj indgående regler for at blokere anmodninger, der indeholder skript tokens.
3. Advarsel:
   • Underret webstedsejere og udviklere om at opdatere til 4.4.6+.
   • Planlæg et implementeringsvindue for at opdatere afhængigheder og genopbygge containere.
4. Verifikation:
   • Efter implementering af opdatering + WAF-regler, kør automatiseret test suite og simulerede XSS-prober i staging.
   • Efter beståede tests, fjern alt for restriktive WAF-regler, der kan blokere gyldig trafik og stol på den upstream løsning.
5. Obduktion:
   • Gennemgå hvorfor cache-nøgle eller Vary headers var forkert konfigureret.
   • Forbedre implementeringskontroller for at sikre, at opdateringer af afhængigheder anvendes hurtigere.

---

Ofte stillede spørgsmål (kort)

Q: Mit site er klassisk WordPress uden Node front-end - er jeg påvirket?
A: Hvis der ikke er nogen Nuxt/Nitro-komponenter i din stak, er din direkte eksponering minimal. Men tjek udviklerværktøjer, forhåndsvisningstjenester eller CDN'er, der bruges af dit site for Nitro-brug.

Q: Jeg opdaterede til 4.4.6, men ser stadig mistænkelige scripts i cachede sider - hvad nu?
A: Ryd caches på tværs af alle niveauer (kant, CDN, omvendt proxy). Opdateringen fjerner muligvis ikke tidligere cachede forgiftede aktiver automatisk.

Q: Kan Content Security Policy fuldt afbøde dette?
A: CSP reducerer virkningen af injicerede scripts, men løser ikke cache-forgiftning. Brug CSP + cache-control + patching for fuld afbødning.

Q: Hvor presserende er denne opdatering?
A: Det er vigtigt: udnyttelsen er lav-severitet på CVSS, men kan bruges til skalerbare cache-forgiftning angreb, der påvirker mange brugere. Prioriter patching, hvis du kører Nuxt/Nitro i nogen del af din leveringskæde.

---

Endelige anbefalinger — prioriteret tjekliste

1. Inventar: Søg efter Nitro/Nuxt brug på tværs af dit site, CI og hostingudbyder.
2. Patch: Opdater @nuxt/nitro-server til 4.4.6+ overalt hvor det optræder.
3. Beskyt: Anvend WAF-regler og indstil Cache-Control/Vary headers for at forhindre delt cache brug for dynamiske fragmenter.
4. Ryd: Ryd caches på CDN og edge lag.
5. Hærd: Implementer/styrk CSP, sanitér server-renderet indhold, og sørg for at cache nøgler varierer på brugerfølsomme headers.
6. Automatiser: Tilføj rutinemæssige SCA-scanninger og automatiserede afhængighedsopdateringer til din pipeline.

---

Hvis du ønsker en operations playbook skræddersyet til din WordPress hostingarkitektur (klassisk vs. headless vs. hybrid), kan vores sikkerhedsteam kortlægge trinene til din stack og give anbefalede WAF-regel snippets og test scripts, som du kan køre i staging før produktionsudrulning.