इस लेख में
5 अगस्त 2026 को Lidor Ben Shitrit के नेतृत्व में Novee के शोधकर्ताओं ने Black Hat USA में एक शोध प्रस्तुत किया, जिसमें चार एंटरप्राइज़ Java प्लेटफ़ॉर्म में बारह कमज़ोरियां उजागर की गईं। इनमें दो गंभीर चेन शामिल हैं जो बिना किसी लॉगिन के सर्वर पर कोड चलाने देती हैं, एक Bonita BPM वर्कफ़्लो प्लेटफ़ॉर्म में और दूसरी ओपन-सोर्स ERP Apache OFBiz में। किसी भी बिज़नेस मालिक के लिए व्यावहारिक सीख यह है: जिस सिस्टम को आप आंतरिक होने के कारण सुरक्षित मानते हैं, वह अगर नेटवर्क पर खुला है और पैच नहीं हुआ है, तो ब्राउज़र के दो अनुरोधों से उस तक पहुंचा जा सकता है। असली सुरक्षा इस सूची से शुरू होती है कि आप क्या चला रहे हैं और पैच लगाने की एक नियमित दिनचर्या से, नेटवर्क की बाहरी सीमा पर भरोसे से नहीं।
शोधकर्ताओं को असल में क्या मिला
यह शोध किसी एक चौंकाने वाले बग पर आधारित नहीं था। यह मिडलवेयर की छोटी, आम गलतियों को जोड़कर बनाया गया था: URL को पार्स करने के तरीके में अंतर, अनुरोध संभालने वाली परत पर अधूरी सुरक्षा, सोर्स कोड में हार्डकोड की गई क्रिप्टोग्राफ़िक कुंजियां, और असुरक्षित टेम्पलेट मूल्यांकन। अलग-अलग देखें तो इनमें से कोई भी खतरनाक नहीं लगती, और ठीक इसी वजह से ये कोड रिव्यू से बच निकलती हैं और कम प्राथमिकता में दर्ज कर दी जाती हैं। एक साथ जोड़ने पर ये एक अनाम विज़िटर से सर्वर पर कमांड चलाने तक का पूरा रास्ता बना देती हैं। बारह कमज़ोरियों में से चार ऑथेंटिकेशन से पहले काम करती हैं और एक निष्पादन सैंडबॉक्स के भीतर का अलगाव तोड़ देती है।
BadBonita चेन: तीन कमज़ोर बिंदु मिलकर एक पूरा समझौता
पहली चेन Bonita BPM के संस्करण 10.4.3 को प्रभावित करती है। यह तीन जुड़ी हुई कमज़ोरियों से बने ऑथेंटिकेशन बायपास से शुरू होती है: ..; नोटेशन का उपयोग करके पाथ ट्रैवर्सल, एक सुरक्षा फ़िल्टर जो पूरे पाथ के बजाय एक सबस्ट्रिंग पर मिलान करता है, और आंतरिक अनुरोध-फ़ॉरवर्डिंग लॉजिक। नतीजा यह होता है कि एक अनुरोध ऐसे आंतरिक API तक पहुंच जाता है जिसे बाहर किसी को कभी देखना ही नहीं था। वह API अविश्वसनीय XML स्वीकार करता है और उसे सीधे XStream लाइब्रेरी को दे देता है, जो उसे डिसीरियलाइज़ करती है, और Commons Collections की एक जानी-मानी गैजेट चेन के ज़रिए यह रास्ता सर्वर पर चलने वाले Groovy कमांड पर खत्म होता है।
ध्यान दें कि इनमें से किसी भी कदम के लिए लीक हुए पासवर्ड, सोशल इंजीनियरिंग या पहले से मौजूद पहुंच की ज़रूरत नहीं है। हमलावर को बस इतना चाहिए कि सिस्टम नेटवर्क पर पहुंच योग्य हो।
OFBiz: एक खुली रिपॉज़िटरी में प्रकाशित साइनिंग कुंजी
दूसरी समस्या, जिसे CVE-2026-31986 के रूप में ट्रैक किया गया है और गंभीर रेटिंग दी गई है, सिंगल साइन-ऑन सक्षम होने पर Apache OFBiz के संस्करण 24.09.05 को प्रभावित करती है। समस्या यह है कि डिफ़ॉल्ट साइनिंग कुंजियां सार्वजनिक रूप से प्रकाशित सोर्स कोड में मौजूद हैं, और चूंकि कई इंस्टॉलेशन डिफ़ॉल्ट को जस का तस छोड़ देते हैं, हमलावर किसी एडमिनिस्ट्रेटर अकाउंट के नाम पर एक वैध SSO टोकन जाली तरीके से बना सकता है। वहां से अनुरोध एक डिनायलिस्ट से गुज़रता है जिसने java, process और import जैसे शब्दों को रोकने की कोशिश की थी, लेकिन यह सूची केस-सेंसिटिव थी और खास पैटर्न जांचती थी, इसलिए किसी अक्षर का केस बदलना या स्वतः इम्पोर्ट होने वाली क्लास का कोई वैकल्पिक नाम इस्तेमाल करना उससे निकल जाने के लिए काफ़ी है। अंतिम नतीजा: SSO चलाने वाले किसी भी इंस्टॉल पर कोड निष्पादन तक पहुंचने के लिए बिना ऑथेंटिकेशन के दो GET अनुरोध काफ़ी हैं।
यह खास तौर पर आपके लिए क्यों मायने रखता है
क्योंकि इनमें से कोई भी मामूली टूल नहीं है। OFBiz एक ओपन-सोर्स ERP है जिसे कई कंपनियां इन्वेंटरी, खरीद और बिलिंग चलाने के लिए इस्तेमाल करती हैं, और Bonita एक वर्कफ़्लो इंजन है जो आंतरिक मंज़ूरियों और प्रक्रियाओं को चलाता है। जो भी इन दो जगहों तक पहुंचता है वह सिर्फ़ डेटा नहीं पढ़ रहा होता, वह आपके संचालन चक्र के बीच में खड़ा होता है: खरीद ऑर्डर, सप्लायर की कीमतें, कर्मचारियों के रिकॉर्ड, ग्राहकों का इतिहास। शोधकर्ताओं ने बताया कि दोनों वेंडरों ने मानक नब्बे दिन की प्रकटीकरण अवधि के भीतर सुधारे गए रिलीज़ जारी कर दिए, जिसका मतलब है कि अपडेट मौजूद है और अब ज़िम्मेदारी उस पर है जो सिस्टम चलाता है, उस पर नहीं जिसने उसे बनाया।
बाज़ार में असली कमी पैच की नहीं, सूची की है। कई संगठनों के पास इस बात की कोई ताज़ा सूची नहीं है कि वे असल में क्या चला रहे हैं, किस संस्करण पर और किस डोमेन पर। इसलिए एक पुरानी स्टेजिंग कॉपी किसी भूले हुए सबडोमेन पर दो साल तक लटकी रहती है और वह दरवाज़ा बन जाती है जिसके बारे में किसी ने सोचा ही नहीं।
इस हफ़्ते क्या करें
- अपने सिस्टम की सूची बनाएं: हर उस सिस्टम की लिखित सूची जो आप चलाते हैं, उसका संस्करण, क्या वह इंटरनेट पर खुला है, और नाम से उसका ज़िम्मेदार कौन है।
- अगर आप Bonita या OFBiz में से कोई भी चलाते हैं तो उसे तुरंत सुधारे गए रिलीज़ पर अपडेट करें, और अपग्रेड करने से पहले Apache का आधिकारिक सुरक्षा पेज पढ़ें।
- प्रोडक्ट के साथ आई हर डिफ़ॉल्ट एन्क्रिप्शन या साइनिंग कुंजी बदलें। दस्तावेज़ में छपा कोई भी मान गुप्त नहीं है।
- एडमिन गेटवे को खुले इंटरनेट के लिए बंद करें और उन तक एक निजी नेटवर्क या पतों की एक छोटी अनुमति-सूची के ज़रिए पहुंचें।
- पुरानी स्टेजिंग कॉपियां और इस्तेमाल न होने वाले सबडोमेन बंद करें। वे सबसे आसान निशाना हैं और उन पर सबसे कम निगरानी होती है।
- एक्सेस लॉगिंग चालू करें और लॉग संभालकर रखें। लॉग के बिना आप बाद में यह भी नहीं बता पाएंगे कि कोई अंदर आया भी था या नहीं।
इंजीनियरिंग की सीख: आंतरिक नेटवर्क सुरक्षा की सीमा नहीं है
इस शोध से निकली सबसे अहम सिफ़ारिश यह है कि आंतरिक रूटिंग पर इंटरनेट स्तर के नियंत्रण लागू किए जाएं। यह पुराना विचार कि फ़ायरवॉल के पीछे की हर चीज़ सुरक्षित है, व्यवहार में विफल हो चुका है: ऑथेंटिकेशन बायपास की एक ही खामी हर आंतरिक एंडपॉइंट को सार्वजनिक बना देती है। इससे इंजीनियरिंग के तीन नियम निकलते हैं, और वे आपके डेवलपमेंट मानकों में होने चाहिए:
किसी खतरनाक ऑपरेशन की सुरक्षा के लिए कभी डिनायलिस्ट पर निर्भर न रहें। अगर किसी कोड पाथ में एक्सप्रेशन मूल्यांकन की ज़रूरत नहीं है, तो उसे फ़िल्टर करने की कोशिश करने के बजाय पूरी तरह हटा दें।
दूसरा नियम है कि किसी संवेदनशील ऑपरेशन को कभी ऐसे सेटिंग फ़्लैग या यूज़र प्राथमिकता पर निर्भर न करें जिसे सिस्टम के अंदर से बदला जा सकता हो। तीसरा है ऑथेंटिकेशन फ़िल्टर लॉजिक में किसी भी सबस्ट्रिंग मिलान की जांच करना, क्योंकि इस श्रेणी में यह सबसे ज़्यादा दोहराई जाने वाली और सबसे आसानी से इस्तेमाल की जाने वाली गलती है। जब हम Origami में नए बिज़नेस सिस्टम बनाते हैं तो इसे डिफ़ॉल्ट रूप से लागू करते हैं: हर एंडपॉइंट पर स्पष्ट अधिकार-जांच, और नेटवर्क पर अनुरोध की स्थिति से कोई भरोसा नहीं।
सऊदी अरब में नियामक पहलू
अगर प्रभावित सिस्टम में किंगडम के भीतर के व्यक्तियों का व्यक्तिगत डेटा है, तो यह सिर्फ़ तकनीकी मामला नहीं रह जाता। व्यक्तिगत डेटा संरक्षण कानून (PDPL) नियंत्रक को उस डेटा की सुरक्षा के लिए ज़रूरी उपाय करने और उसकी गोपनीयता को प्रभावित करने वाली घटनाओं की रिपोर्ट करने के लिए बाध्य करता है। राष्ट्रीय साइबर सुरक्षा प्राधिकरण (NCA) आवश्यक नियंत्रण प्रकाशित करता है जो कमज़ोरियों के प्रबंधन, पैचिंग और एसेट प्रबंधन को कवर करते हैं, और ठीक यही वे नियंत्रण हैं जो इस चेन को रोक देते। किसी ऐसे प्रोडक्ट का पुराना संस्करण चलाना जिसकी ज्ञात कमज़ोरी पहले ही पैच हो चुकी है, किसी भी ऑडिट में ऐसी स्थिति है जिसका बचाव करना मुश्किल है।
सीधा नियम: सुरक्षा अपडेट को एक मासिक परिचालन प्रतिबद्धता मानें जिसका एक ज़िम्मेदार और एक तारीख हो, न कि किसी घटना के बाद की जाने वाली आपात कार्रवाई।
स्रोत
- Help Net Security — लॉगिन से पहले RCE चेन और CVE-2026-31986 का विवरण: helpnetsecurity.com
- Apache OFBiz का आधिकारिक सुरक्षा पेज: ofbiz.apache.org/security.html
- राष्ट्रीय साइबर सुरक्षा प्राधिकरण (NCA) — नियंत्रण और नियामक ढांचे: nca.gov.sa
- सऊदी डेटा और कृत्रिम बुद्धिमत्ता प्राधिकरण (SDAIA) — व्यक्तिगत डेटा संरक्षण कानून (PDPL): sdaia.gov.sa
सामान्य प्रश्न
क्या मेरी कंपनी इन कमज़ोरियों के जोखिम में है?
आप जोखिम में हैं अगर आप Bonita BPM का संस्करण 10.4.3 या उससे पुराना चलाते हैं, या सिंगल साइन-ऑन सक्षम होने के साथ Apache OFBiz का संस्करण 24.09.05 या उससे पुराना चलाते हैं, और सिस्टम नेटवर्क पर पहुंच योग्य है। वह संस्करण जांचें जो आप वास्तव में चला रहे हैं, न कि अनुबंध या हैंडओवर दस्तावेज़ में लिखा संस्करण, फिर सुधारे गए रिलीज़ पर अपग्रेड करें।
हमारा सिस्टम आंतरिक है और इंटरनेट पर प्रकाशित नहीं है, क्या हम सुरक्षित हैं?
ज़रूरी नहीं। इस शोध का मूल बिंदु यह है कि ऑथेंटिकेशन को बायपास करने वाली एक ही खामी हर आंतरिक एंडपॉइंट को खुला बना देती है, और उस तक पहुंचने के लिए नेटवर्क पर एक संक्रमित डिवाइस या किसी कर्मचारी का लीक हुआ अकाउंट काफ़ी है। आंतरिक सिस्टम को भी उसी स्तर की सुरक्षा दें: स्पष्ट अधिकार-जांच, डिफ़ॉल्ट से अलग कुंजियां, और नियमित अपडेट।
मुझे अपने सिस्टम वेंडर से कम से कम क्या मांगना चाहिए?
लिखित में तीन चीज़ें मांगें: उन कंपोनेंट और संस्करणों की सूची जिन पर आपका सिस्टम चलता है, गंभीर कमज़ोरियों के लिए तय प्रतिक्रिया समय वाली सुरक्षा अपडेट नीति, और एक आवधिक रिपोर्ट जो साबित करे कि अपडेट वास्तव में लागू किए गए। ये शर्तें सपोर्ट और मेंटेनेंस अनुबंध में रखें, ईमेल थ्रेड में नहीं।
क्या ओपन-सोर्स सॉफ़्टवेयर क्लोज़्ड-सोर्स से कम सुरक्षित है?
नहीं। फ़र्क़ यह है कि ओपन-सोर्स की खामियां उनके पैच के साथ सार्वजनिक रूप से बताई जाती हैं, इसलिए आप उन्हें देखकर कदम उठा सकते हैं, जबकि क्लोज़्ड-सोर्स की खामियां वेंडर के शेड्यूल पर निर्भर करती हैं। असली जोखिम दोनों मामलों में एक जैसा है: अपडेट मौजूद होने पर भी पुराना संस्करण चलाना। ओपन सोर्स तभी ज़्यादा जोखिम भरा बनता है जब आप उसकी डिफ़ॉल्ट कुंजियां और सेटिंग्स ठीक वैसी ही छोड़ देते हैं जैसी वे आई थीं।
Google पर Origami को फ़ॉलो करें
Origami को अपना पसंदीदा स्रोत बनाइए, तो हमारे लेख आपको Google Search और प्रमुख ख़बरों में सबसे पहले दिखेंगे।








