Nuxt Nitro ‘__nuxt_island’ Shared-Cache Poisoning (CVE-2026-46342) — What WordPress Site Owners Need to Know

सारांश: A recently disclosed vulnerability in the Nuxt Nitro server impacts versions ≥ 4.2.0 and ≤ 4.4.5. It can lead to shared-cache poisoning and Cross-Site Scripting (XSS) via the __nuxt_island एंडपॉइंट के माध्यम से। इस मुद्दे को 4.4.6 में पैच किया गया है। यदि आपकी वर्डप्रेस साइट जावास्क्रिप्ट फ्रंट-एंड, हेडलेस आर्किटेक्चर, CDN एज रेंडरिंग के साथ एकीकृत है, या आपके टूलचेन में Nuxt/Nitro घटकों का उपयोग करती है, तो यह सलाह जोखिम, पहचान विधियों, शमन (आपातकालीन फ़ायरवॉल/एज नियमों सहित) और दीर्घकालिक आपूर्ति श्रृंखला सख्ती रणनीतियों को समझाती है।.

यह वर्डप्रेस साइट के मालिकों के लिए क्यों महत्वपूर्ण है

अधिकांश वर्डप्रेस तैनाती PHP-आधारित रहती हैं, जो वर्डप्रेस स्टैक से सर्वर-साइड रेंडरिंग करती हैं। हालाँकि, हांगकांग और क्षेत्र में ऑपरेटर प्रदर्शन और बेहतर डेवलपर वर्कफ़्लोज़ के लिए आधुनिक जावास्क्रिप्ट फ्रंट-एंड (Nuxt, Next, Remix) का उपयोग कर रहे हैं — एक हेडलेस या डिकपल्ड आर्किटेक्चर। ये फ्रंट-एंड सामान्यतः नोड-आधारित सर्वरों, नाइट्रो मिडलवेयर, और एज कैश/CDNs पर निर्भर करते हैं।.

रिपोर्ट किया गया मुद्दा (CVE-2026-46342) एक नाइट्रो सर्वर एंडपॉइंट को प्रभावित करता है जिसका उपयोग Nuxt फ्रंट-एंड द्वारा किया जाता है: __nuxt_island. जब प्रतिक्रियाएँ उत्पत्ति अनुरोध गुणों से कसकर बंधी नहीं होती हैं, तो एक साझा कैश एक उपयोगकर्ता के लिए बनाई गई प्रतिक्रिया को दूसरे को सेवा दे सकता है। यदि उस प्रतिक्रिया में हमलावर द्वारा नियंत्रित सामग्री (उदाहरण के लिए, अस्वच्छ HTML या स्क्रिप्ट अंश) शामिल है, तो एक हमलावर कैश को विषाक्त कर सकता है और कई साइट आगंतुकों के लिए क्रॉस-साइट स्क्रिप्टिंग को ट्रिगर कर सकता है।.

भले ही आपकी वर्डप्रेस बैकएंड सीधे नोड पर न चल रही हो, वर्डप्रेस सिस्टम प्रभावित हो सकते हैं जब:

• आपकी वर्डप्रेस साइट एक Nuxt या Nitro फ्रंट-एंड का उपयोग करती है जो वर्डप्रेस REST API या GraphQL से डेटा खींचती है।.
• आपका होस्टिंग वातावरण सर्वर-साइड रेंडरिंग या एज-रेंडरिंग सेवाओं का उपयोग करता है जिसमें नाइट्रो-आधारित घटक शामिल हैं।.
• आपका CI/CD, निर्माण पाइपलाइन, या तृतीय-पक्ष सेवाएँ कमजोर पैकेज का उपयोग करती हैं ताकि पूर्वावलोकन उत्पन्न कर सकें, फ्रंट-एंड तैनात कर सकें, या एज पर पृष्ठों को रेंडर कर सकें।.

यह सलाह एक व्यावहारिक दृष्टिकोण अपनाती है जिसमें हांगकांग सुरक्षा विशेषज्ञ की आवाज़ होती है: सीधी, परिचालनात्मक, और इस पर केंद्रित कि साइट मालिकों और ऑपरेटरों को अब क्या करना चाहिए।.

Technical overview — what’s broken

• द __nuxt_island एंडपॉइंट Nuxt के हाइब्रिड रेंडरिंग मॉडल में द्वीपित घटकों (छोटे इंटरैक्टिव अंश) को रेंडर या हाइड्रेट करता है।.
• कमजोर व्यवहार: एंडपॉइंट से प्रतिक्रियाएँ अनुरोध गुणों (उत्पत्ति, हेडर, कुकीज़, क्वेरी पैरामीटर) से पर्याप्त रूप से बंधी नहीं होती हैं। यदि एक कैशिंग परत उस प्रतिक्रिया को उचित Vary/Cache-Control हेडर या कैश कुंजी के बिना संग्रहीत करती है, तो कैश की गई प्रतिक्रिया अन्य अनुरोधों को सेवा दी जा सकती है जो महत्वपूर्ण अनुरोध गुणों में भिन्न होती हैं।.
• यदि एक हमलावर एक अनुरोध तैयार कर सकता है जिसमें हमलावर द्वारा नियंत्रित सामग्री (जैसे, इंजेक्टेड गुणों या परावर्तित डेटा के माध्यम से) शामिल है और उस प्रतिक्रिया को कैश करने का कारण बनता है, तो हमलावर साझा कैश को विषाक्त कर सकता है। जब अन्य उपयोगकर्ता उस कैश की गई प्रतिक्रिया को प्राप्त करते हैं, तो कोई भी दुर्भावनापूर्ण स्क्रिप्ट उनके ब्राउज़रों में निष्पादित होगी — जिसके परिणामस्वरूप संभावित रूप से व्यापक प्रभाव पड़ेगा।.

अंतिम परिणाम: एक सफल शोषण एक विषाक्त कैश किए गए द्वीप अंश के माध्यम से सामूहिक XSS में बदल सकता है।.

वर्डप्रेस साइटों के लिए हमले की सतह

सामान्य एकीकरण पैटर्न जो वर्डप्रेस-संचालित साइटों को इस मुद्दे के लिए उजागर करते हैं:

• हेडलेस वर्डप्रेस + नक्स्ट फ्रंट-एंड:
  • वर्डप्रेस सामग्री को REST API / GraphQL के माध्यम से प्रदान करता है।.
  • नक्स्ट फ्रंट-एंड नाइट्रो का उपयोग करके उन द्वीपों को सर्वर-रेंडर करता है जो WP से सामग्री शामिल करते हैं।.
  • फ्रंट-एंड प्रक्रिया में उपयोग किया गया कमजोर नाइट्रो पैकेज कैश पॉइज़निंग का कारण बन सकता है।.
• एज रेंडरिंग / CDN पूर्वावलोकन / OG छवि निर्माण:
  • कुछ एज पूर्वावलोकन जनरेटर या छवि एंडपॉइंट नाइट्रो-आधारित रेंडरिंग शामिल करते हैं।.
  • यदि आपका होस्टिंग प्रदाता या CI नाइट्रो घटकों का उपयोग करता है, तो उन एंडपॉइंट्स पर प्रभाव पड़ सकता है।.
• डेवलपर उपकरण:
  • निर्माण और पूर्वावलोकन प्रणाली (स्टोरीबुक, SSR पूर्वावलोकन, स्थिर साइट जनरेटर) जो कमजोर निर्भरता को स्थापित करती हैं, विषाक्त कलाकृतियों या कैश आउटपुट को बना या अपलोड कर सकती हैं।.
• तृतीय-पक्ष एकीकरण:
  • प्लगइन विक्रेता, थीम बिल्डर, या हेडलेस-सेवा प्रदाता नाइट्रो-आधारित पूर्वावलोकन चला सकते हैं। यदि वे कमजोर संस्करणों का उपयोग कर रहे हैं, तो ग्राहकों की साइटों पर अप्रत्यक्ष रूप से प्रभाव पड़ सकता है।.

If your WordPress site is purely classic (no headless front-end, no Node tooling in deployments), the risk is much lower. But in modern DevOps environments it’s worth checking.

हमलावर इसे कैसे भुनाते हैं (व्यावहारिक परिदृश्य)

• कैश किए गए द्वीप खंड के माध्यम से परावर्तित XSS:
  • हमलावर एक तैयार अनुरोध भेजता है __nuxt_island हमलावर-नियंत्रित पैरामीटर के साथ।.
  • नाइट्रो उचित सफाई के बिना पैरामीटर वाला एक खंड उत्पन्न करता है।.
  • CDN साझा कुंजी के लिए खंड को कैश करता है।.
  • बाद के आगंतुक कैश किए गए खंड को प्राप्त करते हैं; हमलावर का जावास्क्रिप्ट उनके ब्राउज़रों में चलता है।.
• अपस्ट्रीम डेटा के माध्यम से स्टोर-लाइक पॉइज़निंग:
  • यदि फ्रंट-एंड तीसरे पक्ष के API या उपयोगकर्ता इनपुट (जैसे, टिप्पणियाँ) से डेटा रेंडर करता है, तो एक हमलावर अपस्ट्रीम में दुर्भावनापूर्ण इनपुट संग्रहीत करता है।.
  • सर्वर द्वीप को दुर्भावनापूर्ण सामग्री के साथ प्रस्तुत करता है; प्रतिक्रिया कैश की जाती है और बाद में दूसरों को प्रदान की जाती है।.
• बड़े पैमाने पर दुरुपयोग: एज कैश का मतलब है कि एकल कैश किया गया ऑब्जेक्ट हजारों आगंतुकों को प्रभावित कर सकता है; कैश-ज़हरिंग मार्ग प्रभाव को बढ़ाते हैं।.

पैच और अपडेट - सबसे महत्वपूर्ण सुधार

यदि आप अपने स्टैक में कहीं भी Nuxt/Nitro का उपयोग करते हैं, तो प्रभावित पैकेज को तुरंत अपडेट करें:

• प्रभावित: @nuxt/nitro-server ≥ 4.2.0 and ≤ 4.4.5
• पैच किया गया: 4.4.6 - 4.4.6 या बाद में अपग्रेड करें

क्रियाएँ:

1. उन परियोजनाओं के लिए जो npm/yarn/pnpm का उपयोग करती हैं:
   • चलाएँ npm install @nuxt/nitro-server@^4.4.6 (या अपडेट करें पैकेज.json और अपने पैकेज प्रबंधक को चलाएँ)।.
   • लॉकफाइल्स को अपडेट करें (पैकेज-लॉक.json, यार्न.lock, pnpm-lock.yaml) और उन्हें कमिट करें।.
2. कंटेनराइज्ड बिल्ड के लिए:
   • पैकेज और लॉकफाइल को अपडेट करने के बाद इमेज को फिर से बनाएं और फिर से तैनात करें।.
   • निहित नवीनतम संस्करणों पर निर्भर रहने से बचें - पिन किए गए संस्करणों का उपयोग करें और इमेज को बार-बार पुनर्निर्माण करें।.
3. उन एज या पूर्वावलोकन सेवाओं के लिए जिन्हें आप नियंत्रित नहीं करते:
   • अपने प्रदाता या सेवा मालिक से संपर्क करें और पैचिंग की पुष्टि करने का अनुरोध करें।.
   • उनसे 4.4.6+ में अपडेट करने और पैचिंग के बाद कैश को अमान्य करने के लिए कहें।.

यदि आप तुरंत अपडेट नहीं कर सकते हैं, तो नीचे दिए गए शमन उपायों को लागू करें।.

तत्काल उपाय जो आप अभी लागू कर सकते हैं (यहां तक कि पैचिंग से पहले भी)

व्यावहारिक उपाय जो आप जल्दी लागू कर सकते हैं ताकि जोखिम कम हो:

1. द्वीप एंडपॉइंट के लिए साझा कैशिंग को निष्क्रिय करें
   • सुनिश्चित करें कि प्रतिक्रियाएँ __nuxt_island साझा कैश द्वारा कैश करने योग्य नहीं के रूप में चिह्नित हैं:
     • सेट कैश-नियंत्रण: निजी, नो-कैश, नो-स्टोर, पुनः-सत्यापित करना आवश्यक है (अपने वातावरण के लिए उपयुक्त निर्देश चुनें)।.
     • जोड़ें भिन्नता यदि प्रतिक्रियाएँ उन पर निर्भर करती हैं तो कुकीज़/प्राधिकरण/होस्ट शामिल करने के लिए हेडर: भिन्नता: कुकी, प्राधिकरण, स्वीकार-कोडिंग, होस्ट.
   • यदि आप CDN नियमों को नियंत्रित करते हैं, तो किसी भी पथ के लिए कैश को बायपास करने के लिए एक नियम बनाएं जो मेल खाता है /__nuxt_island या समान।.
2. WAF / एज नियमों के साथ आभासी पैचिंग
   • अनुरोधों को अवरुद्ध या चुनौती देने के लिए फ़ायरवॉल नियम बनाएं /__nuxt_island जो संदिग्ध पेलोड्स को शामिल करते हैं:
     • उन अनुरोधों को ब्लॉक करें जिनमें 9. या विशेषताओं जैसे onload=, त्रुटि होने पर=, 11. साइट मालिकों के लिए तात्कालिक कदम, encoded script tokens (%3Cscript), or obvious XSS patterns in query strings.
     • Rate-limit or CAPTCHA-challenge anomalous requests to that path.
   • उदाहरण ModSecurity-शैली के नियम (वैचारिक):

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

   Adapt IDs and severity to your environment. Test before production-blocking.

3. Purge caches
   • If poisoning may have occurred (or as precaution), purge caches at all tiers:
     • CDN edge caches
     • Reverse proxy caches (Varnish)
     • Application caches
   • Use cache-busting headers or versioning for island fragments if necessary.
4. Add Content Security Policy (CSP)
   • Implement or tighten CSP for pages that include island fragments:
     • उदाहरण: सामग्री-सुरक्षा-नीति: डिफ़ॉल्ट-स्रोत 'स्वयं'; स्क्रिप्ट-स्रोत 'स्वयं' 'नॉन्स-...'; ऑब्जेक्ट-स्रोत 'कोई नहीं'; आधार-यूआरआई 'स्वयं';
   • A strict CSP can limit the impact of XSS even if an attacker injects a script tag.
5. Increase response validation/sanitization
   • On the server side (Nuxt or downstream services), ensure any data bound into responses is properly escaped or sanitized before inclusion in server-rendered HTML.
6. लॉग और ट्रैफ़िक की निगरानी करें
   • Look for sudden increases in requests to __nuxt_island.
   • Inspect for recurring patterns in query strings or POST bodies that include script tokens.
   • Monitor edge cache hit patterns and cache keys.

WAF and edge rule suggestions (concrete)

Below are practical rules and snippets you can adapt. They are intentionally generic and should be tested in staging first.

Nginx snippet to set cache headers for island endpoint:

location ~* /__nuxt_island {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    add_header Cache-Control "private, no-cache, no-store, must-revalidate";
    add_header Vary "Cookie, Authorization, Accept-Encoding, Host";
}

ModSecurity वैचारिक नियम:

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

Response-hardening via edge worker (pseudo-code):

• Intercept responses for /__nuxt_island.
• यदि प्रतिक्रिया में शामिल है 9. या विशेषताओं जैसे onload= or suspicious inline JS AND the request lacks expected authentication or headers, drop/challenge response and do not cache.
• Otherwise, ensure response has Cache-Control: private.

Cache key hardening: Ensure cache keys include user-specific properties where content varies (Cookie, Authorization header, Accept-Language, etc.). A misconfigured cache key that ignores cookies is a major root cause of poisoning.

दर सीमित करना: Apply rate limits on requests to __nuxt_island, e.g., 5 requests per minute per IP, to reduce poisoning feasibility.

Note: WAF rules are blunt instruments — take incremental steps in staging and monitor for false positives to avoid breaking legitimate traffic.

Detection: how to know if you are affected

1. Inventory your stack
   • Search your codebase, CI/CD configurations, and build logs for references to @nuxt/nitro-server, नक्स्ट, nitro, और __nuxt_island.
   • उपयोग करें npm ls @nuxt/nitro-server or equivalent to list installed versions.
   • Check lockfiles (पैकेज-लॉक.json, यार्न.lock, pnpm-lock.yaml) to find transient dependencies.
2. Inspect server and CDN logs
   • Look for traffic to paths like /__nuxt_island (or similar island/hydration endpoints).
   • Look for requests with suspicious query strings containing script, त्रुटि पर, or encoded variants (%3C, <).
3. Review cached responses
   • Fetch cached edge HTML for pages and inspect for injected <script> tags or inline event handlers that you did not author.
   • If your CDN supports cache inspection, verify cached objects for unusual content.
4. स्वचालित स्कैनिंग
   • Run dependency scanners (npm audit, SCA tools) to locate vulnerable package versions.
   • Use web scanners (XSS detectors) to probe render endpoints safely in staging.

If you think you’ve been hit — immediate incident steps

1. Take the vulnerable endpoint out of public caching
   • Temporarily set Cache-Control: no-store on island endpoints.
   • Purge caches across CDN and proxies.
2. Rebuild & patch
   • अपडेट @nuxt/nitro-server to 4.4.6+.
   • Rebuild containers and redeploy.
3. कंटेन करें और जांचें
   • Isolate suspicious servers or processes.
   • Dump logs for the time window of suspected poisoning.
   • Identify and list affected cache keys and purge them.
4. साफ करें और मजबूत करें
   • Remove or sanitize any malicious payloads persisted in upstream data sources.
   • Rotate secrets that may have been exposed.
   • Reassess CSP and input sanitization.
5. संवाद करें
   • If user data was at risk or exploit went public, follow your incident disclosure policy and notify stakeholders.

Long-term supply-chain and deployment hardening for WordPress owners

• Maintain a dependency inventory: Track Node and PHP dependencies used by your site and CI pipeline. Periodically run SCA scans across all packages.
• निर्भरताओं को पिन और लॉक करें: Use exact version pins in पैकेज.json for production-critical packages. Commit lockfiles and run regular rebuilds.
• Automate updates: Use automated tools to propose updates; test and deploy regularly. Consider pipelines that rebuild images and run integration tests when patches are released.
• Limit caching surface: Only enable aggressive shared caching for truly static assets. For dynamic fragments or user-personalized fragments, use Cache-Control: private or bypass caching.
• Harden front-end rendering: Ensure server-rendered fragments escape user data by default. Adopt template engines that auto-escape, or explicitly sanitize dangerous fields.
• Require secure headers: CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options, Strict-Transport-Security — enforce these across the site.
• निगरानी और लॉगिंग करें: Aggregated logs for endpoint access and cache behavior help detect anomalies sooner. Monitor WAF/edge events and keep rules under review.

Specific WordPress recommendations (practical checklist)

• If your site is headless:
  • Confirm which front-end versions and packages are used; upgrade Nitro where necessary.
  • Ensure your WordPress REST API responses encode and sanitize HTML fields properly.
  • Ensure preview and CI environments are as secured as production.
• If your site uses a Jamstack or SSR pipeline (Netlify, Vercel, other providers):
  • Contact your provider for confirmation of Nitro package status in their environments.
  • Purge edge caches after updates.
• If your site is classic WordPress but relies on third-party plugins or services that might render at the edge:
  • Check plugin vendors for notifications and updates.
  • Ask hosting or platform teams about Nitro usage in their stack.

Monitoring signals to watch for in the coming weeks

• Increased requests hitting __nuxt_island with payloads that include encoded 9. या विशेषताओं जैसे onload= forms.
• Sudden appearance of inline scripts in cached HTML served by your CDN.
• Elevated WAF/edge rule hits tied to island endpoints.
• Reports of popups, redirects, or unexpected JavaScript on pages that were previously static.

If you see these signs, treat them seriously: purge caches, apply virtual patches, and update packages.

अक्सर पूछे जाने वाले प्रश्न (संक्षिप्त)

प्रश्न: My site is classic WordPress with no Node front-end — am I affected?
उत्तर: If no Nuxt/Nitro components are in your stack, direct exposure is minimal. But check developer tools, preview services, or CDNs used by your site for Nitro usage.

प्रश्न: I updated to 4.4.6 but still see suspicious scripts in cached pages — what next?
उत्तर: Purge caches across all tiers (edge, CDN, reverse proxy). An update may not remove previously cached poisoned assets automatically.

प्रश्न: Can Content Security Policy fully mitigate this?
उत्तर: CSP reduces the impact of injected scripts but doesn’t solve cache poisoning. Use CSP + cache-control + patching for full mitigation.

प्रश्न: How urgent is this update?
उत्तर: Prioritise patching if you run Nuxt/Nitro in any part of your delivery chain. The CVE is low-severity by CVSS but enables scalable cache-poisoning attacks that can affect many users.

अंतिम सिफारिशें - प्राथमिकता दी गई चेकलिस्ट

1. Inventory: Search for Nitro/Nuxt usage across your site, CI, and hosting provider.
2. Patch: Update @nuxt/nitro-server to 4.4.6+ everywhere it appears.
3. Protect: Apply WAF rules and set appropriate कैश-नियंत्रण 8. और भिन्नता headers to prevent shared cache usage for dynamic fragments.
4. Purge: Clear caches at CDN and edge layers.
5. Harden: Implement/strengthen CSP, sanitize server-rendered content, and ensure cache keys vary on user-sensitive headers.
6. Automate: Add routine SCA scans and automated dependency updates to your pipeline.

If you would like an operations playbook tailored to your WordPress hosting architecture (classic vs. headless vs. hybrid), I can provide one that maps the steps to your stack and includes WAF rule snippets and testing scripts you can run in staging before production rollout. Reply with details of your architecture and I will prepare a practical playbook.