Magento اور Adobe Commerce میں 10 میں سے 10 درجے کی خامی: اصل میں کیا ہوا

پہلے سیدھا جواب: 4 ستمبر 2026 کو حملہ آوروں نے Magento Open Source اور Adobe Commerce میں ایک ایسی خامی کا فائدہ اٹھانا شروع کیا جس کا ابھی کوئی پیچ نہیں تھا۔ اسے CVE-2026-75650 کے طور پر درج کیا گیا ہے اور اس کا شدت اسکور 10.0 ہے — جو ممکنہ طور پر سب سے زیادہ ہے۔ یہ خامی اسٹور کے سرور پر بغیر لاگ اِن اور بغیر کسی اختیار کے کمانڈز چلانے دیتی ہے، اور Adobe نے اس کا حل 7 ستمبر کی شام جاری کیا۔ یعنی پورے تین دن تک اسٹورز بغیر کسی تحفظ کے کھلے رہے۔ یہی وجہ ہے کہ صرف پیچ لگانا کافی نہیں: اگر آپ کا اسٹور اس پلیٹ فارم پر چلتا ہے تو محفوظ مفروضہ یہی ہے کہ حل آنے سے پہلے ہی آپ کے سسٹم میں نقب لگ چکی ہو، اور درست ردعمل دراندازی کی علامات تلاش کرنا اور اپنی انکرپشن کیز اور ہر سند کو تبدیل کرنا ہے — نہ کہ اپ ڈیٹ لگا کر اپنے دن کے کاموں میں لگ جانا۔

ٹھیک ٹھیک کون متاثر ہے

فہرست غیر معمولی طور پر وسیع ہے، کیونکہ اس میں دریافت کے وقت دستیاب سب سے نیا ریلیز بھی شامل ہے:

  • Magento Open Source اور Adobe Commerce: ورژن 2.4.4 سے 2.4.9 تک، اگست 2026 تک کی تمام پیچ اپ ڈیٹس سمیت۔
  • Adobe Commerce B2B: ورژن 1.3.3 سے 1.5.3 تک، اگست 2026 کی اپ ڈیٹ تک۔
  • 2.4.4 سے پرانا کوئی بھی ورژن: پہلے ہی سپورٹ سے باہر، اور سب سے خطرناک زمرہ، کیونکہ سرکاری ہاٹ فکس اس کا احاطہ نہیں کرتا۔

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

حملہ بغیر پاس ورڈ کے کیسے کام کرتا ہے

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

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

اندر پہنچ کر حملہ آوروں نے کیا نصب کیا

یہیں ایک تخریب کار اور ایک منظم کارروائی کا فرق نظر آتا ہے۔ جو پے لوڈز دیکھے گئے وہ شور مچانے والے رینسم ویئر نوٹس نہیں بلکہ خاموشی سے ٹکے رہنے والے ٹولز تھے:

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

کسی معروف آن لائن اسٹور پر ایسے پے لوڈز کا مقصد سائٹ بند کرنا نہیں بلکہ طویل عرصے تک ٹکے رہنا اور آرڈر اور ادائیگی کا ڈیٹا گزرتے وقت پڑھنا ہے۔ متاثرہ اسٹور مکمل طور پر معمول کے مطابق چلتا رہتا ہے، اور یہی بات پریشان کن ہے۔

صرف اپ ڈیٹ لگانا کیوں کافی نہیں

کیونکہ اگر کوئی حملہ آور 7 ستمبر سے پہلے اندر آ گیا تھا تو اب اس کے پاس آپ کی انکرپشن کیز اور محفوظ کی گئی اسناد کی ایک کاپی موجود ہے۔ پیچ وہ دروازہ بند کرتا ہے جس سے وہ آیا تھا؛ اسے اندر سے باہر نہیں نکالتا۔ Adobe کی اپنی رہنمائی اس بارے میں بالکل واضح تھی: حل لاگو کریں اور اس کے بعد انکرپشن کیز، ایڈمن پینل کے پاس ورڈز، API ٹوکنز، پیمنٹ گیٹ وے کی اسناد، ڈیٹا بیس کے پاس ورڈز اور سرور تک رسائی کی کیز تبدیل کریں۔

پیچ خون بہنا روکتا ہے۔ بن بلائے مہمان کو گھر سے نکالنے کا کام کیز کی تبدیلی کرتی ہے۔

اسٹور کے مالک کے لیے ایک عملی لائحہ عمل

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

سعودی عرب میں ریگولیٹری پہلو: صارفین کا ڈیٹا صرف تکنیکی معاملہ نہیں

صارفین کے نام، پتے، موبائل نمبرز اور آرڈر کی تاریخ رکھنے والا آن لائن اسٹور ایسا ذاتی ڈیٹا پروسیس کر رہا ہے جو ذاتی ڈیٹا کے تحفظ کے قانون کے تحت آتا ہے۔ ڈیٹا کی خلاف ورزی اسٹور اور اس کے ہوسٹنگ فراہم کنندہ کے درمیان اندرونی معاملہ بن کر نہیں رہتی؛ یہ متعلقہ اتھارٹی اور خود ڈیٹا کے مالکان کے حوالے سے ذمہ داریاں پیدا کرتی ہے۔ اس لیے آج اسٹور کے مالک کو صرف یہ نہیں پوچھنا چاہیے کہ "کیا سرور پر پیچ لگ گیا" بلکہ یہ بھی کہ "کیا میں ثابت کر سکتا ہوں کہ میرے صارفین کے ڈیٹا کو چھوا نہیں گیا"۔

اگر آپ کا اسٹور Salla یا Zid جیسے منیجڈ کلاؤڈ پلیٹ فارم پر چلتا ہے تو آپ اس مخصوص خامی کے دائرے سے باہر ہیں، کیونکہ پلیٹ فارم پر پیچ لگانا آپ کی ذمہ داری نہیں۔ لیکن یہی سبق ہر اس ایکسٹینشن یا تھرڈ پارٹی انٹیگریشن پر لاگو ہوتا ہے جو آپ نے اپنے اسٹور سے جوڑ رکھا ہے: پیچ لگانے کی ذمہ داری اسی کی ہے جس کا سرور ہے۔

Origami میں ہم ایسے واقعات سے کیسے نمٹتے ہیں

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

اور اگر آپ کسی مخصوص تکنیکی ٹیم کے بغیر Magento اسٹور چلاتے ہیں تو آج کا درست قدم سادہ ہے: اپنے ہوسٹنگ فراہم کنندہ یا تکنیکی شراکت دار سے ایک تحریری رپورٹ مانگیں جو صرف تین سوالوں کا جواب دے — حل ٹھیک کب انسٹال ہوا، نقب زنی کی جانچ میں کیا ملا، اور کیا کیز تبدیل کی گئیں۔ یہ تین سوال کسی تکنیکی شراکت دار کی تیاری کے بارے میں کسی بھی پریزنٹیشن سے زیادہ بتاتے ہیں۔

ذرائع

  • سیکیورٹی اپ ڈیٹ APSB26-146 اور فوری ہاٹ فکس پر Adobe Commerce کا سرکاری اعلان: experienceleague.adobe.com
  • CVE-2026-75650 اور نقب زنی کے اشاریوں پر Sansec کا تکنیکی تجزیہ: sansec.io/research/stylesmuggler-0day
  • CISA کی معلوم استحصال شدہ کمزوریوں کی فہرست: cisa.gov
  • ذاتی ڈیٹا کے تحفظ کا قانون (PDPL) — سعودی ڈیٹا اور مصنوعی ذہانت اتھارٹی (SDAIA): sdaia.gov.sa