Cisco ईमेल गेटवे की खामी हमले में—एक ईमेल से root अधिकार संभव
Cisco Secure Email Gateway की गंभीर खामी CVE-2026-76461 का सक्रिय हमलों में दुरुपयोग हो रहा है। Cisco की सुरक्षा सलाह 14 सितंबर 2026 को प्रकाशित और 17 सितंबर को अद्यतन हुई; इसके अनुसार, प्रभावित गेटवे से गुजारा गया विशेष रूप से तैयार ईमेल बिना प्रमाणीकरण दुर्भावनापूर्ण SQL कथन चला सकता है और अंततः मूल प्रचालन तंत्र पर root अधिकारों के साथ आदेश निष्पादित करा सकता है।
15 सितंबर की Center for Internet Security की चेतावनी भी सक्रिय दुरुपयोग और पूरे उपकरण के समझौते के जोखिम की पुष्टि करती है। भारतीय उद्यम प्रशासकों के लिए इसका अर्थ है कि प्रभावित संस्करण को तुरंत सुधारयुक्त संस्करण पर ले जाना आवश्यक है, लेकिन संभावित शोषण के संकेत मिलने पर केवल अद्यतन को पर्याप्त उपचार नहीं माना जा सकता।
एक तैयार ईमेल से हमला कैसे शुरू होता है
खामी Cisco AsyncOS की ईमेल-पार्सिंग प्रक्रिया में इनपुट की अपर्याप्त जाँच के कारण पैदा होती है। हमलावर को प्रशासनिक खाता, स्थानीय पहुँच या उपयोगकर्ता की सहभागिता की आवश्यकता नहीं होती: प्रभावित उपकरण से दुर्भावनापूर्ण SQL कथन वाला संदेश गुजरना ही आक्रमण का रास्ता खोल सकता है। सफल शोषण मनमाने SQL कथनों से आगे बढ़कर अंतर्निहित प्रचालन तंत्र पर root स्तर का आदेश निष्पादन करा सकता है।
यह जोखिम किसी खुले प्रबंधन-पोर्ट या वैकल्पिक सुविधा पर निर्भर नहीं है। इसलिए केवल इंटरनेट से दिखाई देने वाले प्रशासनिक अंतरफलक की जाँच करके उपकरण को सुरक्षित मानना गलत होगा; सामान्य ईमेल-प्रसंस्करण पथ स्वयं हमले की सतह है।
प्रभावित उपकरण और पहले सुरक्षित संस्करण
खामी Cisco Secure Email Gateway के भौतिक और आभासी दोनों उपकरणों को उनकी संरचना से स्वतंत्र रूप से प्रभावित करती है। Secure Email and Web Manager तथा Secure Web Appliance इस विशिष्ट खामी से प्रभावित उत्पादों में शामिल नहीं हैं। प्रशासकों को समान उत्पाद-परिवार के नाम के आधार पर अनुमान लगाने के बजाय हर उपकरण का वास्तविक उत्पाद और AsyncOS संस्करण दर्ज करना चाहिए।
प्रत्येक प्रभावित शाखा का पहला सुधारयुक्त संस्करण अलग है:
- 15.5 तथा उससे पुराने संस्करणों के लिए 15.5.5-014;
- 16.0 शाखा के लिए 16.0.4-302;
- 16.5 शाखा के लिए 16.5.0-780।
16.5 से पुरानी शाखाओं के ग्राहकों के लिए अनुशंसित स्थानांतरण 16.5.0-780 है। अद्यतन पूरा होने पर उपकरण पुनः आरंभ होता है, इसलिए उपलब्धता और मेल-प्रवाह की योजना भी रखनी होगी। Cisco Secure Email Cloud के सभी उपकरण 16.5.0-780 पर उन्नत किए जा चुके हैं; संभावित समझौते के संकेत वाले क्लाउड उपकरणों के ग्राहकों से कंपनी ने सीधे संपर्क किया है।
तत्काल कार्रवाई का चार चरणों वाला क्रम
- हर तैनाती पहचानें: सभी भौतिक उपकरणों, आभासी मशीनों और क्लस्टर सदस्यों की सूची बनाकर उनका AsyncOS संस्करण दर्ज करें। केवल मुख्य नोड या इंटरनेट से खुला प्रबंधन-अंतरफलक जाँचना पर्याप्त नहीं है।
- सुधारयुक्त संस्करण स्थापित करें: संबंधित शाखा का पहला सुरक्षित संस्करण या उससे नया समर्थित निर्माण चुनें। इस खामी को रोकने वाला कोई वैकल्पिक उपाय उपलब्ध नहीं है; नेटवर्क नियंत्रण अतिरिक्त सुरक्षा दे सकते हैं, पर विक्रेता के सुधार का स्थान नहीं लेते।
- शोषण के संकेत तलाशें: प्रत्येक उपकरण के mail_logs में संदिग्ध SQL कथनों की समीक्षा करें। विशेष रूप से COPY के साथ TO PROGRAM जैसे प्रतिरूप की उपस्थिति दुर्भावनापूर्ण गतिविधि का संकेत हो सकती है। क्लस्टर में हर सदस्य के लॉग अलग-अलग जाँचें।
- अद्यतन या पुनर्निर्माण चुनें: शोषण का संदेह न हो तो सुरक्षित संस्करण पर तत्काल उन्नयन प्राथमिक कार्रवाई है। संकेत मिलने, बाहरी गतिविधि दिखने या जाँच के लिए पर्याप्त अभिलेख उपलब्ध न होने पर साक्ष्य सुरक्षित करके पुनर्निर्माण और प्रवेश-प्रमाण नवीनीकरण का रास्ता अपनाना अधिक सुरक्षित है।
उपकरण पर root अधिकार पाने वाला हमलावर स्थानीय प्रमाण या समझौते के संकेत मिटा अथवा छिपा सकता है। इस कारण जाँच को उसी उपकरण के लॉग तक सीमित नहीं रखना चाहिए: बाहरी नेटवर्क और फायरवॉल अभिलेखों में उपकरण से अनपेक्षित बाहरी अपलोड, दुर्भावनापूर्ण पतों से डाउनलोड तथा असामान्य संपर्क भी खोजे जाने चाहिए।
समझौता मिलने पर केवल अद्यतन पर्याप्त क्यों नहीं
आभासी उपकरण पर शोषण का संदेह हो तो नई मशीन बनाने से पहले न्यायिक-जाँच के लिए आवश्यक सामग्री सुरक्षित करनी चाहिए, क्योंकि नया उदाहरण तैनात करने पर पुरानी संरचना और लॉग नष्ट हो सकते हैं। इसके बाद सुधारयुक्त संस्करण वाली नई आभासी मशीन तैनात करना, उत्पाद की संरचना दोबारा बनाना, उपकरण पर मौजूद प्रवेश-प्रमाण और क्रिप्टोग्राफिक सामग्री नवीनीकृत करना तथा असामान्य व्यवहार की निगरानी जारी रखना आवश्यक है।
भौतिक उपकरण में संभावित शोषण मिलने पर Cisco Technical Assistance Center से सहायता लेने की प्रक्रिया निर्धारित है। क्लस्टर में जोखिम एक उपकरण तक सीमित नहीं रहता: सदस्यों के बीच प्रमाणीकरण में प्रयुक्त निजी SSH कुंजियाँ समझौता किए गए उपकरण से प्राप्त की जा सकती हैं। एक सदस्य के समझौते की पुष्टि होने पर संबंधित क्लस्टर के प्रत्येक सदस्य को सुरक्षित अवस्था में बहाल करना चाहिए।
फिलहाल सुधारयुक्त निर्माण उपलब्ध हैं और कोई वैकल्पिक समाधान नहीं है, लेकिन सार्वजनिक सलाह हमलावरों की पहचान, लक्षित देशों या प्रभावित संगठनों की संख्या नहीं बताती। इसलिए भारतीय प्रशासकों को पीड़ितों की सूची की प्रतीक्षा करने के बजाय उत्पाद, संस्करण और स्थानीय समझौता-संकेतों के आधार पर निर्णय लेना होगा: साफ जाँच वाले प्रभावित उपकरण को तुरंत उन्नत करें; संदिग्ध गतिविधि या अधूरे अभिलेख मिलने पर साक्ष्य-संग्रह, पुनर्निर्माण और प्रवेश-प्रमाण नवीनीकरण को प्राथमिकता दें।
यह भी पढ़ें:
हमारे न्यूज़लेटर की सदस्यता लें
Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।