React और Next.js में रिमोट कोड एक्सीक्यूशन (RCE) की सुरक्षा कमजोरी

 (github.com/vercel)
8 पॉइंट द्वारा GN⁺ 2025-12-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • React और Next.js में रिमोट कोड एक्सीक्यूशन (RCE) संभव बनाने वाली सुरक्षा कमजोरी की रिपोर्ट की गई
  • यह समस्या Next.js package के अंदर पाई गई है, जहाँ attacker दुर्व्यवहारपूर्ण इनपुट के ज़रिये मनचाहा कोड चलाने को ट्रिगर कर सकता है
  • Vercel ने GitHub security advisory (GHSA-9qr9-h5gf-34mp) के माध्यम से इस कमजोरी का खुलासा किया और अपडेटेड संस्करण जारी किया
  • उपयोगकर्ताओं को इस कमजोरी को कम करने के लिए नवीनतम संस्करण पर अपग्रेड करना चाहिए
  • यह घटना फ्रेमवर्क स्तर पर सुरक्षा प्रबंधन के महत्व को फिर से उजागर करती है

RCE कमजोरी का अवलोकन

  • Next.js और React वातावरण में एक ऐसी कमजोरी मिली जो remote code execution की अनुमति दे सकती है
    • इससे server side पर मनमाना JavaScript code execute करने का जोखिम मौजूद है
  • यह कमजोरी Next.js package के अंदर code processing flow में मौजूद है
    • प्रभावित किसी विशेष function या module का विस्तृत विवरण सार्वजनिक नहीं किया गया है

प्रभाव और प्रतिक्रिया

  • Vercel ने GitHub security advisory (GHSA-9qr9-h5gf-34mp) के ज़रिए इस मुद्दे की आधिकारिक घोषणा की
    • यह advisory Next.js repository के security advisories सेक्शन में पोस्ट किया गया था
  • प्रभावित संस्करणों का उल्लेख नहीं दिया गया, लेकिन अद्यतन संस्करण जारी किया गया है
    • उपयोगकर्ता को latest stable version पर जल्द से जल्द अपग्रेड करने की सलाह दी गई है

सुरक्षा सलाह और कार्रवाई

  • Next.js package का उपयोग करने वाले सभी projects को तुरंत version check करना चाहिए
    • package.json में Next.js version को नवीनतम रखना जरूरी है
  • Vercel ने patched version के अतिरिक्त अन्य mitigation उपायों का कोई जिक्र नहीं किया है
  • कमजोरी की तकनीकी डिटेल पूरी तरह सार्वजनिक नहीं की गई; सुरक्षा कारणों से केवल सीमित जानकारी साझा की गई है

महत्व

  • यह कमजोरी server rendering environment में code execution risk को स्पष्ट करती है
  • React तथा Next.js आधारित सेवाओं के operators को security updates नियमित रूप से लागू करनी चाहिए
  • फ्रेमवर्क स्तर की सुरक्षा कमजोरी सीधे पूरे application security पर असर डाल सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-12-04
Hacker News की राय

  • यह भेद्यता उस सबसे खराब स्थिति के सच हो जाने का मामला है, जिसकी चेतावनी RSC/server actions लाते समय से दी जा रही थी
    सर्वर ने क्लाइंट के अविश्वसनीय input को वैसे का वैसा deserialize करके module और export नाम ढूंढकर execute किया
    hasOwnProperty patch से इसे रोका जा सकता है, लेकिन मूल समस्या यह है कि React एक RPC layer बना रहा है, इस बात को स्पष्ट रूप से नहीं पहचाना गया
    gRPC या SOAP जैसे पारंपरिक RPC framework explicit schema और service definition के जरिए boundaries साफ रखते हैं, लेकिन React का तरीका bundler को दिखने वाली हर API को expose करता है, इसलिए जोखिम भरा है
    इस तरह के design से पैदा होने वाली security समस्याएं आगे भी दोहराई जाने की संभावना है

    • यह सिर्फ लापरवाही का मामला लगता है
      explicit schema होने पर भी, अगर आखिरी चरण में अविश्वसनीय input को server namespace की किसी भी object को refer करने दिया जाए, तो उसका कोई फायदा नहीं
    • वास्तव में क्लाइंट के request करने भर से हर endpoint expose नहीं हो जाता
      सिर्फ "use server" से marked functions ही expose होते हैं, और React टीम भी इस बात से अवगत है कि वे एक RPC system डिजाइन कर रहे हैं
      ऐसे bugs दूसरे RPC systems में भी पूरी तरह हो सकते हैं (मैं React contributor हूं)
    • चेतावनी मिलने के बावजूद यह हुआ, तो आखिरकार इसे लापरवाह implementation ही कहा जा सकता है
    • आम उपयोगकर्ता के नज़रिए से सवाल यह है कि क्या इस approach का इस्तेमाल न करने पर सुरक्षित रहा जा सकता है
      लेकिन पुराना private repo बनाए रखना भी कोई अच्छा विकल्प नहीं है

  • Next का static build ही उसका एकमात्र फायदा है
    अगर उसका support बंद हो जाए तो फिर उसे इस्तेमाल करने की कोई वजह नहीं बचेगी

  • Facebook/Meta की security advisory के अनुसार, React Server Components 19.0.0~19.2.0 versions में pre-auth remote code execution (RCE) भेद्यता मौजूद है
    React के आधिकारिक ब्लॉग की घोषणा में भी बताया गया है कि क्लाइंट द्वारा server functions को call कर पाने वाली संरचना के कारण हमलावर malicious HTTP requests बनाकर सर्वर पर arbitrary code execute कर सकता है

    • अगर fix में hasOwnProperty check जोड़ना शामिल है, तो हमला शायद prototype chain की properties (__proto__ आदि) को refer करने के तरीके से हुआ होगा
    • अगर “क्लाइंट server functions को call कर सकता है” वाला वाक्य intended feature है, तो यह काफी डरावना design लगता है

  • fix commit शायद यह commit है
    लगता है कि इसे कई बदलावों के साथ squash किया गया, इसलिए details छिप गई हैं
    code में expose होने वाले functions की सूची को whitelist approach से सीमित करने वाला pattern 4 जगह दिखता है

    • या फिर यह commit कारण हो सकता है (“critical security vulnerability fix” स्पष्ट रूप से लिखा है)

  • Vercel पहले से ही platform-level protection के जरिए malicious request patterns को block कर रहा है
    घोषणा देखें
    Cloudflare ने भी WAF rule के जरिए पहले से प्रतिक्रिया दी

    • कई partners के साथ मिलकर pre-mitigation measures deploy किए गए
      फिर भी Next, React, और दूसरे meta-framework dependencies को तुरंत update करने की जोरदार सिफारिश की जाती है
    • Netlify की response announcement और
      Deno Deploy/Subhosting की blog post भी देखने लायक हैं
    • मैंने खुद patch करके rebuild किया, और किसी संभावित चूक के लिए Crowdsec WAF rule भी जोड़ दिया

  • PoC repository देखकर मैंने भेद्यता को reproduce करके देखा

    • patched react-server-dom-webpack में भी RCE चल गया, इसलिए लगता है mechanism पूरी तरह सही नहीं बैठता
      किसी असली Next.js project में demo दिखाया जाए तो अच्छा होगा
    • फिर भी इसे समेटकर समझाने वाली पोस्ट सच में प्रभावशाली थी

  • अब तो “Vercel के बिना RCE नहीं” जैसी बात कही जा रही है, और इस घटना ने hosting environment और security के संबंध को उजागर कर दिया है

  • CVE score 10.0 इस तरह के व्यापक रूप से इस्तेमाल होने वाले project के लिए चौंकाने वाला आंकड़ा है

    • प्रभावित package react-server-dom-webpack में साफ लिखा है कि यह “experimental है और जोखिम अपने ऊपर लें”
      फिर भी इसके साप्ताहिक downloads 3.1 लाख से ज्यादा हैं
    • ऐसे मामलों में CVSS 10.0 को साफ-साफ लिखना चाहिए, ताकि PR जैसे बयानों से बात दब न जाए
    • React बहुत व्यापक रूप से इस्तेमाल होता है, लेकिन React Server Components अभी उतना सामान्य नहीं है

  • यह समझना मुश्किल है कि React टीम ऐसे भ्रमित करने वाले feature पर समय क्यों खर्च कर रही है
    SSR से यह कितना बेहतर है, performance gain वास्तव में कितना है, इस पर भी सवाल है
    Hook आने के बाद developer experience खराब हुआ, और उसे बेहतर करने के बजाय एक और जटिलता जोड़ दी गई
    बेहतर होता कि JS के मूल control flow को component logic में स्वाभाविक रूप से इस्तेमाल करने दिया जाता

    • Server Components का SSR से सीधा संबंध नहीं है
      मैं इसे componentized BFF (Backend for Frontend) layer की तरह देखता हूं
      हर UI fragment अपने संबंधित backend logic से सीधे जुड़ जाता है, जिससे fetch call के बिना data लाया जा सकता है
      इससे frontend और backend को साथ-साथ विकसित करना आसान हो जाता है, और सिर्फ जरूरी data को बारीकी से load किया जा सकता है
      आखिरकार सिर्फ UI के लिए server logic को component structure के भीतर स्वाभाविक रूप से पिरोया जा सकता है
    • अफसोस इस बात का है कि React “default framework” बन गया
      Svelte या React का compiler-based model कहीं ज्यादा संभालने योग्य लगता है
    • मूल रूप से समस्या JS language की सीमाएं और प्रतिस्पर्धा की कमी है
      Vue, Svelte, Angular आदि सभी को अलग compiler और file extension चाहिए
      जबकि React/JSX को preprocessor चरण में ही विशेष लाभ मिल जाता है
      Rust ने macro system के जरिए इस तरह की समस्या हल की — उदाहरण के लिए Leptos या Yew standard .rs files के भीतर JSX या HTML template support करते हैं
      अगर JS में ऐसी extensibility नहीं आती, तो web आगे भी जटिल और अल्प-प्रभावी वातावरण बना रह सकता है
    • मुझे hooks पसंद हैं :)
    • RSC, SSR को तेज़ नहीं बना पाने के बाद निकला हुआ एक वैकल्पिक प्रयास है
      क्लाइंट-साइड load कम करने की कोशिश की गई, लेकिन वह भी असफल लगती है

  • React ब्लॉग की विस्तृत व्याख्या भी देखने लायक है