InvoiceShelf نے CVE-2026-55610 کے لیے ایک پیچ (patch) جاری کیا ہے، جو کہ ایک سنگین نقص ہے جس کے ذریعے ایک کمپنی کا کوئی بھی مالک دوسری کمپنی کے صارف اکاؤنٹس پر قبضہ کر سکتا تھا۔ CVSS اسکیل پر 8.7 کی درجہ بندی والا یہ نقص، ایپ کے Laravel کوڈ میں ٹیننٹ-اسکوپ (tenant-scope) چیک کی کمی کی وجہ سے پیدا ہوا۔

یہ نقص کیسے کام کرتا تھا

InvoiceShelf ایک SaaS ٹول ہے جو Laravel پر مبنی ہے اور کمپنیوں کو ایک ہی ڈیش بورڈ سے صارفین، انوائسز اور سیٹنگز کو مینیج کرنے کی اجازت دیتا ہے۔ یہ پلیٹ فارم ٹیننٹ کی شناخت کے لیے ایک کسٹم ہیڈر (custom header) پڑھتا ہے۔ جب کوئی مالک (Owner) صارف کا ریکارڈ طلب کرتا ہے، تو کوڈ صرف یہ چیک کرتا ہے کہ، "کیا درخواست گزار اپنی کمپنی کا مالک ہے؟"

یہ کبھی بھی اس بات کی تصدیق نہیں کرتا کہ مطلوبہ صارف اسی ٹیننٹ سے تعلق رکھتا ہے۔ Laravel کی implicit route-model binding صارف کی ID کو گلوبل users ٹیبل کے ایک رو (row) سے جوڑ دیتی ہے، اور اتھارائزیشن پالیسی صرف درخواست گزار کے کردار (role) کی بنیاد پر درخواست کی منظوری دے دیتی ہے۔

لہذا، ایک حملہ آور:

  • درخواست کے URL میں کوئی بھی عددی صارف ID فراہم کر سکتا ہے۔
  • ای میل سمیت صارف کا مکمل ریکارڈ حاصل کر سکتا ہے۔
  • ایک ایسی اپ ڈیٹ جاری کر سکتا ہے جو متاثرہ صارف کی ای میل، پاس ورڈ کو تبدیل کر دے اور یہاں تک کہ اکاؤنٹ کو حملہ آور کی کمپنی میں super-admin کے طور پر دوبارہ تفویض (reassign) کر دے۔

عملی طور پر، ایک بدنیتی پر مبنی مالک نے کمپنی مینجمنٹ ٹول کو اکاؤنٹ ہائی جیک کرنے کے ایک عالمگیر ہتھیار میں بدل دیا۔ اس کے لیے "Owner" کے علاوہ کسی اور خصوصی اختیارات کی ضرورت نہیں تھی۔

کون متاثر ہے

2.4.1 سے پہلے کا ورژن استعمال کرنے والا ہر InvoiceShelf کسٹمر اس خطرے کی زد میں تھا۔ چونکہ یہ نقص درخواست ہینڈلنگ کے بنیادی راستے (core request-handling path) میں موجود ہے، اس لیے کسی بھی ٹیننٹ کو کسی دوسرے ٹیننٹ کے مالک کا نشانہ بنایا جا سکتا تھا، چاہے کمپنی کا سائز یا سیکیورٹی کی صورتحال کچھ بھی ہو۔ اس کے اثرات میں رازداری کا نقصان (ای میل ایڈریسز) اور سالمیت کا نقصان (غیر مجاز پاس ورڈ کی تبدیلی، super-admin کے عہدے تک رسائی) شامل ہیں۔

پیچ (The Patch)

ڈویلپرز نے ورژن 2.4.1 جاری کیا ہے، جس میں صارف کے ریکارڈ پر کسی بھی ریڈ (read) یا رائٹ (write) آپریشن سے پہلے ایک واضح ٹیننٹ چیک شامل کیا گیا ہے۔ یہ اصلاح (fix) کوئری کو فعال کمپنی آئیڈینٹی فائر (active company identifier) تک محدود کر دیتی ہے، جس سے Laravel صرف وہی روز (rows) واپس کرنے پر مجبور ہوتا ہے جو درخواست گزار کے ٹیننٹ سے تعلق رکھتی ہیں۔

ڈویلپرز کو کیا سیکھنا چاہیے

  • ملٹی ٹیننٹ ایپلی کیشنز میں کبھی بھی گلوبل پرائمری کیز (global primary keys) پر بھروسہ نہ کریں۔
  • ہر ڈیٹا بیس لک اپ (database lookup) پر ٹیننٹ فلٹر لگائیں، نہ کہ صرف ڈیلیٹ یا کریٹ ایکشنز پر۔
  • اتھارائزیشن پالیسیوں کو اس طرح بنائیں کہ وہ ایکٹر کے کردار اور ٹارگٹ آبجیکٹ کی ٹیننسی (tenancy) دونوں کی تصدیق کریں۔
  • امپلیسٹ فریم ورک فیچرز جیسے کہ route-model binding کو محض سہولت کے طور پر لیں جو سیکیورٹی کے خلا کو چھپا سکتے ہیں، جب تک کہ آپ واضح اسکوپنگ (explicit scoping) شامل نہ کریں۔

مستقبل کا منظرنامہ

یہ واقعہ کسی بھی ایسے SaaS کے لیے وسیع تر خطرے کو ظاہر کرتا ہے جو ٹیبلز شیئر کرتا ہے۔ سیکیورٹی آڈٹ کو ان تمام اینڈ پوائنٹس (endpoints) کا جائزہ لینا چاہیے جو آئیڈینٹی فائیئرز قبول کرتے ہیں اور اس بات کی تصدیق کرنی چاہیے کہ ٹیننٹ اسکوپنگ کو یکساں طور پر نافذ کیا گیا ہے۔

حاصلِ کلام: ٹیننٹ چیک کی ایک چھوٹی سی کمی ایک بااختیار صارف کے کردار کو ایک عالمگیر بیک ڈور (backdoor) میں بدل سکتی ہے۔ مناسب اسکوپنگ کوئی اختیاری چیز نہیں ہے؛ یہ کسی بھی ملٹی ٹیننٹ سسٹم میں ڈیٹا کی علیحدگی (data isolation) کی بنیاد ہے۔