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 سے پرانیکسی درست کی گئی ریلیز پر منتقل ہوں
20.920.9.10.1
20.1220.12.8.2
20.1520.15.6.1
20.1820.18.4.1
26.126.1.2.1
26.226.2.1

پہلی قطار پر غور کریں۔ جو بھی 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 سے پرانی ریلیزوں کو درست کی گئی ٹرین پر منتقل ہونا ہوگا۔
  • اپ گریڈ ہونے تک: ایڈوائزری کے مطابق انٹرنیٹ سے سسٹم تک رسائی بند کریں اور کنٹرول اجزاء کو فائر وال کے پیچھے رکھیں۔
  • اپ گریڈ سے پہلے دونوں لاگز جانچیں اور ان کی نقل محفوظ کریں، کیونکہ حل شائع ہونے سے پہلے ہی فائدہ اٹھانا شروع ہو چکا تھا۔
  • اگر نیٹ ورک ایک منظم سروس ہے تو اوپر دیے گئے سوالات آج ہی بھیجیں، پھر اگلی تجدید پر معاہدے میں نازک اپ ڈیٹس کی آخری تاریخ اور اطلاع کا طریقۂ کار شامل کریں۔

ذرائع