اگر آپ کی کمپنی GitLab کو اپنے سرور پر چلاتی ہے تو اسے آج ہی اپ ڈیٹ کریں۔ 12 اکتوبر 2026 کو GitLab نے ایک کریٹیکل سکیورٹی پیچ جاری کیا جو 24 خامیوں کو دور کرتا ہے۔ ان میں سب سے سنگین، CVE-2026-97229، کو سب سے زیادہ ممکنہ شدت کا اسکور ملا: 10 میں سے 10۔ یہ ایسے شخص کو، جس کا آپ کے سرور پر کوئی اکاؤنٹ نہیں، اس پر اپنا کوڈ چلانے دیتی ہے۔ 19.2.8 سے پہلے کے 19.2، 19.3.5 سے پہلے کے 19.3 یا 19.4.2 سے پہلے کے 19.4 ورژن چلانے والا ہر سرور متاثر ہے۔ GitLab جو واحد حل بتاتا ہے وہ 19.4.2، 19.3.5 یا 19.2.8 پر اپ گریڈ کرنا ہے۔ اگر آپ GitLab.com پر کلاؤڈ سروس استعمال کرتے ہیں تو آپ کو کچھ کرنے کی ضرورت نہیں۔

GitLab کیا ہے، اور کاروباری مالک کو اس کی فکر کیوں ہونی چاہیے؟

GitLab وہ جگہ ہے جہاں آپ کی تکنیکی ٹیم آپ کے سسٹمز اور ایپس کا سورس کوڈ رکھتی ہے، اور جہاں نئے ورژن تیار کر کے آپ کے سرورز پر بھیجے جاتے ہیں۔ بہت سی کمپنیاں کوڈ اور ڈیٹا کو ادارے کے اندر رکھنے کے لیے اسے کلاؤڈ سروس کے بجائے اپنے اندرونی سرور پر چلاتی ہیں۔ اس سرور پر عموماً مالک کی توقع سے زیادہ چیزیں ہوتی ہیں: پورا سورس کوڈ، ڈیٹابیس کے پاس ورڈ، وہ کیز جو آپ کو پیمنٹ گیٹ ویز اور سرکاری خدمات سے جوڑتی ہیں، اور ان سرورز پر ڈیپلائے کرنے کا اختیار جنہیں آپ کے صارفین استعمال کرتے ہیں۔ جس کے قبضے میں یہ سرور ہو وہ یہ سب پڑھ سکتا ہے، اور آپ کا کوڈ صارفین تک پہنچنے سے پہلے بدل بھی سکتا ہے۔

GitLab نے دراصل کیا اعلان کیا؟

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

اعلان یہ نہیں کہتا کہ اس خامی کا غلط استعمال ہوا ہے۔ لیکن 10 کے اسکور کا مطلب ہے کہ اسے انٹرنیٹ کے ذریعے، بغیر پاس ورڈ اور کسی ملازم کی مدد کے بغیر استعمال کیا جا سکتا ہے۔ حملہ آور عموماً اصلاح عام ہونے کے چند دنوں کے اندر ایسی خامیوں کی تلاش شروع کر دیتے ہیں، کیونکہ اصلاح خود بتا دیتی ہے کہ کمزوری کہاں ہے۔

پیچ میں اور کیا شامل ہے؟

یہی پیچ 23 دیگر خامیوں کو بھی دور کرتا ہے، جن میں سے پانچ کو زیادہ شدت والا قرار دیا گیا ہے:

  • سنٹیکس ہائی لائٹنگ میں بدنیتی پر مبنی اسکرپٹ انجیکشن (XSS)، اسکور 8.7۔
  • پائپ لائنز بناتے وقت اجازت (authorization) کی ایک خامی، اسکور 8.5۔
  • فائل تک رسائی کو متاثر کرنے والا ضرورت سے زیادہ ڈھیلا ریگولر ایکسپریشن، اسکور 8.2۔
  • پیڈ ایڈیشن میں پائپ لائن ایگزیکیوشن پالیسیوں میں اجازت کی ایک خامی، اسکور 7.7۔
  • پیڈ ایڈیشن میں GitLab Duo AI ایجنٹ میں پرامپٹ انجیکشن کی خامی، اسکور 7.3۔

اس لیے 19.2 سے پرانے ورژن، جن پر کریٹیکل خامی کا اثر نہیں، ضروری نہیں کہ محفوظ ہوں۔ GitLab کی سرکاری مینٹیننس پالیسی کہتی ہے کہ سکیورٹی اصلاحات صرف موجودہ ریلیز اور پچھلی دو ماہانہ ریلیزز میں ہی بیک پورٹ کی جاتی ہیں۔ اس سے پرانے کسی بھی ورژن والے سرور کو اب کوئی سکیورٹی اصلاح نہیں ملتی، اور اسے ہر صورت اپ گریڈ کرنے کی ضرورت ہے۔

کسے قدم اٹھانا چاہیے؟

  • GitLab.com کلاؤڈ صارفین: کچھ کرنے کی ضرورت نہیں؛ GitLab کہتا ہے کہ سروس پہلے ہی پیچ شدہ ورژن پر چل رہی ہے۔
  • GitLab Dedicated کے صارفین: اعلان کے مطابق انہیں بھی کچھ کرنے کی ضرورت نہیں۔
  • GitLab کو اپنے سرور پر چلانے والا ہر شخص: فوراً اپ گریڈ کریں۔ ہر خود منظم تنصیب کے لیے GitLab کی یہی واضح سفارش ہے۔
  • جسے یقین نہیں کہ اس کا GitLab کہاں چلتا ہے: آج ہی اپنی ٹیم سے یا اس وینڈر سے پوچھیں جس نے آپ کے سسٹمز بنائے۔ بہت سے اندرونی سرور کسی سابق وینڈر نے سیٹ کیے اور پھر انہیں بھلا دیا گیا۔

اس ہفتے کے عملی اقدامات

  1. ورژن معلوم کریں: اپنے تکنیکی سربراہ سے کہیں کہ وہ GitLab میں Help صفحہ کھولیں، وہاں دکھایا گیا ورژن نمبر پڑھیں اور اس کا موازنہ اوپر دیے گئے نمبروں سے کریں۔
  2. اپ گریڈ مہینے کے آخر میں نہیں، آج ہی شیڈول کریں: GitLab کے اعلان کے مطابق، سنگل نوڈ سرور پیچ کے دوران اس وقت تک بند رہتا ہے جب تک ڈیٹابیس مائیگریشن مکمل نہ ہو جائیں، جبکہ ملٹی نوڈ سیٹ اپ کو درست زیرو ڈاؤن ٹائم طریقۂ کار پر عمل کر کے بغیر ڈاؤن ٹائم کے پیچ کیا جا سکتا ہے۔ کام کے اوقات سے باہر ایک گھنٹے کا ڈاؤن ٹائم ہیک شدہ سرور سے کہیں کم مہنگا پڑتا ہے۔
  3. اگر آپ 19.3 پر ہیں: 19.3.4 پر نہیں، سیدھے 19.3.5 پر جائیں۔ اعلان بتاتا ہے کہ 19.3.4 میں ایک بگ تھا جو Ona انٹیگریشن فعال ہونے پر مرج ریکویسٹ صفحات کو متاثر کرتا تھا، اور اسے 19.3.5 میں ٹھیک کیا گیا۔
  4. انٹرنیٹ پر رسائی کم کریں: اگر کمپنی سے باہر کسی کو آپ کے GitLab سرور تک پہنچنے کی ضرورت نہیں تو اسے صرف کمپنی کے نیٹ ورک سے یا VPN کے ذریعے کنکشن قبول کرنے دیں۔ یہ پیچ کرنے کا متبادل نہیں، لیکن اگلی بار دروازہ تنگ کر دیتا ہے۔
  5. پیچ کے بعد جانچ کریں: حال ہی میں بنائے گئے صارفین، کیز اور ایکسیس ٹوکنز کا جائزہ لیں۔ اگر کوئی ایسی چیز نظر آئے جسے کوئی نہیں پہچانتا تو سرور پر محفوظ پاس ورڈ اور کیز تبدیل کر دیں۔

ہر تنصیبی طریقے کے لیے اپ گریڈ کے مراحل GitLab کی سرکاری اپ گریڈ گائیڈ میں دیے گئے ہیں۔

Origami کی رائے

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

ذرائع