ईथेरियम क्लाइंट्स द्वारा एक दोष को ठीक किया गया जो ETH रिवॉर्ड्स को रीडायरेक्ट कर सकता था
Teku और Besu अपडेट्स बाहरी अवसंरचना सुरक्षा के महत्व पर प्रकाश डालते हैं
अक्टूबर 2026 के अंत में, ईथेरियम कंसेंसस क्लाइंट टेकू और एक्जीक्यूशन क्लाइंट बेसू ने भारतीय कंपनी eMudhra से संबंधित संक्रमित प्रमाणन प्राधिकरण कुंजियों से जुड़ी एक वल्नरेबिलिटी को बंद करने के लिए सुरक्षा रिलीज़ जारी कीं। यह दोष ऐसे हमलावरों को अनुमति दे सकता था जो कुछ HTTPS कनेक्शन्स को इंटरसेप्ट करते थे, ताकि वे वैलिडेटर्स द्वारा उपयोग किए जाने वाली बाहरी सेवाओं का नकल कर सकें और ब्लॉक पुरस्कारों को पुनः निर्देशित कर सकें या संवेदनशील हस्ताक्षर प्राप्त कर सकें। शोधकर्ताओं ने पाया कि eMudhra के आठ मध्यवर्ती प्रमाणन प्राधिकरणों की निजी कुंजियाँ पर्याप्त रूप से यादृच्छिकता के साथ उत्पन्न नहीं की गई थीं, जिससे उन कुंजियों को सार्वजनिक प्रमाणपत्रों से ही पुनः प्राप्त किया जा सकता था। चूँकि दोनों क्लाइंट्स द्वारा उपयोग किए जाने वाले Java रनटाइम्स में प्रारंभिक रूप से प्रमाणपत्र रद्दीकरण की जाँच नहीं होती है, कुछ Docker इमेजेस और स्थापनाएँ ब्राउज़र्स और प्रमुख संचालन प्रणालियों द्वारा उन्हें ब्लॉक करने के बाद भी प्रभावित श्रृंखलाओं पर भरोसा करती रहीं। HTTPS एंडपॉइंट्स से बचने वाली प्रारंभिक मेननेट टेकू कॉन्फ़िगरेशन प्रभावित नहीं हुईं, और डेवलपर्स ने कोई पुष्टि की हुई दुरुपयोग की सूचना नहीं दी।
पैच्स अपडेटेड Docker इमेजेस से संलग्न रूट्स पर विश्वास हटा देते हैं, जबकि स्टैंडअलोन बाइनरीज चला रहे ऑपरेटर्स को अपने स्थानीय Java ट्रस्ट स्टोर्स को अलग से संबोधित करना होगा। यह घटना यह बताती है कि बाहरी इंफ्रास्ट्रक्चर निर्भरताएं कैसे स्टेकिंग ऑपरेशन्स के लिए संकीर्ण लेकिन उच्च प्रभाव वाले जोखिम पैदा कर सकती हैं, भले ही मूल प्रोटोकॉल सुरक्षित रहे। टेकू और बेसू द्वारा त्वरित प्रतिक्रिया यह दर्शाती है कि ईथेरियम की क्लाइंट विविधता और सक्रिय सुरक्षा प्रथाएं कैसे सर्टिफिकेट-संबंधी खतरों को उनके वैलिडेटर पुरस्कारों को बड़े पैमाने पर प्रभावित करने से पहले रोक सकती हैं, जब तक कि ऑपरेटर्स उपलब्ध अपडेट्स लागू करते हैं और अपनी बाहरी कनेक्शन कॉन्फ़िगरेशन की समीक्षा करते हैं।
eMudhra इंटरमीडिएट कुंजियों में कमजोर रैंडमनेस के कारण पुनर्प्राप्तयोग्य निजी सामग्री बनी
शोधकर्ताओं ने 17 अक्टूबर, 2026 को यह समस्या पहचानी, जब उन्होंने निर्धारित किया कि eMudhra के आठ इंटरमीडिएट सर्टिफिकेट प्राधिकरणों के प्राइवेट कीज को बहुत कम एंट्रॉपी के साथ जनरेट किया गया था। ये कीज़ सार्वजनिक सर्टिफिकेट्स से प्रभावी ढंग से पुनः प्राप्त की जा सकती थीं, एक ऐसी स्थिति जो अप्रैल 2025 में की-जनरेशन समारोह में उनके निर्माण से ही मौजूद थी। इनमें से छह टीएलएस कनेक्शन्स को सपोर्ट करते थे, जबकि दो कोड साइनिंग से संबंधित थे। जब प्राइवेट सामग्री ज्ञात हो गई, तो हमलावर ऐसे धोखेबाज़ सर्टिफिकेट जारी कर सकता था जिन्हें प्रभावित प्राधिकरणों पर विश्वास करने वाले सॉफ़्टवेयर सही मानते। eMudhra ने 18 अक्टूबर को इंटरमीडिएट्स को रद्द कर दिया। प्रमुख प्लेटफॉर्म्स ने तुरंत प्रतिक्रिया दी: ब्राउज़र और ऑपरेटिंग सिस्टम्स ने 17 से 20 अक्टूबर के बीच सर्टिफिकेट्स को ब्लॉक करना शुरू कर दिया, और माइक्रोसॉफ़्ट ने 26–27 अक्टूबर को विंडोज़ और एज़ के अतिरिक्त अपडेट्स जारी किए जिन्होंने अपनी ट्रस्ट सूचियों से संबंधित मूल को हटा दिया। क्रिप्टोग्राफिक विफलता स्वयं ईथेरियम प्रोटोकॉल की समस्या नहीं थी, फिर भी यह महत्वपूर्ण थी क्योंकि Teku और Besu अपने नोड्स द्वारा की जाने वाली किसी भी HTTPS कनेक्शन के लिए Java सर्टिफिकेट प्रमाणीकरण पर निर्भर हैं। Java का हटाए गए पुनः प्राप्ति की जाँच को छोड़ने का पूर्वनिर्धारित व्यवहार कुछ स्थापनाओं को ब्राउज़र पर्यावरणों की तुलना में अधिक समय के लिए संवेदनशील बना देता है। इसलिए, यह प्रसंग दर्शाता है कि कैसे किसी एक सर्टिफिकेट प्राधिकरण की संचालन समस्या मानक TLS ट्रस्ट स्टोर पर निर्भर करने वाली विशेषज्ञता संबंधी प्रणाली में प्रसारित हो सकती है।
कुंजियों की पुनर्प्राप्ति के लिए जटिल क्रिप्टोएनालिसिस की आवश्यकता नहीं थी; अपर्याप्त यादृच्छिकता के कारण, जब तक सार्वजनिक प्रमाणपत्रों की जांच की गई, तब तक निष्कर्ष निकालना सरल हो गया। माइक्रोसॉफ्ट की 26 अक्टूबर की सलाह ने पुष्टि की कि कुंजियों का उपयोग एक विश्वसनीय प्राधिकरण से उत्पन्न होने वाले प्रमाणपत्र बनाने के लिए किया जा सकता है, जिससे वेबसाइटों या सेवाओं की छलावरण संभव हो सकती है। ईथेरियम संचालकों के लिए, व्यावहारिक परिणाम यह था कि HTTPS एंडपॉइंट्स, रिमोट बीकन नोड्स, बाहरी साइनर, ब्लॉक बिल्डर्स या रिले पर निर्भर कोई भी वैलिडेटर कॉन्फ़िगरेशन एक झूठा प्रमाणपत्र स्वीकार कर सकता है, यदि मूल Java रनटाइम अभी भी संक्रमित श्रृंखला पर भरोसा करता है। ईथेरियम क्लाइंट्स द्वारा उपयोग किए जाने वाले पीयर-टू-पीयर नेटवर्किंग प्रभावित नहीं हुए क्योंकि इसका निर्भरता इन प्रमाणपत्र प्राधिकरणों पर नहीं है। पुनर्प्राप्त कुंजियों और अन-समाप्त Java मान्यता के संयोजन से एक ऐसा समय-अंतराल बना, जिसमें नेटवर्क मार्ग पर स्थित मैन-इन-द-मिडल हमलावर क्लाइंट सॉफ़्टवेयर को एक संभावित पहचान प्रस्तुत कर सकता है। क्लाइंट टीमों ने केवल मूल Java अपडेट का प्रतीक्षा करने के बजाय, अपने Docker इमेज से संबंधित मूलों को हटा दिया, जिससे नए इमेज पुल करने वाले संचालकों को मजबूत ट्रस्ट स्टोर मिल सके। CA पर समाप्ति, प्लेटफ़ॉर्म प्रतिबंध, और क्लाइंट-विशिष्ट इमेज अपडेट के संयोजन से, अधिकांश स्टेकिंग सेटअप के लिए व्यावहारिक हमला सतह सीमित हो गई।
कैसे जाली प्रमाणपत्र ब्लॉक प्रस्ताव और शुल्क प्राप्तकर्ता व्यवहार को बदल सकते हैं
Teku की सुरक्षा सलाह ने वास्तविक हमले के मार्गों को बताया जो तब संभव हो जाते हैं जब हमलावर क्लाइंट द्वारा स्वीकृत एक झूठा प्रमाणपत्र प्रस्तुत कर सके। एक परिदृश्य में एक वैलिडेटर द्वारा समन्वय के लिए उपयोग किए जाने वाले दूरस्थ बीकन नोड की छलांग लगाई जाती है। यदि संपर्क अवरुद्ध हो जाता है और झूठा प्रमाणपत्र स्वीकार कर लिया जाता है, तो वैलिडेटर को उस ब्लॉक के बारे में हेरफेर की गई जानकारी मिल सकती है जिसे वह प्रस्तुत करने के लिए तैयार कर रहा है। इस मामले में, क्लाइंट एक ब्लॉक का निर्माण और हस्ताक्षर कर सकता है जिसका फी-प्राप्तकर्ता पता हमलावर द्वारा नियंत्रित खाते की ओर संकेत करता है, न कि संचालक के निर्धारित पते की ओर। ब्लॉक में सम्मिलित सभी लेनदेन शुल्क और प्राथमिकता टिप्स प्राप्तकर्ता को प्रवाहित होंगे। सलाह में बाहरी हस्ताक्षर सेवाओं को भी दिखाया गया, जो वैलिडेटर कुंजियों को अलग से रखती हैं और अनुरोध पर हस्ताक्षर प्रदान करती हैं। एक हमलावर, जो ऐसे हस्ताक्षरकर्ता की छलांग लगा सके, संवेदनशील संचालनों, जिनमें पुरस्कारों के निर्देशन को प्रभावित करने वाले बदलाव सहित, प्रयुक्त हस्ताक्षर प्राप्त कर सकता है। Teku ने बाहरी-हस्ताक्षरकर्ता मामले को अधिक गंभीर कॉनफ़िगरेशन में से एक के रूप में वर्गीकृत किया, हालाँकि कुछ सेटअप में पारस्परिक TLS प्रमाणीकरण प्रभाव को सेवा-अस्वीकृति तक सीमित कर देगा, हस्ताक्षर संक्रमण के प्रति।
अतिरिक्त उजागर किए गए कनेक्शन प्रकारों में निष्पादन क्लाइंट, ब्लॉक बिल्डर, रिले और वैलिडेटर कॉन्फ़िगरेशन डेटा प्रदान करने वाली सेवाएँ शामिल हैं। प्रत्येक मामले में, मूल जोखिम एक ही है: क्लाइंट सॉफ़्टवेयर झूठा सर्टिफिकेट को वैध मानता है और इसलिए एक प्रस्तावित ब्लॉक की सामग्री या कुंजियों के प्रबंधन को बदलने वाले डेटा या निर्देशों को स्वीकार करता है। इस दुर्बलता से सामान्य संचालन के दौरान वैलिडेटर की साइनिंग कुंजी तक सीधा पहुँच प्राप्त नहीं होता; इसके बजाय, यह वैलिडेटर द्वारा सलाह ली जाने वाली बाहरी सेवाओं की पूर्णता को बेअसर कर देता है। चूँकि ईथेरियम ब्लॉक पुरस्कार और शुल्क प्रस्तावित ब्लॉक में समाहित पतों के अनुसार भुगतान किए जाते हैं, प्रस्तावना समय के दौरान सफल हस्तक्षेप से पहले से कमाए गए धन को स्थानांतरित किए बिना ही मूल्य को विचलित किया जा सकता है। इन मार्गों का कोई दुरुपयोग अब तक रिपोर्ट नहीं किया गया है, और उन मुख्यनेट Teku स्थापनाओं, जिनमें उनकी कॉन्फ़िगरेशन में कोई HTTPS URL नहीं है, प्रभावित सेट के बाहर हैं। हालाँकि, विस्तृत परिदृश्य स्पष्ट करते हैं कि क्लाइंट टीमों ने इस मुद्दे को क्यों तत्काल Docker-इमेज अपडेट की आवश्यकता मानी, हालाँकि मूल प्रोटोकॉल और पीयर-टू-पीयर स्तरों को स्पर्श नहीं किया गया।
Teku 26.10.3 Docker ट्रस्ट स्टोर्स से � compromis ed रूट्स हटाता है
Teku ने 27 अक्टूबर, 2026 को eMudhra-संबंधित एक्सपोजर को संबोधित करने के लिए संस्करण 26.10.3 जारी किया। रिलीज नोट्स में बताया गया है कि अब Docker इमेज emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2, या AAA Certificate Services रूट्स पर भरोसा नहीं करते हैं। इन रूट्स को OpenJDK ने इंटरमीडिएट अथॉरिटीज़ के सुरक्षा उल्लंघन के बाद हटा दिया था; Teku द्वारा उपयोग किए जाने वाले Eclipse Temurin बेस इमेज में अभी तक संबंधित सुधार शामिल नहीं किया गया था। अपडेटेड इमेज प्रदान करके, Teku टीम ने सुनिश्चित किया कि जो संचालक नए टैग प्राप्त करते हैं, उन्हें एक Java रनटाइम मिलता है, जिसका ट्रस्ट स्टोर संक्रमित सामग्री को शामिल नहीं करता है। रिलीज के साथ संलग्न सलाह में जोर दिया गया है कि कोई भी डिफ़ॉल्ट मेननेट नोड, जिसमें कोई HTTPS URL कॉन्फ़िगर नहीं किया गया है, को कोई कार्रवाई की आवश्यकता नहीं है। एक्सपोजर केवल उन कॉन्फ़िगरेशन तक सीमित है, जो स्पष्ट रूप से बीकन समन्वय, बाहरी हस्ताक्षर, बिल्डर्स, या समान सेवाओं के लिए रिमोट HTTPS एंडपॉइंट्स से कनेक्ट होते हैं।
पुराने Docker इमेज चला रहे ऑपरेटर, जिनमें 26.10.2 तक के टैग शामिल हैं, अभी भी एक ऐसा रनटाइम शिप कर रहे हैं जो प्रभावित रूट्स पर भरोसा करता है। मौजूदा कंटेनर के अंदर के रनटाइम को अपडेट करने के लिए होस्ट Java इंस्टॉलेशन को अपडेट करना पर्याप्त नहीं है, इसलिए एक नया इमेज पुल करना आवश्यक है। टेकू ने आगे बताया कि Java 26 का लाइफसाइकिल समाप्त हो चुका है और इसके लिए कोई पैचड बिल्ड उपलब्ध नहीं होगी; इस संस्करण पर अभी भी काम कर रहे ऑपरेटर्स को वर्तमान लॉन्ग-टर्म सपोर्ट रिलीज, Java 25 पर स्विच करने और संबंधित -jdk25 इमेज टैग्स का उपयोग करने की सलाह दी गई है। इसलिए, रिलीज में सर्टिफिकेट-रूट हटाने के साथ-साथ रनटाइम संस्करण प्रबंधन पर मार्गदर्शन शामिल है। क्योंकि यह बदलाव केवल Docker इमेज के ट्रस्ट स्टोर्स तक सीमित है, सहमति व्यवहार और वैलिडेटर की हैंडलिंग में कोई परिवर्तन नहीं हुआ है। इस अपडेट को एक आपातकालीन सहमति अपग्रेड के बजाय एक सुझाया हुआ सुरक्षा उपाय के रूप में प्रस्तुत किया गया है, क्योंकि प्रभावित कॉन्फ़िगरेशन का परिसर सीमित है।
Besu 26.10.2 समानांतर प्रमाणपत्र विश्वास समायोजन लागू करता है
बेसु, जो एक ही व्यापक परितंत्र द्वारा रखरखाव किया जाता है, ने 26 अक्टूबर, 2026 को संस्करण 26.10.2 जारी किया, जिसमें अपने डॉकर इमेज में समान जड़ हटाव किए गए। समान समय और समान प्रमाणपत्र लक्ष्यों से पता चलता है कि जावा-आधारित ईथेरियम क्लाइंट स्टैक के भीतर eMudhra घटना के प्रति समन्वित जागरूकता थी। निष्पादन क्लाइंट संगठन क्लाइंट और बाहरी सेवाओं के साथ पेलोड निर्माण और लेनदेन सम्मिलन के लिए बातचीत करते हैं; उनके द्वारा बनाए गए कोई भी HTTPS संचार मार्ग समान प्रमाणपत्र-सत्यापन नियमों के अधीन होते हैं जो टेकू को प्रभावित करते हैं। अपने इमेज से संक्रमित प्राधिकरणों के लिए विश्वास हटा कर, बेसु उन संचालकों के लिए संबंधित हमला सतह बंद कर देता है जो इसके डॉकर वितरणों पर निर्भर हैं।
टेकू की तरह, बेसू अपडेट स्वतः उन स्टैंडअलोन बाइनरी इंस्टॉलेशन्स को ठीक नहीं करता है जो अलग से प्रबंधित जावा रनटाइम का उपयोग करते हैं। इस श्रेणी के संचालकों को अपने स्थानीय ट्रस्ट स्टोर या जावा संस्करण की स्वतंत्र रूप से जांच करनी चाहिए और अपडेट करना चाहिए। डुअल क्लाइंट रिलीज़ से पता चलता है कि ईथेरियम नोड सॉफ्टवेयर स्टैक के समझौता और निष्पादन दोनों पहलुओं ने जावा सर्टिफिकेट हैंडलिंग पर साझा निर्भरता को मान्यता दी है। क्योंकि कई उत्पादन वैलिडेटर्स टेकू जैसे समझौता क्लाइंट और बेसू जैसे निष्पादन क्लाइंट दोनों चलाते हैं, समान समय पर अपडेट करने से नोड जोड़ी के किसी भी पहलु पर कम्प्रोमाइज़ किए गए रूट्स में शेष विश्वास के रहने की संभावना कम होती है। रिलीज़ से पहले किसी भी दुरुपयोग की रिपोर्ट न होना सुझाता है कि व्यावहारिक समय सीमित था, हालांकि समन्वित पैच अभी भी ईथेरियम प्रोटोकॉल के बाहर एक ज्ञात क्रिप्टोग्राफिक विफलता के खिलाफ प्रudent हार्डनिंग का प्रतिनिधित्व करते हैं।
जावा की डिफ़ॉल्ट रिवोकेशन चेकिंग की कमी के कारण लंबा एक्सपोजर
एक केंद्रीय तकनीकी विवरण यह है कि Java प्रमाणपत्र मान्यता डिफ़ॉल्ट रूप से प्रतिकूलन स्थिति की जांच नहीं करती है। यहां तक कि eMudhra द्वारा मध्यवर्ती प्रमाणपत्रों को प्रतिकूलित करने के बाद और प्रमुख प्लेटफ़ॉर्म द्वारा उन्हें ब्लॉक करने के बाद, भी कोई भी Java रनटाइम जिसमें अभी भी इसके संबंधित रूट या मध्यवर्ती इसके विश्वास संग्रह में मौजूद हों, उन प्राधिकरणों के लिए श्रृंखला बनाने वाले प्रमाणपत्रों को स्वीकार करता रहेगा। OpenJDK ने सुधार जारी किए जिन्होंने पहले संक्रमित मध्यवर्ती प्रतिकूलित किए और बाद में चार संबंधित रूट हटा दिए। हालांकि, पुराने Temurin या OpenJDK बिल्ड्स वाले Docker इमेजेस को ये सुधार स्वचालित रूप से प्राप्त नहीं हुए। प्लेटफ़ॉर्म-स्तरीय प्रतिकूलन और समाहित Java रनटाइम के व्यवहार के बीच यह अंतर ही ग्राहक-विशिष्ट इमेज अपडेट को आवश्यक बनाता है।
ईथेरियम ऑपरेटर्स के लिए, इसका प्रभाव केवल सैद्धांतिक नहीं, बल्कि संचालनात्मक है। एक वैलिडेटर जिसकी कॉन्फ़िगरेशन में रिमोट सेवाओं के लिए HTTPS एंडपॉइंट्स शामिल हैं, वह अपने उपयोग किए जा रहे Java रनटाइम के विश्वास निर्णयों को विरासत में प्राप्त करता है। यदि वह रनटाइम अपडेट नहीं किया गया है या पैच किए गए इमेज से प्रतिस्थापित नहीं किया गया है, तो क्लाइंट एक झूठा सर्टिफिकेट स्वीकार करने के लिए तैयार रहता है। सावधानीपूर्वक डिज़ाइन किए गए सेटअप में म्यूचुअल TLS या पिन किए गए सर्टिफिकेट जोखिम को कम कर सकते हैं, लेकिन कई उत्पादन कॉन्फ़िगरेशन मानक ट्रस्ट-स्टोर प्रमाणीकरण पर निर्भर करते हैं। इसलिए, टेकू और बेसु रिलीज़ एक व्यावहारिक स्मरण के रूप में कार्य करती हैं कि कंटेनराइज़्ड नोड सॉफ़्टवेयर के पास होस्ट सिस्टम से स्वतंत्र अपना सर्टिफिकेट स्टोर होता है। जो ऑपरेटर Docker इमेज को अज्ञात काले बॉक्स के रूप में मानते हैं, वे इस विवरण को तब तक नज़रअंदाज़ कर सकते हैं जब तक कि कोई बाहरी घटना अपडेट के लिए मजबूर न कर दे। यह मामला जावा-आधारित ईथेरियम क्लाइंट्स चलाते समय अपस्ट्रीम Java सुरक्षा सलाहों की निगरानी के महत्व को भी प्रकट करता है।
डिफ़ॉल्ट मेननेट कॉन्फ़िगरेशन्स ने प्राथमिक आक्रमण सतह से बचाव किया
Teku की सलाह स्पष्ट है कि एक डिफ़ॉल्ट मेननेट नोड, जिसके कॉन्फ़िगरेशन में कोई HTTPS URL नहीं है, अप्रभावित रहता है और कोई कार्रवाई की आवश्यकता नहीं होती। अधिकांश वैलिडेटर जो स्थानीय रूप से समझौता और निष्पादन क्लाइंट चलाते हैं, बिना रिमोट साइनिंग या रिमोट बीकन एंडपॉइंट के, इस श्रेणी में आते हैं। Ethereum द्वारा उपयोग किए जाने वाले पीयर-टू-पीयर खोज और गॉसिप प्रोटोकॉल eMudhra सर्टिफिकेट प्राधिकरणों पर निर्भर नहीं करते, जिससे मानक सेटअप अधिक सुरक्षित होते हैं। जो संचालक क्रियाकलापों की सुविधा, साइनिंग कुंजियों के भौगोलिक वितरण, या तीसरे पक्ष की ब्लॉक-बिल्डिंग सेवाओं के समाकलन के लिए जानबूझकर बाहरी HTTPS निर्भरताएँ शामिल करते हैं, उनके बीच ही जोखिम केंद्रित है। पूरे नेटवर्क प्रभाव का मूल्यांकन करने के लिए यह भेद महत्वपूर्ण है। क्योंकि मेननेट वैलिडेटर्स का अधिकांश हिस्सा ऐसे कॉन्फ़िगरेशन के साथ काम करता है, जिन्होंने कभी कमजोर सर्टिफिकेट श्रृंखलाओं से संपर्क नहीं किया, इसलिए पैच से पहले ही सैद्धांतिक हमले का पृष्ठ सीमित रहा।
ग्राहक टीमों द्वारा अपडेटेड छवियों को फिर भी जारी करने का निर्णय उन संचालकों के उपसमूह की सुरक्षा करता है जो दूरस्थ सेवाओं का उपयोग करते हैं और भविष्य की छवि खींचने को एक मजबूत आधार से शुरू करने की गारंटी देता है। HTTPS के माध्यम से प्रारंभिक अवस्था डाउनलोड करने वाले टेस्टनेट कॉन्फ़िगरेशन को संभावित रूप से उजागर के रूप में चिह्नित किया गया, जिससे स्पष्ट होता है कि एक ही प्रमाणपत्र तर्क मेननेट के बाहर भी लागू होता है। किसी भी नेटवर्क के संचालक, जो HTTPS बूटस्ट्रैप या दूरस्थ एंडपॉइंट पर निर्भर हैं, उन्हें अपने पर्यावरण के लिए अक्टूबर 2026 के रिलीज़ को अनिवार्य मानना चाहिए। डिफ़ॉल्ट और गैर-डिफ़ॉल्ट कॉन्फ़िगरेशन के बीच स्पष्ट पृथक्करण के कारण सलाह पूरे वैलिडेटर सेट के लिए सटीक और प्रशमित करने वाली हो सकी।
बाहरी साइनर और रिमोट बीकन नोड्स सर्वोच्च जोखिम वाले मार्गों का प्रतिनिधित्व करते हैं
टेकू द्वारा सूचीबद्ध परिदृश्यों में, बाह्य हस्ताक्षर सेवाओं की गंभीरता अधिक थी। ये सेवाएँ वैलिडेटर की निजी कुंजियों को ऑफलाइन या विशेष हार्डवेयर में रखती हैं और नेटवर्क कनेक्शन के माध्यम से हस्ताक्षर अनुरोधों का उत्तर देती हैं। यदि कोई हमलावर एक झूठा प्रमाणपत्र प्रस्तुत करके हस्ताक्षरकर्ता का अपनापन कर सकता है, तो वैलिडेटर क्लाइंट ऐसे हस्ताक्षर स्वीकार कर सकता है जो ऑपरेटर द्वारा कभी इच्छित नहीं हुए कार्रवाइयों को सशक्त बनाते हैं, जिनमें फी-प्राप्तकर्ता सेटिंग्स बदलना या निकास शुरू करना शामिल है। पारस्परिक TLS प्रमाणीकरण को लागू करने वाले कॉन्फ़िगरेशन प्रभाव को सेवा के असमर्थन तक सीमित कर देते हैं, क्योंकि हमलावर प्रमाणीकृत हैंडशेक पूरा नहीं कर सकता। जहाँ पारस्परिक प्रमाणीकरण अनुपस्थित है, वहाँ उपयोगी हस्ताक्षर प्राप्त करने का जोखिम अधिक होता है। दूरस्थ बीकन नोड्स संबंधित लेकिन भिन्न चिंता प्रस्तुत करते हैं।
एक वैलिडेटर जो कुछ समन्वय कार्यों को एक दूरस्थ बीकन एंडपॉइंट को सौंपता है, उस एंडपॉइंट पर अपनी कर्तव्यों, ब्लॉक की सामग्री और नेटवर्क स्थिति के बारे में जानकारी के लिए भरोसा करता है। इसलिए, एक सफल छलावा उस ब्लॉक को प्रभावित कर सकता है जिसे वैलिडेटर अंततः प्रस्तावित करता है, जिसमें उस ब्लॉक में शामिल फी-प्राप्तकर्ता पता भी शामिल है। ब्लॉक बिल्डर और रिले अभी भी अन्य HTTPS सतहें पेश करते हैं, जिनके माध्यम से हेरफेर किए गए पेलोड को इंजेक्ट किया जा सकता है। प्रत्येक मामले में, हमलावर को पहले एक ऐसी नेटवर्क पोज़ीशन प्राप्त करनी होगी जो अवरोधन की अनुमति दे, और फिर एक प्रमाणपत्र प्रस्तुत करना होगा जिसे अपडेट नहीं किया गया Java रनटाइम स्वीकार करे। आवश्यकताओं का संयोजन वास्तविक प्रतिद्वंद्वियों के सेट को संकुचित करता है, फिर भी संभावित पुरस्कार, एक सफल प्रस्ताव से पुनः निर्देशित शुल्क, प्रतिरोधी पैचों को समझाता है। बाहरी साइनर्स या दूरस्थ अवसंरचना को बनाए रखने वाले संचालकों को उन कड़ियों पर क्लाइंट अपडेट्स के साथ-साथ प्रमाणीकरण तंत्र की समीक्षा पर प्राथमिकता देनी चाहिए।
अलग-अलग बाइनरीज चला रहे ऑपरेटर्स को अलग जावा अपडेट के दायित्व का पालन करना होगा
डॉकर उपयोगकर्ता नए Teku 26.10.3 या Besu 26.10.2 इमेज को पुल करके समाधान कर सकते हैं। जो ऑपरेटर क्लाइंट को स्टैंडअलोन बाइनरी या पैकेज के रूप में स्थापित करते हैं, वे होस्ट सिस्टम पर मौजूद Java रनटाइम पर निर्भर करते हैं। इन स्थापनाओं के लिए, क्लाइंट रिलीज़ स्वयं होस्ट ट्रस्ट स्टोर को नहीं बदलते हैं। इसलिए, ऑपरेटर्स को सुनिश्चित करना चाहिए कि उनके स्थापित Java संस्करण में OpenJDK द्वारा किए गए उन सुधारों को शामिल किया गया है, जो दुर्भावनापूर्ण रूट्स को हटा देते हैं, या उन्हें मैनुअल रूप से सर्टिफिकेट स्टोर को समायोजित करना होगा। Teku ने विशेष रूप से चेतावनी दी है कि Java 26 का समर्थन समाप्त हो चुका है और इसके लिए कोई पैचड बिल्ड उपलब्ध नहीं होगा; निरंतर समर्थन और सुरक्षा अपडेट के लिए Java 25 पर स्थानांतरण करना आवश्यक है। ईथेरियम इंफ्रास्ट्रक्चर में कंटेनराइज़्ड और बेयर-मेटल डिप्लॉयमेंट के बीच यह अंतर सामान्य है और नोड ऑपरेटर्स के लिए एक व्यावहारिक चेकलिस्ट आइटम बनाता है।
जावा संस्करणों की सूची, ट्रस्ट-स्टोर की सामग्री की पुष्टि, और यह सुनिश्चित करना कि कोई भी HTTPS एंडपॉइंट अविश्वसनीय सेवाओं की ओर न इशारा कर रहा हो, न्यूनतम पोस्ट-पैच स्वच्छता का आधार है। चूंकि आधारभूत क्रिप्टोग्राफिक विफलता ईथेरियम के बाहर हुई है, इसलिए किसी भी अन्य जावा-आधारित उपकरणों के लिए, जिन्हें ऑपरेटर चला सकता है, वही जावा अपडेट के दायित्व लागू होते हैं। इसलिए क्लाइंट सलाहकार प्रतिवेदन न केवल टेकू और बेसू के लिए विशिष्ट समाधान हैं, बल्कि ऑपरेटर के स्टैक के भरपूर सर्टिफिकेट प्रबंधन की समीक्षा के लिए एक व्यापक प्रेरणा भी हैं। होस्ट जावा पर्यावरण को संबोधित न करने से, क्लाइंट सॉफ़्टवेयर को अपडेट करने के बाद भी सैद्धांतिक हमले के मार्ग खुले रहते हैं।
पैच लागू होने से पहले कोई पुष्टि की गई दुरुपयोग नहीं हुआ
टेकू सलाह और समकालीन रिपोर्टिंग दोनों यह बताती हैं कि इस वल्नरेबिलिटी का कोई दुरुपयोग नहीं देखा गया है। ज्ञात घटनाओं के अभाव का अर्थ है कि सफल हमले के लिए आवश्यक शर्तों का सीमित सेट है: एक अपडेट नहीं किया गया Java रनटाइम, एक बाहरी सेवा के साथ HTTPS कनेक्शन, और एक हमलावर जो उस विशिष्ट कनेक्शन को इंटरसेप्ट कर सके और एक झूठा सर्टिफिकेट प्रस्तुत कर सके। अधिकांश वैलिडेटर्स कभी भी पहली दो शर्तों को एक साथ पूरा नहीं करते थे। 17 अक्टूबर को पुनः प्राप्त की गई कुंजियों के सार्वजनिक प्रकाशन और क्लाइंट इमेज रिलीज़ के बीच का छोटा समय अंतर प्रैक्टिकल विंडो को और संकुचित कर दिया।
अवलोकित हमलों की कमी के कारण पैचों का मूल्य कम नहीं होता। प्रमाणपत्र-संबंधी दुर्बलताएँ तब तक निष्क्रिय रह सकती हैं जब तक कि एक अवसरवादी शत्रु प्रकट न हो जाए। डॉकर ट्रस्ट स्टोर्स से संक्रमित जड़ों को हटाकर, क्लाइंट टीमों ने अपडेट करने वाले ऑपरेटर्स के लिए झूठे प्रमाणपत्रों को स्वीकार करने का रास्ता बंद कर दिया। इस घटना ने यह भी एक लाइव प्रदर्शन प्रदान किया कि बाहरी क्रिप्टोग्राफिक विफलताएँ ईथेरियम स्टेकिंग बुनियादी ढांचे के साथ कैसे जुड़ सकती हैं, जिससे ऑपरेटर्स को अपने स्वयं के निर्भरता ग्राफ़ की जाँच करने के लिए प्रेरित किया गया। प्रमाणपत्र प्राधिकरणों या भाषा रनटाइम्स से संबंधित भविष्य की घटनाओं का सामना संभवतः समान क्लाइंट-स्तरीय प्रतिक्रियाओं के साथ किया जाएगा, जो त्वरित, लक्ष्यित हल के पैटर्न को मजबूत करता है।
कैसे प्रमाणन सुरक्षा जोखिम ब्लॉकचेन नेटवर्क्स के भर में फैलते हैं
ईएमुध्रा की घटना केवल ईथेरियम तक सीमित नहीं है; कोई भी सॉफ्टवेयर जो मानक TLS विश्वास स्टोर पर निर्भर करता है, उसकी सुरक्षा स्थिति उन प्रमाणपत्र प्राधिकरणों की होती है जिन पर यह भरोसा करता है। जावा, गो, या अन्य भाषा रनटाइम्स को एम्बेड करने वाले ब्लॉकचेन क्लाइंट्स को समझौता बदलावों के समान ध्यान से अपस्ट्रीम प्रमाणपत्र अपडेट्स का पालन करना चाहिए। यह तथ्य कि जावा की डिफ़ॉल्ट कॉन्फ़िगरेशन में प्रतिकूलन जांच को छोड़ दिया गया है, ने प्रभाव को बढ़ाया और क्लाइंट टीम्स को अपने स्वयं के ट्रस्ट-स्टोर संशोधन जारी करने के लिए मजबूर कर दिया। लंबे समय तक चलने वाले रनटाइम्स को कंटेनर्स के भीतर पैकेज करने वाले अन्य परितंत्र इसी प्रकार के जोखिमों का सामना करते हैं।
ईथेरियम स्टेकिंग समुदाय के लिए व्यावहारिक सबक यह है कि संचालन सुरक्षा केवल कुंजी प्रबंधन और क्लाइंट संस्करण के बारे में ही नहीं है, बल्कि प्रत्येक नेटवर्कयुक्त घटक के प्रमाणपत्र मान्यता व्यवहार को भी शामिल करती है। जो संचालक दूरस्थ हस्ताक्षर, वितरित बीकन नोड या तीसरे पक्ष के रिले स्वीकार करते हैं, वे अतिरिक्त विश्वास सीमाएँ पेश करते हैं जिनका निरीक्षण किया जाना आवश्यक है। CA रद्दीकरण, प्लेटफॉर्म ब्लॉक और क्लाइंट इमेज अपडेट के माध्यम से इस विशिष्ट दोष का सफलतापूर्वक नियंत्रण दर्शाता है कि प्रत्येक परत जब तुरंत प्रतिक्रिया करती है, तो परतबद्ध सुरक्षा काम कर सकती है। लगातार क्लाइंट विविधता मूल्यवान बनी रहती है क्योंकि विभिन्न कार्यान्वयन बाहरी निर्भरताओं को अलग-अलग गति से प्रकट कर सकते हैं या कमजोर कर सकते हैं, जिससे एकल प्रमाणपत्र विफलता के कारण पूरे वैलिडेटर सेट को एक साथ प्रभावित होने की संभावना कम हो जाती है।
वैलिडेटर इंफ्रास्ट्रक्चर में हाल की समानांतर चिंताएँ निरंतर सावधानी को दर्शाती हैं
अक्टूबर 2026 प्रमाणपत्र पैच्स अन्य वैलिडेटर-संबंधी सुरक्षा ध्यान के संदर्भ में आए। पहले की घोषणाओं में स्टेकिंग सेवा बुनियादी ढांचे और फी-प्राप्तकर्ता प्रबंधन से संबंधित मुद्दे पहले से ही बड़े पैमाने पर स्वैच्छिक निकास और पुरस्कार प्रवाह की बढ़ी हुई निगरानी का कारण बन चुके थे। अलग से, विकासकर्ताओं ने आगामी Glamsterdam अपग्रेड के लिए मसौदा नियमों में एक डिपॉज़िट-रूटिंग समस्या को सुलझाया, जिससे कुछ सार्वजनिक-चाबी टकराव की स्थिति में स्टेकिंग डिपॉज़िट्स गलत तरीके से आवंटित हो सकते थे; इस सुधार को अतिरिक्त समीक्षा के बाद सहमति विनिर्देशों में मिला दिया गया। ये समानांतर घटनाएँ दर्शाती हैं कि वैलिडेटर अर्थव्यवस्था और संचालनात्मक सुरक्षा अभी भी समीक्षा के सक्रिय क्षेत्र हैं, भले ही मूल प्रोटोकॉल विकसित होता रहे।
प्रमाणपत्र की खामी की उत्पत्ति भिन्न थी; यह एक बाहरी सीए से उत्पन्न हुई, ईथेरियम स्पेसिफिकेशन या क्लाइंट सहमति बग से नहीं, फिर भी यह एक ही आर्थिक सतह को छूती थी: प्रस्तावकों द्वारा कमाए गए शुल्क और पुरस्कारों का गंतव्य। इसलिए क्लाइंट की त्वरित प्रतिक्रिया किसी भी वास्तविक पुरस्कार अपहरण के मार्ग को उच्च प्राथमिकता के रूप में मानने के एक व्यापक पैटर्न के साथ मेल खाती है। जो संचालक विविध क्लाइंट सेटअप बनाए रखते हैं, ऑन-चेन पर शुल्क-प्राप्ति पते का निरीक्षण करते हैं, और सहमति और निष्पादन सॉफ़्टवेयर दोनों को अपडेटेड रखते हैं, वे ऐसी बाहरी सदमों को सहन करने के लिए बेहतर स्थिति में होते हैं। eMudhra मामले में हानि का अभाव यह पुष्टि करता है कि समय पर पैचिंग और कॉन्फ़िगरेशन का पालन अभी भी प्रभावी सुरक्षा है।
अक्टूबर के रिलीज़ के बाद ईथेरियम नोड ऑपरेटर्स को क्या करना चाहिए
वैलिडेटर और नोड ऑपरेटर्स को पुष्टि करनी चाहिए कि वे Docker का उपयोग करते समय Teku 26.10.3 या बाद का संस्करण और Besu 26.10.2 या बाद का संस्करण चला रहे हैं, या बाइनरी का उपयोग करते समय समतुल्य पैच किए गए Java रनटाइम का उपयोग कर रहे हैं। HTTPS एंडपॉइंट्स के लिए कॉन्फ़िगरेशन की समीक्षा की जानी चाहिए; जहां ऐसे एंडपॉइंट्स आवश्यक हों, तो म्यूचुअल TLS या सर्टिफिकेट पिनिंग अतिरिक्त सुरक्षा प्रदान करते हैं। Java 26 पर अभी भी काम कर रहे ऑपरेटर्स को समर्थित रिलीज़ पर स्थानांतरित होना चाहिए। ट्रस्ट-स्टोर अपडेट्स के बाद भी, अप्रत्याशित फी-प्राप्तकर्ता पतों के लिए प्रस्तावित ब्लॉक्स की निगरानी एक कम लागत वाली पता लगाने की विधि है। क्योंकि नीचे की कुंजियां खोज से पहले लंबे समय तक पुनः प्राप्त करने योग्य थीं, इतिहास के संपर्कों और सर्टिफिकेट स्वीकृति लॉग्स की एक-बार की समीक्षा अतिरिक्त सुरक्षा प्रदान कर सकती है, हालांकि कोई दुरुपयोग की रिपोर्ट नहीं हुई है।
ये चरण अधिकांश संचालकों के लिए रूपांतरणकारी नहीं, बल्कि क्रमिक हैं। मेननेट वैलीडेटर्स में से अधिकांश कभी कमजोर सर्टिफिकेट श्रृंखलाओं से संपर्क नहीं करते थे, इसलिए उन्हें इस घटना केवल एक याददाश्त के रूप में अनुभव हुआ कि कंटेनर इमेजेस और जावा रनटाइम्स को अपडेटेड रखें। जो बाहरी सेवाओं पर निर्भर हैं, उनके लिए पैच एक विशिष्ट और पहले कम सराही गई राह को बंद करते हैं। उपरि-स्तरीय सर्टिफिकेट और रनटाइम सलाहों के प्रति जागरूकता बनाए रखने से भविष्य में समान बाहरी विफलताओं के कारण ऐसे ही खुले समय की संभावना कम होगी। टेकू और बेसू टीमों द्वारा समन्वित कार्रवाई से तुरंत समाधान के साथ-साथ ईथेरियम क्लाइंट सॉफ़्टवेयर के साथ संघर्ष करने वाली अगली बाहरी क्रिप्टोग्राफिक घटना के प्रबंधन का मॉडल प्रदान किया गया है।
अक्सर पूछे जाने वाले प्रश्न
eMudhra प्रमाणपत्रों में क्या वास्तव में गलत था?
2025 के की समारोह के दौरान eMudhra द्वारा संचालित आठ मध्यवर्ती प्रमाणन प्राधिकरणों की निजी कुंजियाँ अपर्याप्त यादृच्छिकता के साथ उत्पन्न की गईं। ये कुंजियाँ सार्वजनिक प्रमाणपत्रों से पुनः प्राप्त की जा सकती थीं, जिससे कोई भी व्यक्ति जिन्हें ये प्राप्त हो गए, धोखेबाज़ प्रमाणपत्र जारी कर सकता था जिन्हें सॉफ़्टवेयर अभी भी इन प्राधिकरणों को स्वीकार करने के लिए विश्वास करता था। इन मध्यवर्ती में से छह का उपयोग TLS के लिए और दो का उपयोग कोड साइनिंग के लिए किया गया था। eMudhra ने 17 अक्टूबर, 2026 को खोज के बाद उन्हें रद्द कर दिया, और बाद में प्रमुख प्लेटफ़ॉर्मों ने संबंधित सामग्री को ब्लॉक कर दिया।
क्या इस दोष के कारण किसी वैलिडेटर ने वास्तव में ETH रिवॉर्ड खोए?
कोई पुष्टि शोषण या पुरस्कारों की हानि रिपोर्ट नहीं की गई है। क्लाइंट सलाह और समकालीन कवरेज में यह बताया गया है कि कोई हमले नहीं देखे गए। आवश्यक परिस्थितियों का संयोजन, एक अपैच्ड Java रनटाइम और एक वैधता वाली बाहरी सेवा के साथ सक्रिय HTTPS कनेक्शन, वास्तविक हमले के क्षेत्र को सीमित करता है, और पैच किए गए Docker इमेज का त्वरित जारी करना अतिरिक्त जोखिम को और कम करता है।
डिफ़ॉल्ट ईथेरियम मेननेट नोड प्रभावित हैं?
जिन डिफ़ॉल्ट मेननेट Teku कॉन्फ़िगरेशन में कोई HTTPS URL नहीं है, वे प्रभावित नहीं होते और इनके लिए कोई कार्रवाई की आवश्यकता नहीं है। इसी सिद्धांत को समान Besu सेटअप पर भी लागू किया जाता है। जो ऑपरेटर बीकन नोड, बाहरी साइनर, बिल्डर या समान सेवाओं के लिए जानबूझकर रिमोट HTTPS एंडपॉइंट कॉन्फ़िगर करते हैं, उन्हीं की सुरक्षा खतरे में है।
जावा रनटाइम्स क्यों अभी भी वुल्नरेबल रहे, जबकि सर्टिफिकेट्स को रिवॉक कर दिया गया था?
जावा डिफ़ॉल्ट रूप से प्रमाणपत्र रद्दकरण की स्थिति की जांच नहीं करता है। यहां तक कि जब इंटरमीडिएट्स को ब्राउज़र और ऑपरेटिंग सिस्टम द्वारा रद्द और ब्लॉक कर दिया गया, तब भी किसी भी जावा स्थापना जिसमें अभी भी अपने ट्रस्ट स्टोर में संबंधित रूट्स मौजूद थे, उनके साथ जुड़ने वाले प्रमाणपत्रों को स्वीकार करती रही। इसलिए, पुराने रनटाइम्स के साथ आने वाले क्लाइंट डॉकर इमेजेज को स्पष्ट रूप से रूट हटाने की आवश्यकता थी।
डॉकर इमेज का उपयोग करने वाले ऑपरेटर्स को क्या करना चाहिए?
Teku संस्करण 26.10.3 या उससे अधिक और Besu संस्करण 26.10.2 या उससे अधिक को खींचें और चलाएं। ये छवियाँ संक्रमित जड़ों पर विश्वास नहीं करती हैं। केवल होस्ट सिस्टम को अपडेट करने से मौजूदा कंटेनर के भीतर रनटाइम अपडेट नहीं होता; एक नया छवि आवश्यक है।
ग्राहकों को स्वतंत्र बाइनरी के रूप में चलाने वाले ऑपरेटर्स के बारे में क्या?
उन ऑपरेटरों को होस्ट Java इंस्टॉलेशन को अपडेट या पुनः कॉन्फ़िगर करना चाहिए ताकि इसमें OpenJDK के ठीक किए गए बदलाव शामिल हों और प्रभावित जड़ें हटा दी जाएं। Java 26 का समर्थन समाप्त हो चुका है और इसे पैच किए गए बिल्ड की प्राप्ति नहीं होगी; Java 25 में स्थानांतरण की सिफारिश की जाती है। क्लाइंट सॉफ्टवेयर अपडेट स्वयं होस्ट ट्रस्ट स्टोर को नहीं बदलते हैं।
उत्तरदायित्व से मुक्ति: यह सामान्य बाजार सूचना, जो संभवतः तीसरे पक्ष, वाणिज्यिक या प्रायोजित स्रोतों से ली गई है, केवल संदर्भ और शैक्षिक उद्देश्यों के लिए प्रदान की गई है और यह वित्तीय या निवेश सलाह, एक ऑफर, आमंत्रण या गारंटी नहीं है। हम इसकी सटीकता, पूर्णता, विश्वसनीयता और किसी भी परिणामस्वरूप हुए नुकसान के लिए उत्तरदायित्व से मुक्त हैं। निवेश/व्यापार जोखिम भरा है; अतीत का प्रदर्शन भविष्य के परिणामों की गारंटी नहीं देता। उपयोगकर्ताओं को अनुसंधान करना चाहिए, सावधानी से मूल्यांकन करना चाहिए और पूरा जिम्मेदारी लेना चाहिए। अधिक विवरण के लिए, कृपया KuCoin के उपयोग के नियम और जोखिम अवगति को संदर्भित करें।
डिस्क्लेमर: इस पेज का भाषांतर आपकी सुविधा के लिए AI तकनीक का इस्तेमाल करके किया गया है। सबसे सटीक जानकारी के लिए, मूल अंग्रेजी वर्जन देखें।