GitLab کی CVSS 10 خامی: self-managed سرور فوراً اپ ڈیٹ کریں

GitLab نے 12 اکتوبر 2026 کی اہم پیچ ریلیز میں CVE-2026-97229 کے لیے درست شدہ ورژن 19.2.8، 19.3.5 اور 19.4.2 جاری کیے۔ GitLab Community Edition اور Enterprise Edition کی اس خامی کا CVSS اسکور 10.0 ہے؛ بعض حالات میں CI/CD ترتیب کی خاص طور پر تیار کردہ ریگولر ایکسپریشن بغیر تصدیق کے سرور پر من مانا کوڈ چلانے دے سکتی تھی۔ کمپنی نے اپنی GitLab تنصیبات چلانے والوں کو فوری اپ گریڈ کی سفارش کی ہے۔

GitLab.com پر درست شدہ ورژن چل رہا ہے اور GitLab Dedicated کے صارفین کو اس پیچ کے لیے خود کارروائی نہیں کرنی۔ پاکستان میں اپنی تنصیب چلانے والی ٹیم کے لیے فیصلہ اس کے نصب شدہ ورژن سے شروع ہوتا ہے: ہوسٹڈ سروس کی اپ ڈیٹ اس کے اپنے سرور تک نہیں پہنچتی۔ اگر سرور متاثرہ شاخ پر ہے تو اسی شاخ کا درست پیچ لگانا ہوگا، چاہے تنصیب عوامی انٹرنیٹ کے بجائے اندرونی نیٹ ورک پر ہو۔

متاثرہ شاخ کے لیے کون سا پیچ درست ہے؟

19.2 شاخ میں 19.2.8 سے پہلے، 19.3 شاخ میں 19.3.5 سے پہلے اور 19.4 شاخ میں 19.4.2 سے پہلے کے ورژن اس خامی سے متاثر ہیں۔ منتظم ہر تنصیب کا مکمل ورژن درج کرے؛ صرف بڑا ورژن دیکھنا کافی نہیں، کیونکہ فیصلہ آخری پیچ نمبر سے بدلتا ہے۔ لاگ اِن کے بعد بائیں جانب مدد کے صفحے پر نصب ورژن دیکھا جا سکتا ہے۔ مرکزی سرور کے ساتھ آزمائشی، ترقیاتی اور بحالی کے لیے رکھی گئی تنصیبات بھی فہرست میں شامل ہوں۔

19.3 شاخ کے لیے درست انتخاب 19.3.5 ہے۔ اس سے پہلے کا 19.3.4 اجرا، Ona انضمام فعال ہونے پر مرج ریکوئسٹ کے صفحات کو متاثر کرنے والی ایک الگ خرابی رکھتا تھا، جسے 19.3.5 میں درست کیا گیا۔ پرانی تنصیب سے ان شاخوں تک آنے والی ٹیم کو اپنے موجودہ ورژن کے مطابق اپ گریڈ راستہ طے کرنا ہوگا؛ درمیان میں درکار ورژن اور مکمل ہونے والی پس منظر کی منتقلی کو نظرانداز کرنا محفوظ طریقہ نہیں۔

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

خامی کس طرح استعمال ہو سکتی ہے، اور حملوں کی کیا خبر ہے؟

خطرہ CI/CD ترتیب میں ریگولر ایکسپریشن کی جانچ سے جڑا ہے۔ Rapid7 کے عملی تجزیے میں حملے کے لیے نقصان دہ CI/CD ترتیب اور ایک خاص ذخیرہ جاتی راستہ عوامی منصوبے میں شامل کیا گیا؛ اس نے غیر درست شدہ GitLab 19.4.1 پر کوڈ چلایا، جبکہ وہی کوشش درست شدہ 19.4.2 پر کامیاب نہ ہوئی۔ اس آزمائش میں حملہ آور کو پہلے نقصان دہ ترتیب ذخیرے تک پہنچانے کا ذریعہ درکار تھا۔ جہاں غیر معتبر صارف اکاؤنٹ بنا کر عوامی منصوبہ اور اس کا مواد شامل کر سکتا ہو، وہاں یہ شرط پوری ہو سکتی ہے۔

یہ تفصیل خطرے کی حد سمجھنے میں اہم ہے۔ بغیر تصدیق کے کوڈ چلنے کا نتیجہ ہر تنصیب میں یکساں طریقے سے حاصل ہو، ایسا ثابت نہیں ہوا؛ GitLab نے بھی اسے مخصوص حالات سے مشروط بتایا ہے۔ تاہم سرور پر کوڈ چلنے کی صلاحیت محض ایک ناکام پائپ لائن کا مسئلہ نہیں: تنصیب میں ماخذ کوڈ، رسائی کے ٹوکن، ترسیل کی اسناد اور رنرز سے متعلق معلومات ہو سکتی ہیں۔ ممکنہ نقصان اس بات پر منحصر ہے کہ متعلقہ سرور کو کون سی رسائی اور اختیارات دیے گئے ہیں۔

Censys کی 13 اکتوبر 2026 کی حفاظتی رپورٹ کے وقت اس کی تحقیقی ٹیم کو حقیقی ماحول میں استحصال کا علم نہیں تھا؛ اس تاریخ تک خامی امریکی CISA کی معلوم استحصال شدہ خامیوں کی فہرست میں بھی شامل نہیں تھی۔ Rapid7 کی شائع شدہ آزمائشی مثال حقیقی حملے کی تصدیق نہیں ہے۔ دوسری طرف، عوامی حملے کی رپورٹ نہ ہونا کسی مخصوص سرور کی سابقہ سرگرمی کو محفوظ قرار دینے کے لیے کافی نہیں۔

اپ گریڈ تک رسائی محدود کرنے اور پیچ لگانے کی ترتیب

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

1. ہر خود چلائی گئی GitLab تنصیب تلاش کریں۔ مکمل ورژن، اس تک بیرونی رسائی اور اس کے ذمہ دار منتظم کو ایک ہی فہرست میں درج کریں؛ آزمائشی اور بحالی کے سرور بھی شامل کریں۔
2. متاثرہ سرور کو اپ گریڈ تک غیر معتبر ذرائع سے محدود کریں۔ جہاں پوری تنصیب الگ نہیں کی جا سکتی، وہاں عوامی منصوبوں اور ان میں تبدیلی کی اجازت کا جائزہ لے کر عارضی پابندی مقرر کریں۔
3. موجودہ شاخ کا درست شدہ اجرا منتخب کریں۔ اپ گریڈ سے پہلے بیک اپ، واپسی کا راستہ اور مطلوبہ بندش کا وقت طے کریں؛ پرانے ورژن سے آنے کی صورت میں درمیانی اپ گریڈ مراحل بھی دیکھیں۔
4. اپ ڈیٹ کے بعد نصب ورژن دوبارہ معلوم کریں۔ لاگ اِن، ذخیرے سے کوڈ لینے، تبدیلی بھیجنے اور ضروری CI/CD کام چلنے کی مختصر جانچ سے تصدیق کریں کہ بنیادی خدمات بحال ہیں۔
5. اپ گریڈ سے پہلے کے دستیاب ریکارڈ میں نئے منتظمین، رسائی کے ٹوکن، رنر رجسٹریشن اور غیر متوقع پائپ لائن تبدیلیاں دیکھیں۔ ناقابلِ توضیح سرگرمی ملے تو اس کی الگ حفاظتی تفتیش شروع کریں۔

پیچ کے بعد کام مکمل ہونے کا ثبوت

ایک سرور پر نیا ورژن نظر آنا پوری تنظیم کی حالت نہیں بتاتا۔ فہرست میں موجود ہر متعلقہ تنصیب کے لیے اس کی شاخ کا درست شدہ ورژن، بنیادی خدمات کی کامیاب جانچ اور اپ گریڈ کے دوران شروع ہونے والی منتقلیوں کی حالت درج ہونی چاہیے۔ جس سرور کا اپ گریڈ مؤخر ہے، اس کی عارضی رسائی کی پابندی، ذمہ دار شخص اور اگلا مقررہ اقدام واضح رہیں۔

ورژن کی تصدیق مستقبل کے لیے خامی کی اصلاح دکھاتی ہے، ماضی کی سرگرمی کے بارے میں فیصلہ نہیں دیتی۔ پہلے بیرونی صارفین کے لیے کھلی تنصیبات میں منتظم کے نئے اکاؤنٹس، ٹوکن، رنرز اور پائپ لائن تبدیلیوں کا جائزہ زیادہ اہم ہے۔ اگر کوئی غیر متوقع تبدیلی ملے تو اس کا سبب اور اس سے حاصل شدہ رسائی معلوم کرنا اگلا کام ہوگا؛ صرف پیچ نصب ہونے سے وہ سوال حل نہیں ہوتا۔

یہ بھی پڑھیں:

• ServiceNow کی تین critical خامیاں؛ self-hosted instances فوراً patch کریں
• CVSS 10 اکیلا patch order نہیں، KEV اور affected version پہلے دیکھیں
• CVSS 10 پہلے patch ہو؟ KEV اور asset exposure فیصلہ بدل سکتے ہیں