Wवर्डप्रेस भेद्यता डेटाबेस

हांगकांग सुरक्षा सूचना XSS Nuxt Nitro(CVE202646342)

Npm @nuxt/nitro-server Npm में क्रॉस साइट स्क्रिप्टिंग (XSS)
0
शेयर
0
0
0
0






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


प्लगइन का नाम @nuxt/nitro-server
कमजोरियों का प्रकार क्रॉस-साइट स्क्रिप्टिंग (XSS)
CVE संख्या CVE-2026-46342
तात्कालिकता कम
CVE प्रकाशन तिथि 2026-05-20
स्रोत URL CVE-2026-46342

Nuxt Nitro ‘__nuxt_island’ साझा-कैश विषाक्तता (CVE-2026-46342) — वर्डप्रेस साइट मालिकों को क्या जानना चाहिए

लेखक: हांगकांग सुरक्षा विशेषज्ञ — दिनांक: 2026-05-20 — टैग: सुरक्षा, वर्डप्रेस, WAF, Nuxt, हेडलेस, CVE-2026-46342

सारांश: हाल ही में प्रकट हुई एक कमजोरियों ने Nuxt Nitro सर्वर को प्रभावित किया है, जो संस्करण ≥ 4.2.0 और ≤ 4.4.5 पर लागू होती है। यह साझा-कैश विषाक्तता और क्रॉस-साइट स्क्रिप्टिंग (XSS) का कारण बन सकती है __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, निर्माण पाइपलाइन, या तृतीय-पक्ष सेवाएँ कमजोर पैकेज का उपयोग करती हैं ताकि पूर्वावलोकन उत्पन्न कर सकें, फ्रंट-एंड तैनात कर सकें, या एज पर पृष्ठों को रेंडर कर सकें।.

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

तकनीकी अवलोकन — क्या टूटा है

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

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

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

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

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

यदि आपकी वर्डप्रेस साइट पूरी तरह से क्लासिक है (कोई हेडलेस फ्रंट-एंड नहीं, तैनाती में कोई नोड उपकरण नहीं), तो जोखिम बहुत कम है। लेकिन आधुनिक देवऑप्स वातावरण में इसे जांचना उचित है।.

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

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

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

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

  • प्रभावित: @nuxt/nitro-server ≥ 4.2.0 और ≤ 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 जो संदिग्ध पेलोड्स को शामिल करते हैं:
      • उन अनुरोधों को ब्लॉक करें जिनमें , onerror=, onload=, encoded script tokens (%3Cscript), or obvious XSS patterns in query strings.
      • Rate-limit or CAPTCHA-challenge anomalous requests to that path.
    • Example ModSecurity-style rules (conceptual):
    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)(

    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:
      • Example: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none'; base-uri 'self';
    • 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. Monitor logs and traffic
    • 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 conceptual rule:

# 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)(

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

  • Intercept responses for /__nuxt_island.
  • If response contains 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.

Rate limiting: 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, nuxt, nitro, and __nuxt_island.
    • Use npm ls @nuxt/nitro-server or equivalent to list installed versions.
    • Check lockfiles (package-lock.json, yarn.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, onerror, or encoded variants (%3C, <).
  3. Review cached responses
    • Fetch cached edge HTML for pages and inspect for injected