Cisco SD-WAN Manager पर सक्रिय हमला: आपके सिस्टम को पैच कौन करेगा, आप या आपका प्रदाता?

30 सितंबर 2026 को रियाद समय के अनुसार दोपहर 4 बजे Cisco ने Cisco Catalyst SD-WAN Manager में CVE-2026-76504 के लिए एक सुरक्षा एडवाइजरी प्रकाशित की। यह वह सिस्टम है जिसका इस्तेमाल कई शाखाओं वाली कंपनियां अपने पूरे शाखा नेटवर्क को एक ही स्क्रीन से चलाने के लिए करती हैं। गंभीरता स्कोर 10 में से 9.8 है, फायदा उठाने के लिए न किसी खाते की ज़रूरत है न पासवर्ड की, Cisco का कहना है कि उसे सितंबर के दौरान सक्रिय दुरुपयोग की जानकारी मिली, और कोई वैकल्पिक उपाय नहीं है। उसी दिन सऊदी अरब के राष्ट्रीय साइबर सुरक्षा प्राधिकरण (NCA) ने गंभीर स्तर की चेतावनी 2026-7889 जारी की और संगठनों से एडवाइजरी की समीक्षा करके अपडेट लागू करने को कहा।

मुख्य सवाल तकनीकी नहीं है: पैच कौन करेगा?

दो हफ्ते पहले हमने Cisco के एक दूसरे उपकरण में, जो पहचान और एक्सेस को नियंत्रित करता है, एक ऐसी खामी के बारे में लिखा था जिसका फायदा उठाया जा रहा था, और वहां कमजोरी प्रबंधन की बुनियादी बातें समझाई थीं। इस बार सबसे अहम सवाल तकनीकी नहीं है। हो सकता है कि आप अपना शाखा नेटवर्क खुद चलाते ही न हों: कोई दूरसंचार ऑपरेटर या IT कंपनी किसी प्रबंधित सेवा अनुबंध के तहत उसे आपके लिए चला रही हो। अगर ऐसा है, तो आज रात सिस्टम को अपग्रेड कौन करेगा, कौन जांचेगा कि अपग्रेड से पहले कोई अंदर तो नहीं आ गया, और अगर इनमें से कुछ भी न हो तो आपका अनुबंध क्या कहता है?

Cisco ने असल में क्या प्रकाशित किया

यह खबर कुछ ही घंटे पुरानी है, इसलिए ये तथ्य प्रेस रिपोर्टों से नहीं, बल्कि सीधे Cisco की एडवाइजरी और NCA की चेतावनी से लिए गए हैं:

• उत्पाद: Cisco Catalyst SD-WAN Manager, जिसे पहले vManage के नाम से जाना जाता था। एडवाइजरी के अनुसार यह कॉन्फ़िगरेशन चाहे जैसा भी हो, प्रभावित है।
• कारण: HTTP अनुरोधों में URI एन्कोडिंग को गलत तरीके से संभालने की वजह से एक खास तरह से बनाया गया अनुरोध उस प्रमाणीकरण नियम को दरकिनार कर सकता है जो API के एक विशेष एंडपॉइंट की सुरक्षा के लिए बना है, जिससे हमलावर admin उपयोगकर्ता के अधिकारों के साथ API तक पहुंच जाता है।
• पूर्व शर्त: कोई नहीं। एक दूरस्थ, बिना प्रमाणीकरण वाला हमलावर, और 9.8 का CVSS आधार स्कोर।
• स्थिति: सक्रिय रूप से दुरुपयोग हो रहा है। Cisco PSIRT का कहना है कि उसे सितंबर 2026 में दुरुपयोग की जानकारी मिली, और यह खामी Cisco Technical Assistance Center के एक सहायता मामले को सुलझाते समय मिली।
• वैकल्पिक उपाय: कोई नहीं। समाधान सुधारी गई रिलीज़ में अपग्रेड करना है।
• स्थानीय चेतावनी: NCA चेतावनी 2026-7889, दिनांक 30 सितंबर 2026। इसमें 14 लक्षित क्षेत्र सूचीबद्ध हैं, यानी व्यावहारिक रूप से सभी, वाणिज्य और निवेश, वित्त और अर्थव्यवस्था और स्वास्थ्य से लेकर शिक्षा, परिवहन और विनिर्माण तक।

एडवाइजरी के अनुसार सुधारी गई रिलीज़:

पहली पंक्ति पर ध्यान दें। जो कोई 20.9 से पुरानी रिलीज़ पर है, उसके सामने कोई छोटा अपडेट नहीं, बल्कि दूसरी रिलीज़ ट्रेन पर जाने का काम है। इसके लिए योजना चाहिए, और यह इंतज़ार नहीं कर सकता।

खास तौर पर यही सिस्टम क्यों

एक SD-WAN नेटवर्क शाखाओं, गोदामों और मुख्यालय को जो भी कनेक्शन उपलब्ध हों उनके ज़रिए जोड़ता है, और यह सब एक केंद्रीय सिस्टम से प्रबंधित होता है। नीतियां वहीं लिखी जाती हैं: कौन सा ट्रैफ़िक किस लिंक से जाएगा, कौन सी शाखा किस सिस्टम तक पहुंच सकती है, और हर साइट के राउटर पर कौन सी सेटिंग्स भेजी जाएंगी। केंद्र में किया गया एक बदलाव हर शाखा तक पहुंचता है। यही तो इसका पूरा मकसद है।

यही खूबी खतरा भी है। जो कोई admin अधिकारों के साथ इस सिस्टम के API तक पहुंच जाता है, उसके सामने एक उपकरण नहीं, बल्कि वह कंसोल होता है जो पूरे नेटवर्क के कॉन्फ़िगरेशन को संभालता है। किसी शाखा का पॉइंट ऑफ सेल, गोदाम तक का लिंक, और मुख्यालय के बाहर से लेखा प्रणाली तक पहुंच, ये सब उस नेटवर्क पर चल सकते हैं जिसे यह सिस्टम नियंत्रित करता है। रोज़मर्रा के प्रबंधन से यह चाहे जितना दूर लगे, इसकी जगह महत्वपूर्ण परिसंपत्तियों की सूची में सबसे ऊपर है।

Cisco का क्लाउड या आपका डेटा सेंटर? यही तय करता है कि कदम कौन उठाएगा

एडवाइजरी सिस्टम चलाने के दो तरीकों में अंतर करती है, और यह अंतर बहुत व्यावहारिक है:

• Cisco के क्लाउड में: एडवाइजरी कहती है कि यह खामी कॉन्फ़िगरेशन चाहे जो भी हो, SD-WAN Manager को प्रभावित करती है, और यह क्लाउड के दो मामलों का वर्णन करती है। Cisco Catalyst SD-WAN Cloud Hosted परिवेशों में Cisco ने एक्सेस सीमित करने वाला बचाव उपाय पहले ही लागू कर दिया है, लेकिन बचाव उपाय सुधार नहीं है, इसलिए ऊपर की तालिका में दी गई सुधारी गई रिलीज़ में अपग्रेड अब भी ज़रूरी है, और आपको पूछना चाहिए कि इसे कौन करेगा। Cisco SD-WAN Cloud (Cisco Managed) में रिलीज़ 20.15.605 खामी को ठीक करती है, Cisco का कहना है कि उपयोगकर्ता को कुछ करने की ज़रूरत नहीं है, और संस्करण सेवा इंटरफ़ेस में Help सुविधा के ज़रिए जांचा जा सकता है। केवल इस आखिरी मामले में अपग्रेड विक्रेता की ज़िम्मेदारी है। फिर भी आपका काम लिखित पुष्टि लेना और उससे पहले की अवधि के लॉग की समीक्षा करवाना है।
• ऑन-प्रिमाइसेस, आपकी साइट पर या आपके प्रदाता के डेटा सेंटर में: यहां कोई भी आपके लिए सिस्टम को अपग्रेड नहीं करेगा, जब तक कि अनुबंध में ऐसा न लिखा हो। अपग्रेड होने तक Cisco जिस बचाव उपाय का वर्णन करता है, वह है इंटरनेट जैसे असुरक्षित नेटवर्क से सिस्टम तक पहुंच को सीमित करना, और SD-WAN नियंत्रण घटकों को फ़ायरवॉल जैसे फ़िल्टरिंग उपकरण के पीछे सुरक्षित रखना।

तो पहला सवाल यह नहीं है कि आप Cisco इस्तेमाल करते हैं या नहीं। सवाल यह है कि आपका नेटवर्क प्रबंधन सिस्टम कहां चलता है और उसे अपग्रेड करने की ज़िम्मेदारी किसकी है। अगर इसका जवाब सिर्फ प्रदाता को पता है, तो यही पहली कमी है जिसे दूर करना है, और यह तकनीकी कमी नहीं है।

अपग्रेड यह नहीं बताता कि कोई पहले ही अंदर आ गया था या नहीं

Cisco को सितंबर के दौरान दुरुपयोग की जानकारी मिली और उसने महीने के आखिरी दिन सुधार प्रकाशित किया। दूसरे शब्दों में, लागू करने के लिए कोई अपडेट मौजूद होने से पहले ही इस खामी का फायदा उठाया जा रहा था। आज रात अपग्रेड करने से दरवाज़ा बंद हो जाता है। लेकिन यह नहीं बताता कि कोई पहले ही उस दरवाज़े से होकर गुज़र चुका है और पीछे कोई खाता या कॉन्फ़िगरेशन में बदलाव छोड़ गया है।

इसीलिए Cisco ने ऐसे संकेतक प्रकाशित किए हैं जिन्हें आपकी IT टीम या प्रदाता को सिस्टम के दो विशेष लॉग, serviceproxy-access.log और vmanage-server.log में खोजना चाहिए:

• अज्ञात या अनधिकृत IP पतों से j_security_check पर आने वाले अनुरोध।
• अनुरोध के पाथ में URI-एन्कोड किया गया कोई भी अक्षर, जैसे %6a_security_check, जहां %6a एन्कोड किया गया अक्षर j है। एक्सप्लॉइट इसी तरह प्रमाणीकरण नियम से बच निकलता है। Cisco ज़ोर देकर कहता है कि %6a केवल एक उदाहरण है: अनुरोध में किसी भी एक अक्षर की एन्कोडिंग का इस्तेमाल किया जा सकता है, इसलिए टीम को सिर्फ %6a नहीं, बल्कि j_security_check के हर एन्कोड किए गए रूप को खोजना चाहिए।
• खास तौर पर vmanage-server.log में: अज्ञात पतों से उन यूज़रनेम के लिए किए गए j_security_check अनुरोध जो viptela-reserved- से शुरू होते हैं। ये सिस्टम के अंतर्निहित सेवा खाते हैं, इसलिए लॉग में इस नाम का दिखना अपने आप में सेंधमारी का संकेत नहीं है। मायने रखता है अज्ञात स्रोत।

Cisco यह भी चेतावनी देता है कि ये संकेतक कभी-कभी सामान्य संचालन के दौरान भी दिख सकते हैं, इसलिए कोई निष्कर्ष निकालने से पहले इनकी तुलना नेटवर्क की सामान्य गतिविधि से करनी चाहिए।

यही सबक इस हफ्ते Citrix NetScaler की दो गंभीर खामियों के साथ भी सामने आया, जिन्हें अमेरिका की साइबर सुरक्षा और अवसंरचना सुरक्षा एजेंसी (CISA) ने 27 सितंबर को अपनी ज्ञात शोषित कमजोरियों (Known Exploited Vulnerabilities) की सूची में जोड़ा। CISA ने कहा कि खतरा पैदा करने वाले तत्व दुनिया भर में इनका सक्रिय रूप से फायदा उठा रहे हैं, संगठनों को जहां संभव हो पैच करने से पहले सेंधमारी के संकेतों की जांच करने के लिए प्रोत्साहित किया, और कहा कि सेंधमारी का संदेह रखने वाले किसी भी संगठन को अपडेट लागू करने से पहले फ़ॉरेंसिक सबूत सुरक्षित रखने चाहिए, क्योंकि अपडेट जो हुआ उसके निशान मिटा सकते हैं। यह नियम यहां भी लागू होता है: जांचें, लॉग की एक प्रति रखें, फिर अपग्रेड करें, लेकिन जांच को अपग्रेड को कई दिनों तक टालने का बहाना न बनने दें।

अगर आपका नेटवर्क एक प्रबंधित सेवा है: आपका अनुबंध क्या कहता है?

NCA के आवश्यक साइबर सुरक्षा नियंत्रण (Essential Cybersecurity Controls), 2024 संस्करण, सरकारी संस्थाओं और उनकी संबद्ध कंपनियों पर, और उन निजी क्षेत्र की संस्थाओं पर बाध्यकारी हैं जो महत्वपूर्ण राष्ट्रीय अवसंरचना की मालिक हैं, उसे संचालित करती हैं या होस्ट करती हैं। NCA राज्य के बाकी सभी संगठनों को इन्हें अपनाने के लिए दृढ़ता से प्रोत्साहित करता है। भले ही आपकी कंपनी इनसे बंधी न हो, ये इस बात का सबसे स्पष्ट स्थानीय संदर्भ हैं कि आपकी तकनीक का कोई हिस्सा चलाने वाले किसी भी प्रदाता के अनुबंध में क्या होना चाहिए:

• उन तीसरे पक्षों के साथ अनुबंधों में जिनमें गड़बड़ी होने पर आपका डेटा या सेवाएं प्रभावित हो सकती हैं, सेवा स्तर समझौतों सहित: गोपनीयता और सेवा समाप्त होने पर आपके डेटा को सुरक्षित रूप से हटाना, साइबर सुरक्षा घटना होने पर संचार की प्रक्रियाएं, और तीसरे पक्ष पर आपकी साइबर सुरक्षा आवश्यकताओं और नीतियों को लागू करने का दायित्व (नियंत्रण 4-1-2)।
• खास तौर पर IT आउटसोर्सिंग और प्रबंधित सेवा प्रदाताओं के साथ अनुबंधों में: हस्ताक्षर से पहले साइबर सुरक्षा जोखिम मूल्यांकन, जिसमें जोखिम कम करने वाले नियंत्रणों की पुष्टि हो, और निगरानी व संचालन के लिए रिमोट एक्सेस का उपयोग करने वाले साइबर सुरक्षा प्रबंधित सेवा केंद्र पूरी तरह राज्य के भीतर स्थित होने चाहिए (नियंत्रण 4-1-3)।
• कमजोरी प्रबंधन में: कमजोरियों को गंभीरता के आधार पर वर्गीकृत करना और उसी वर्गीकरण के अनुसार उन्हें ठीक करना, नई कमजोरियों की खबरों के लिए विश्वसनीय स्रोतों की सदस्यता लेना, और अपडेट लागू करने से पहले उन्हें गैर-उत्पादन परिवेश में सत्यापित करना (नियंत्रण 2-10-3)।

ध्यान दें कि कमजोरी प्रबंधन के नियंत्रण क्या नहीं कहते: वे किसी गंभीर अपडेट को लागू करने की कोई समय सीमा तय नहीं करते। वह संख्या आपके अपने अनुबंध में लिखी होनी चाहिए। वरना प्रदाता तब पैच करेगा जब वह कर सके, न कि तब जब आपको ज़रूरत हो।

आज ही अपने प्रदाता को भेजने लायक संदेश

ये सवाल पूछने के लिए आपको तकनीकी होने की ज़रूरत नहीं है, और न ही किसी बैठक का इंतज़ार करने की। जवाब लिखित में मांगें:

• क्या हमारा नेटवर्क Cisco Catalyst SD-WAN Manager पर चलता है? और यह कहां चलता है: Cisco के क्लाउड में, हमारी साइट पर, या आपके डेटा सेंटर में?
• यह किस रिलीज़ पर है, और इसे सुधारी गई रिलीज़ में कब अपग्रेड किया जाएगा, तारीख और समय के साथ?
• क्या प्रबंधन इंटरफ़ेस इस समय इंटरनेट से पहुंच में है? अगर हां, तो क्या आपने अपग्रेड तक पहुंच सीमित कर दी है?
• क्या आपने Cisco द्वारा बताए गए दोनों लॉग में प्रकाशित संकेतकों की जांच की है, और अपग्रेड से पहले उनकी एक प्रति रखी है? आपको क्या मिला?
• इस चेतावनी के बारे में हमें सबसे पहले किसने बताया: आपने, या हमारे द्वारा पढ़ी गई किसी खबर ने? और अगली बार हमें सूचित करने की तय प्रक्रिया क्या है?

आखिरी सवाल सबसे ज़्यादा मायने रखता है। अगर आपको चेतावनी के बारे में अपने प्रदाता से नहीं, बल्कि किसी लेख से पता चला, तो समस्या इस एक खामी से बड़ी है।

Origami का नज़रिया

हम व्यावसायिक सिस्टम बनाते हैं। हम नेटवर्क उपकरण न बेचते हैं, न चलाते हैं। लेकिन कई शाखाओं वाले किसी ग्राहक के लिए हम जो भी सिस्टम बनाते हैं, वह एक ऐसे नेटवर्क पर चलता है जिसे हमने डिज़ाइन नहीं किया: शाखा का पॉइंट ऑफ सेल सर्वर को डेटा भेजता है, गोदाम स्टॉक अपडेट करता है, ई-इनवॉइस प्लेटफ़ॉर्म पर जाता है। और नेटवर्क को पैच कौन करता है, इस सवाल का आम जवाब होता है: प्रदाता सब संभाल लेता है। यह तसल्ली देने वाला जवाब है, और यह कोई जवाब नहीं है।

किसी सऊदी व्यवसाय मालिक के लिए हम इस खामी को इस बात की याद दिलाने वाला मानते हैं कि आउटसोर्सिंग काम को आगे बढ़ा देती है, ज़िम्मेदारी को नहीं। कई कंपनियों के लिए प्रबंधित सेवा सही चुनाव है, बशर्ते अनुबंध में तीन मापने योग्य बातें हों: गंभीर अपडेट लागू करने की तय समय सीमा, आपके सिस्टम को प्रभावित करने वाली हर चेतावनी की लिखित सूचना, और हर घटना के बाद एक रिपोर्ट जो बताए कि क्या जांचा गया और क्या मिला। इन प्रावधानों से किसी अच्छे प्रदाता का कुछ नहीं बिगड़ता, और ये किसी कमज़ोर प्रदाता को किसी कमजोरी से पहले ही उजागर कर देते हैं।

निष्कर्ष

• अगर आप Cisco Catalyst SD-WAN Manager को अपनी साइट पर या अपने प्रदाता के यहां चलाते हैं, तो सुधारी गई रिलीज़ में अपग्रेड करना ज़रूरी और तत्काल काम है, कोई नियोजित काम नहीं, और 20.9 से पुरानी रिलीज़ के लिए सुधारी गई ट्रेन पर जाना होगा।
• अपग्रेड होने तक: एडवाइजरी में बताए अनुसार इंटरनेट से सिस्टम तक पहुंच रोकें और नियंत्रण घटकों को फ़ायरवॉल के पीछे रखें।
• अपग्रेड से पहले दोनों लॉग जांचें और उनकी एक प्रति रखें, क्योंकि सुधार प्रकाशित होने से पहले ही दुरुपयोग शुरू हो गया था।
• अगर नेटवर्क एक प्रबंधित सेवा है, तो ऊपर दिए सवाल आज ही भेजें, फिर अगले नवीनीकरण पर अनुबंध में गंभीर अपडेट की समय सीमा और सूचना प्रक्रिया जोड़ें।

स्रोत

• Cisco: CVE-2026-76504 के लिए सुरक्षा एडवाइजरी cisco-sa-sdwan-webauth-xr8beuuU (30 सितंबर 2026)
• राष्ट्रीय साइबर सुरक्षा प्राधिकरण (NCA): Cisco Alert 2026-7889 (30 सितंबर 2026)
• राष्ट्रीय साइबर सुरक्षा प्राधिकरण (NCA): आवश्यक साइबर सुरक्षा नियंत्रण, 2024 संस्करण
• CISA: Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway (सितंबर 2026)