SolarWinds کی دو RCE خامیاں، حملہ آور کو login بھی درکار نہیں

SolarWinds نے 22 ستمبر 2026 کو Observability Self-Hosted کی CVE-2026-28324 کی سکیورٹی اطلاع شائع کی، جس کے مطابق غیر محفوظ، غیر معمولی configuration والی تنصیب میں حملہ آور لاگ اِن کیے بغیر دور سے کوڈ چلا سکتا ہے؛ CVSS اسکور 9.8 ہے، ورژن 2026.2.2 اور اس سے پرانے متاثرہ فہرست میں ہیں، اور اصلاحی ورژن 2026.2.3 ہے۔ صرف پرانا ورژن موجود ہونا یہ ثابت نہیں کرتا کہ تنصیب میں اس خامی کے استعمال کی پوری شرط بھی موجود ہے۔

اسی روز شائع ہونے والی دوسری خامی، CVE-2026-28325، کی اطلاع مخصوص communication mode والی تنصیبات میں بلا تصدیق ریموٹ کوڈ چلنے کا خطرہ بیان کرتی ہے؛ اس کا CVSS اسکور 8.8 ہے، متاثرہ ورژن 2026.2.2 اور اس سے پرانے ہیں، اور اصلاح 2026.2.3 میں شامل ہے۔ 24 ستمبر کی SecurityWeek کی رپورٹ نے دونوں اصلاحات اور ان کی مختلف configuration شرائط کا ذکر کیا۔ منتظم کو اس لیے نصب شدہ ورژن کے ساتھ ہر تنصیب کی اصل ترتیبات بھی دیکھنی ہوں گی۔

کون سی تنصیب کس خامی سے متاثر ہو سکتی ہے؟

دونوں مسائل ایک ہی self-hosted پروڈکٹ میں ہیں، مگر ایک ہی ترتیب پر منحصر نہیں۔ درج ذیل تقابل میں متاثرہ ورژن کا مطلب وہ ورژن ہے جس میں اصلاح موجود نہیں؛ قابلِ استعمال ہونے کے لیے متعلقہ configuration شرط بھی پوری ہونا ضروری ہے۔ یہی فرق اس سوال کا جواب دیتا ہے کہ پرانی تنصیب دیکھتے ہی دونوں خامیوں کو یکساں کیوں نہیں سمجھنا چاہیے۔

• CVE-2026-28324: وجہ ڈیٹا کی سالمیت کی ناکافی جانچ ہے۔ شرط ایسی غیر معمولی اور غیر محفوظ configuration ہے جس میں یہ کمزوری قابلِ استعمال ہو۔ CVSS: 9.8، یعنی critical۔ متاثرہ ورژن: 2026.2.2 اور اس سے پرانے۔ مطلوبہ اصلاح: 2026.2.3۔
• CVE-2026-28325: وجہ ناقابلِ اعتماد ڈیٹا کی deserialization ہے۔ شرط ایپلی کیشن کا مخصوص communication mode میں ترتیب دیا جانا ہے۔ CVSS: 8.8، یعنی high۔ متاثرہ ورژن: 2026.2.2 اور اس سے پرانے۔ مطلوبہ اصلاح: 2026.2.3۔

پہلی خامی کی شرط کو محض یہ کہہ کر رد نہیں کیا جا سکتا کہ ادارہ عموماً محفوظ ترتیبات استعمال کرتا ہے۔ کسی پرانی تعیناتی میں بعد کی تبدیلی، الگ ماحول یا استثنائی ترتیب موجود ہو سکتی ہے؛ یہ ممکنہ صورتیں ہیں، کسی مخصوص ادارے کے بارے میں دعویٰ نہیں۔ دوسری خامی کے لیے بھی communication mode کی شناخت درکار ہے۔ شائع شدہ مختصر خلاصے اس mode کو ایسا واضح نام نہیں دیتے جسے ہر مقامی تنصیب کی ترتیب سے بلا تحقیق ملایا جا سکے۔

لاگ اِن کے بغیر RCE کا مطلب کیا ہے؟

بلا تصدیق ہونے کا مطلب یہ ہے کہ حملہ آور کو متعلقہ راستے پر حملے سے پہلے صارف اکاؤنٹ کی ضرورت نہیں، بشرطیکہ تنصیب کی باقی شرائط پوری ہوں اور وہ اس تک مطلوبہ نیٹ ورک راستے سے پہنچ سکے۔ RCE صرف معلومات پڑھ لینے کا مسئلہ نہیں: اس کا ممکنہ نتیجہ متاثرہ میزبان پر حملہ آور کا کوڈ چلنا ہے۔ اسی لیے configuration کی شرط کو سنجیدگی سے جانچنا ضروری ہے، خواہ سافٹ ویئر براہِ راست عوامی انٹرنیٹ پر دستیاب نہ ہو۔

دونوں CVSS ویکٹر نیٹ ورک کی رسائی کے معاملے میں مختلف ہیں۔ CVE-2026-28324 میں نیٹ ورک سے حملہ درج ہے، جبکہ CVE-2026-28325 میں adjacent network درج ہے۔ دوسری درجہ بندی کو ہر جگہ، کسی بھی فاصلے سے انٹرنیٹ کے ذریعے حملے کے دعوے میں بدلنا درست نہیں؛ اس کے لیے قریبی یا منطقی طور پر متصل نیٹ ورک تک رسائی درکار ہو سکتی ہے۔ تاہم اندرونی نیٹ ورک کی رسائی بھی حقیقی رسائی ہے، اس لیے اسے محض بیرونی انٹرنیٹ سے الگ ہونے کی بنیاد پر نظرانداز نہیں کیا جا سکتا۔

CVSS اسکور شدت کا اشارہ دیتا ہے، کسی ادارے کی مخصوص تنصیب میں کامیاب حملے کا ثبوت نہیں۔ یہاں خطرے کا عملی اندازہ ورژن، ترتیب اور نیٹ ورک سے قابلِ رسائی ہونے کو ملا کر بنتا ہے۔ مثال کے طور پر پرانے ورژن کی ایسی تنصیب جس میں متعلقہ mode استعمال ہی نہیں ہوتا، دوسری خامی کے لیے اس تنصیب سے مختلف حالت ہے جس میں وہ mode فعال ہو۔ اس فرق سے جانچ کی ترجیح واضح ہوتی ہے، لیکن غیر اصلاح شدہ ورژن کو محفوظ قرار دینے کا جواز نہیں ملتا۔

منتظم ورژن اور configuration کیسے ملائے؟

جانچ کی ابتدا Observability Self-Hosted کی تمام موجودہ تنصیبات کی فہرست سے ہونی چاہیے۔ مرکزی production ماحول کے علاوہ اگر الگ آزمائشی یا پرانی تعیناتیاں چل رہی ہیں تو ان کا نصب شدہ ورژن بھی الگ درج کریں۔ فہرست کا مقصد پہلے یہ معلوم کرنا ہے کہ کہاں اصلاح موجود ہے؛ configuration کی جانچ اس کے بعد بتاتی ہے کہ پرانے ورژن میں بیان کردہ استحصال کی شرط کہاں پوری ہو سکتی ہے۔

1. ہر تنصیب کا اصل ورژن معلوم کریں۔ 2026.2.3 سے پرانے ورژن کو دونوں خامیوں کی جانچ میں شامل رکھیں؛ صرف مرکزی نظام کا ورژن پوری تعیناتی کی نمائندگی نہیں کرتا۔
2. CVE-2026-28324 کے لیے مقامی configuration اور تعیناتی کی دستاویزات سے تصدیق کریں کہ غیر معمولی، غیر محفوظ ترتیب موجود ہے یا نہیں۔ ترتیب کا علم نہ ہونا، محفوظ ترتیب کی تصدیق کے برابر نہیں۔
3. CVE-2026-28325 کے لیے استعمال ہونے والا communication mode معلوم کریں۔ اگر mode واضح نہ ہو تو صرف اندازے کی بنیاد پر اس خامی کو غیر متعلقہ قرار نہ دیں۔
4. جہاں اصلاح غائب ہے، 2026.2.3 پر اپ ڈیٹ کریں اور بعد میں نصب شدہ ورژن کی تصدیق کریں۔ غیر واضح configuration والی تنصیب کی حیثیت کو جانچ مکمل ہونے تک غیر واضح ہی درج رکھیں۔

یہ فہرست دونوں خامیوں کے فرق کو برقرار رکھتی ہے: پرانا ورژن دونوں کی ممکنہ زد میں آنے کی پہلی شرط ہے، مگر استحصال کے راستے الگ ہیں۔ اگر کسی ادارے کے پاس communication mode یا غیر معمولی ترتیبات کا قابلِ اعتماد ریکارڈ نہیں تو صرف ورژن کی فہرست خطرے کی مکمل تصویر نہیں دے گی۔ اسی طرح صرف configuration کا جائزہ یہ نہیں بتاتا کہ اصلاحی release واقعی نصب ہو چکا ہے یا نہیں۔

صرف firewall rule مستقل حل کیوں نہیں؟

نیٹ ورک رسائی محدود کرنے والا firewall rule حملے کے ممکنہ راستے گھٹا سکتا ہے، مگر سافٹ ویئر کے اندر ناکافی integrity check یا غیر محفوظ deserialization کو درست نہیں کرتا۔ اگر بعد میں routing، مجاز میزبانوں یا نیٹ ورک پالیسی میں تبدیلی آئے تو پرانی، غیر اصلاح شدہ تنصیب دوبارہ قابلِ رسائی ہو سکتی ہے۔ یہ firewall کی افادیت سے انکار نہیں؛ اس کی حد بیان کرتا ہے۔

خاص طور پر adjacent network سے متعلق خامی کے لیے صرف بیرونی انٹرنیٹ ٹریفک روکنے کا قاعدہ پوری صورت حال نہیں سمیٹتا۔ منطقی طور پر متصل نظاموں سے آنے والی رسائی بھی دیکھنی پڑتی ہے۔ عارضی نیٹ ورک پابندی اپ ڈیٹ تک خطرہ کم کرنے میں مدد دے سکتی ہے، لیکن مستقل اصلاح وہ release ہے جس میں دونوں خامیوں کے لیے تبدیلی شامل ہے۔ اس لیے ورژن کی تصدیق اور configuration کی شناخت کو firewall کے قاعدے سے الگ کام سمجھنا چاہیے۔

ابھی معلوم صورت حال کیا ہے؟

دونوں خامیوں کے لیے اصلاحی release دستیاب ہے اور ان کی قابلِ استعمال ہونے کی شرائط مختلف ہیں۔ دستیاب عوامی معلومات میں ان خامیوں کے ذریعے عملی حملوں کی تصدیق پیش نہیں کی گئی؛ اس سے یہ نتیجہ نہیں نکلتا کہ ہر غیر اصلاح شدہ تنصیب خطرے سے باہر ہے۔ منتظم کے سامنے باقی سوال اپنی تنصیب سے متعلق ہے: کون سا ورژن چل رہا ہے، کون سی غیر معمولی ترتیب یا communication mode فعال ہے، اور اپ ڈیٹ کے بعد واقعی کون سا ورژن نصب ہوا ہے۔

یہ بھی پڑھیں:

• پاکستان میں Stripe اور PayPal نہیں، international payment قانونی طور پر کیسے لیں؟
• Thunderbird 155 میں high-risk خامیاں بند، صرف email کھولنا بڑا خطرہ نہیں
• ServiceNow کی تین critical خامیاں؛ self-hosted instances فوراً patch کریں