React Server Components में DoS और स्रोत कोड एक्सपोज़र कमजोरियों का खुलासा

• React Server Components में Denial of Service (DoS) और स्रोत कोड एक्सपोज़र की नई कमजोरियाँ खोजकर सार्वजनिक की गईं
• इस बार इन कमजोरियों में Remote Code Execution (RCE) संभव नहीं है, लेकिन सर्वर बंद होने या कोड लीकेज का जोखिम मौजूद है
• प्रभावित पैकेज react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack के 19.0.0~19.2.2 संस्करण हैं; फिक्स्ड वर्ज़न 19.0.3, 19.1.4, 19.2.3 हैं
• DoS कमजोरी (CVE-2025-55184, CVE-2025-67779) में मालिशियस HTTP request के कारण सर्वर में infinite loop हो सकता है, जबकि स्रोत कोड एक्सपोज़र कमजोरी (CVE-2025-55183) से server function का कुछ code वापस आ सकता है
• React टीम ने तुरंत अपग्रेड करने की सलाह दी है और इस अतिरिक्त खुलासे को security response cycle का normal part बताया है

---

नई सार्वजनिक कमजोरियों का अवलोकन

• सुरक्षा शोधकर्ताओं ने पिछले हफ्ते सार्वजनिक किए गए क्रिटिकल vulnerability पैच के सत्यापन के दौरान दो अतिरिक्त कमजोरियाँ खोजीं
• नई कमजोरियों में Remote Code Execution (RCE) संभव नहीं है, और पहले वाला React2Shell patch अभी भी valid है
• नई सार्वजनिक कमजोरियाँ इस प्रकार हैं
  • DoS — CVE-2025-55184, CVE-2025-67779 (CVSS 7.5, उच्च गंभीरता)
  • स्रोत कोड एक्सपोज़र — CVE-2025-55183 (CVSS 5.3, मध्यम गंभीरता)
• React टीम ने तुरंत अपग्रेड की सलाह दी है

पहले के पैच की अपूर्णता

• पिछले हफ्ते रिलीज़ हुए 19.0.2, 19.1.3, 19.2.2 के पैच पूर्ण नहीं थे, इसलिए फिर से अपडेट की आवश्यकता है
• पूर्ण फिक्स 19.0.3, 19.1.4, 19.2.3 संस्करणों में शामिल हैं
• पहले के पोस्ट की अपडेट गाइडलाइंस का पालन करें
• पूर्ण फिक्स रोलआउट के बाद अतिरिक्त विवरण बाद में जारी किए जाएँगे

प्रभावित पैकेज और संस्करण

• यह कमजोरी उसी पैकेज और संस्करणों में मौजूद है जिनमें पहले का CVE-2025-55182 पाया गया था
• प्रभावित संस्करण: 19.0.0~19.2.2
• प्रभावित पैकेज:
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• फिक्स संस्करण: 19.0.3, 19.1.4, 19.2.3
• जो app server का उपयोग नहीं करते या React Server Components support नहीं करते, वे प्रभावित नहीं होंगे

अतिरिक्त vulnerabilities सार्वजनिक होने का सामान्य पैटर्न

• क्रिटिकल CVE सार्वजनिक होने के बाद संबंधित code paths की अतिरिक्त जाँच के दौरान अक्सर और कमजोरियाँ मिलती हैं
• उदाहरण के तौर पर Log4Shell के बाद और CVE रिपोर्ट होने के केसों का उल्लेख किया गया है
• ऐसे अतिरिक्त खुलासे दिखाते हैं कि security response ठीक तरह से काम कर रही है

प्रभावित frameworks और bundlers

• नीचे दिए गए frameworks/bundlers उन vulnerable React पैकेजों को include या depend करते हैं
  • next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, rwsdk
• पहले के पोस्ट की अपडेट गाइडलाइंस का पालन करें

होस्टिंग providers द्वारा mitigation

• कई होस्टिंग providers के साथ मिलकर temporary mitigations लागू किए गए
• फिर भी केवल उन्हीं पर भरोसा न करें; तुरंत अपडेट ज़रूरी है

React Native संबंधित निर्देश

• React Native अकेले उपयोग करने वाले डेवलपर्स के लिए अतिरिक्त कार्रवाई की जरूरत नहीं है
• Monorepo setup में केवल ये पैकेज अपडेट करने होंगे
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• react और react-dom को अपडेट करने की जरूरत नहीं है
• संबंधित details के लिए React Native GitHub issue देखें

उच्च गंभीरता: DoS

• CVE-2025-55184, CVE-2025-67779, CVSS 7.5
• अगर malicious HTTP request को React server function endpoint पर भेजा जाए, तो deserialization के दौरान infinite loop ट्रिगर हो सकता है
• server process crash हो सकता है और CPU का heavy usage हो सकता है
• सीधे server function endpoint implement न भी किया हो, तो भी अगर app React Server Components support करता हो तो वह vulnerable हो सकता है
• आज जारी हुए patch ने infinite loop रोककर समस्या हल की
• शुरुआत का fix अधूरा था, जिसे अतिरिक्त weakness (CVE-2025-67779) के साथ complete किया गया

मध्यम गंभीरता: स्रोत कोड एक्सपोज़र

• CVE-2025-55183, CVSS 5.3
• malicious HTTP request से server function का स्रोत कोड का कुछ हिस्सा return हो सकता है
• यह तभी संभव होता है जब server function का string argument explicit या implicit तरीके से exposed हो
• उदाहरण में database connection keys जैसी hard-coded secret values लीक हो सकती हैं
• patch ने server function source code को stringified होने से रोककर समस्या ठीक की
• एक्सपोज़र सिर्फ server function के अंदर के code तक सीमित है, जबकि runtime secrets (process.env.SECRET आदि) प्रभावित नहीं होते
• इसे production bundle के आधार पर validate करना ज़रूरी है

टाइंलाइन

• 3 दिसंबर: Andrew MacPherson ने Vercel और Meta Bug Bounty पर source code exposure रिपोर्ट किया
• 4 दिसंबर: RyotaK ने DoS weakness रिपोर्ट की
• 6 दिसंबर: React टीम ने दोनों मुद्दों की पुष्टि की और investigation शुरू की
• 7 दिसंबर: प्रारंभिक फिक्स लिखा गया और validation प्लान बनाया गया
• 8 दिसंबर: होस्टिंग providers और open source प्रोजेक्ट्स को notify किया गया
• 10 दिसंबर: mitigation लागू और patch validation complete हुआ
• 11 दिसंबर: Shinsaku Nomura ने अतिरिक्त DoS रिपोर्ट की, और CVE-2025-55183, 55184, 67779 सार्वजनिक किए

रिपोर्ट करने वाले

• Andrew MacPherson (AndrewMohawk) — स्रोत कोड एक्सपोज़र रिपोर्ट की
• RyotaK (GMO Flatt Security Inc) और Shinsaku Nomura (Bitforest Co., Ltd.) — DoS कमजोरियों की रिपोर्ट की

[GN⁺]

Hacker News की राय

• React Server Components(RSC) हमेशा असहज लगे हैं
  क्योंकि सिर्फ JavaScript code देखकर क्लाइंट पर चलने वाले हिस्से और सर्वर पर चलने वाले हिस्से में फर्क करना मुश्किल होता है
  इसके अलावा इसे लागू करने के लिए गहरे serialization RPC mechanism की ज़रूरत होती है, जो डेवलपर्स के लिए अपारदर्शी है और security vulnerability का जोखिम बढ़ाता है

  • पहले के NextJS pages router दौर में server और client code की सीमा साफ़ थी, जो अच्छा लगता था
    लेकिन app router पर बदलने के बाद भ्रम पैदा हुआ। code दोनों तरफ चल सकता था, इसलिए Headers जैसी objects हमेशा मौजूद नहीं होती थीं और क्या कहाँ चल रहा है यह समझना मुश्किल था
  • एक नई टीम में शामिल होने के बाद जब देखा कि वे Next इस्तेमाल कर रहे हैं, तो मैंने पूछा, “क्या किसी को पता है कि यह कैसे काम करता है?” और कोई भी इसे साफ़ तौर पर समझा नहीं पाया
    React+Next जब ठीक से काम करता है तो जादू जैसा लगता है, लेकिन टीम स्तर पर काम करते समय predictability का लगातार कम होना समस्या है
  • इसलिए मैं Inertia.js का प्रशंसक हूँ। Inertia.js Laravel, Rails, Django जैसे पारंपरिक MVC backend और React, Vue, Svelte जैसे frontend tools को स्वाभाविक रूप से जोड़ता है
    भूमिकाएँ स्पष्ट रहती हैं, काम सरल होता है, और मुझे लगता है कि ज़्यादातर projects में यह सबसे सुरक्षित विकल्प है
  • लगता है RSC और SSR को ज़रूरत से ज़्यादा अपनाया गया है
    landing page या marketing page के लिए SSR उपयोगी है, लेकिन सामान्य SaaS dashboard जैसे apps में इसकी complexity के मुकाबले फ़ायदा लगभग नहीं के बराबर है
  • जिज्ञासा है कि दूसरे frameworks (Angular, SvelteKit, Nuxt) ऐसी vulnerabilities के प्रति कितने exposed हैं
    क्या React सिर्फ़ ज़्यादा लोकप्रिय होने के कारण ज़्यादा ध्यान खींचता है, या संरचनात्मक रूप से ज़्यादा जोखिमभरा है?

• पिछले हफ़्ते मैंने RSC को देखा, और इसकी complexity बहुत ज़्यादा थी, जबकि documentation लगभग नहीं के बराबर था
  React इसे अभी भी experimental feature कहता है, लेकिन NextJS ने इसे पहले ही व्यापक रूप से deploy कर दिया है
  आगे और security issues आने की संभावना लगती है, और Next का build system इतना जटिल है कि debug करना भी मुश्किल था
  मिलने वाले लाभ की तुलना में इसकी लागत बहुत बड़ी है

  • पहले से यह शिकायत रही है कि Next “ऐसे React features जो अभी production-ready नहीं हैं” उन्हें भी नवीनतम features की तरह पेश करता है
    इसी वजह से मैंने भी Next छोड़ दिया। cognitive load बहुत ज़्यादा था और बदले में बहुत कम मिला
  • React में लंबे समय से documentation की कमी की समस्या रही है
    सिर्फ़ RSC ही नहीं, कुल मिलाकर भी स्पष्ट guides देर से आए, और CRA जैसे tools को भी आधिकारिक मान्यता नहीं मिली
    अब जाकर useEffect documentation बेहतर हुई है, लेकिन बहुत देर हो चुकी है
    2025 आ जाने के बाद भी इसे काम में इस्तेमाल कर रहा हूँ, फिर भी स्पष्ट documentation की कमी बनी हुई है

• SPA का मूल विचार यह था कि “पूरा app क्लाइंट को भेजो और server के साथ सिर्फ़ data का आदान-प्रदान करो”

  • लेकिन अब C# ecosystem में Blazor Server लोकप्रिय है
    पुराने .aspx Web Forms की तरह हर click और input server को भेजा जाता है, और बदला हुआ DOM फिर वापस आता है
    यानी व्यवहार में हम पुराने तरीक़े पर लौट आए हैं, जो थोड़ा अजीब लगता है
  • आख़िरकार कई डेवलपर्स ने फिर से server-side rendering की वजह को समझा और PHP, Rails, Spring जैसे full-stack frameworks की ओर लौटे
  • लेकिन आजकल React जैसी libraries से static sites बनाना आम हो गया है, जो साधारण template engine + JS संयोजन से धीमा और ज़्यादा जटिल है
    यह खलता है कि “काम के हिसाब से सही tool चुनने की समझ” कम होती जा रही है
  • बेशक RSC शुद्ध SPA के लिए नहीं है। यह अलग उद्देश्य वाला approach है

• इस security notice में सबसे ज़्यादा ध्यान खींचने वाली पंक्ति यह थी: “जब कोई गंभीर CVE मिलता है, तो उसके बाद अक्सर और vulnerabilities सामने आती हैं”
  दायरा, असर, या mitigation समझाने से पहले ही जैसे CVE को जायज़ ठहराने की कोशिश की जा रही हो, इसलिए असहज लगा

  • लेकिन कुछ लोगों का मानना है कि “वह सफ़ाई नहीं, बल्कि बस उस हिस्से की व्याख्या है जिसे लोग सबसे पहले जानना चाहते हैं”
  • कहा गया कि feedback को ध्यान में रखकर wording बदल दी गई → संशोधित PR लिंक
  • किसी ने इसे perception management कहा
    संबंधित wiki document
  • कुछ लोगों के मुताबिक इस मामले में career संबंधी हित भी जुड़े हुए हैं
  • किसी ने कहा, “यह Vercel marketing team द्वारा लिखा गया पोस्ट लगता है”

• 15 साल पहले Opa में भी ऐसा ही प्रयास किया गया था
  client और server code को अपने-आप अलग करना और JSX जैसी syntax लाना इसका हिस्सा था
  लेकिन security analysis को मज़बूत करते-करते compiler बहुत विशाल हो गया, और अंततः यह समझ आया कि एकल app की अवधारणा से ज़्यादा स्पष्ट separation महत्वपूर्ण है
  कभी न कभी LLM ऐसे code को अपने-आप generate कर सकते हैं, लेकिन अभी के लिए सरल संरचना बेहतर लगती है

  • वास्तव में RSC की vulnerability का कारण code splitting से ज़्यादा serialization/deserialization process की dynamic प्रकृति है
    JS के prototype pollution, function toString, Promise override जैसी समस्याओं को रोकने के लिए patch पर काम चल रहा है
    RSC import "server-only" या import "client-only" जैसी static verification से environment अलग करता है, इसलिए संरचनात्मक रूप से यह काफ़ी सुरक्षित approach है
  • इसी तरह के विचार वाला Electric Clojure नाम का एक project भी है → लिंक
  • जानकारी के लिए, Ocsigen Eliom ने Opa से भी पहले इस तरह की अवधारणा आज़माई थी

• React तब अच्छा था जब वह मूल रूप से MVC के View की भूमिका में छोटा और सरल था
  अब उसमें बहुत ज़्यादा features आ गए हैं और वह फूला हुआ महसूस होता है

  • लेकिन RSC एक अलग library है, इसलिए यह default React install में शामिल नहीं है
  • अगर पुराने version पर लौटना हो, तो git checkout v15.0.0 काफ़ी है

• RSC को शुरू से अस्तित्व में नहीं होना चाहिए था
  ज़्यादातर apps के लिए server पर HTML render करना ही काफ़ी है, और जिन मामलों में SPA सचमुच चाहिए वे बहुत कम हैं
  RSC ने सिर्फ़ complexity और security vulnerabilities बढ़ाई हैं

  • सहमत। लेकिन bootcamp और VC funding से आगे बढ़ाया जा रहा ecosystem इस दिशा को लगातार धक्का दे रहा है
    Bun, Vercel जैसे projects “सब कुछ पूरी तरह काम करने वाले JS utopia” का भ्रम बेच रहे हैं, इसलिए लगता है यह रुझान आसानी से ख़त्म नहीं होगा

• पहले Dan Abramov के साथ X पर RSC को लेकर बहस हुई थी
  उन्होंने इसे एक innovative feature कहा था, लेकिन मैंने इसे “अपने ही पैर पर गोली चलाने वाली बंदूक” कहा था। आख़िरकार हक़ीक़त वैसी ही निकली

  • मैंने व्यक्तिगत रूप से RSC के साथ app बनाया है और अब भी यह तरीका पसंद है
    लेकिन protocol level bugs की संभावना को कम आँका गया था। इस बार की vulnerability serialization protocol पर केंद्रित है
    security community अब जाकर इसे गहराई से देख रही है, इसलिए अच्छा होता अगर टीम ने पहले ही प्रतिक्रिया दी होती
  • सफल systems अक्सर अत्यधिक विस्तार के कारण राक्षस बन जाते हैं
    React भी एक simple rendering library से runtime में बदलते हुए complexity explosion का शिकार हुआ है
  • व्यक्तिगत रूप से मुझे Dan का approach इतना शानदार नहीं लगता
    इसके विपरीत Vue और Vite कहीं ज़्यादा परिष्कृत design लगते हैं → Evan You की व्यक्तिगत site
  • बेशक ज़्यादातर ideas असफल ही होते हैं, इसलिए सिर्फ़ आलोचना करने वाले रवैये से भी बचना चाहिए
    कभी-कभी साहसी प्रयास बड़ा सफल भी हो जाता है
  • किसी ने हौसला बढ़ाते हुए यह भी कहा, “हो सकता है आप ही बेहतर हों”

• अगर RSC frontend द्वारा backend को निगलने की कोशिश है, तो HTMX उसका उल्टा है
  HTMX client–server सीमा बनाए रखता है, इसलिए backend की तरफ़ यह सुरक्षित है, लेकिन frontend में XSS जोखिम है

  • लेकिन HTMX ने template engine के auto-escaping से XSS समस्या पहले ही हल कर ली है
    संबंधित लेख

• Next team ने नया security update घोषित किया है → NextJS Security Update 2025-12-11
  इसका असर 14.x, 15.x, 16.x versions पर पड़ता है