StyleSmuggler نے Magento stores میں backdoor ڈالا—patch ابھی نہیں

StyleSmuggler کے ذریعے Magento اسٹورز پر بغیر لاگ اِن code execution اور Linux backdoor نصب ہونے کے شواہد ملے ہیں۔ Sansec کی تازہ کردہ تحقیق میں پہلا تصدیق شدہ حملہ 4 ستمبر 2026، ابتدائی انکشاف 5 ستمبر اور Magento Open Source 2.4.7، 2.4.8 اور 2.4.9 پر صاف تنصیبات میں مکمل chain کی reproduction درج ہے۔

عنوان ابتدائی disclosure کی صورتِ حال بیان کرتا ہے، جب کوئی vendor patch موجود نہیں تھا۔ اب Adobe کی 7 ستمبر کی ہنگامی ہدایت میں CVE-2026-75650 کے لیے VULN-39341 hotfix، متاثرہ product branches اور credentials تبدیل کرنے کے اقدامات موجود ہیں؛ اس لیے موجودہ ترجیح patch لگانے کے ساتھ پہلے سے ہونے والی دراندازی تلاش کرنا ہے۔

متاثرہ versions اور ثبوت کی حد

• سرخ — براہِ راست ثابت شدہ: Magento Open Source 2.4.7، 2.4.8 اور 2.4.9 پر صاف ماحول میں unauthenticated chain چلائی گئی۔ پہلا معلوم متاثرہ اسٹور 2.4.6-p15 پر تھا اور حالیہ security updates نصب ہونے کے باوجود compromise ہوا۔
• سرخ — vendor کی متاثرہ فہرست: Magento Open Source کی 2.4.6 سے 2.4.9 branches، Adobe Commerce کی 2.4.4 سے 2.4.9 branches اور متعلقہ Adobe Commerce B2B releases hotfix ہدایت میں شامل ہیں۔ “Earlier” سے مراد درج شدہ branches کی پہلے والی builds ہیں، ہر تاریخی Magento release نہیں۔
• زرد — Adobe Commerce کے شواہد کی نوعیت: vendor نے اپنے Commerce merchants کو نشانہ بنانے والی حقیقی exploitation تسلیم کی ہے، مگر Magento Open Source جیسی الگ public clean-lab reproduction سامنے نہیں آئی۔ اس فرق کا مطلب یہ نہیں کہ Adobe Commerce محفوظ ہے؛ صرف ثبوت کی قسم مختلف ہے۔
• نیلا — ابھی نامعلوم: متاثرہ اسٹورز کی قابلِ اعتماد عالمی تعداد، حملہ آوروں کی شناخت اور ہر compromised host پر ڈیٹا تک رسائی کی حد شائع نہیں ہوئی۔

The Hacker News کی ابتدائی تحقیق نے دو الگ متاثرہ Magento Open Source اسٹورز—2.4.8 اور 2.4.7-p2—کا incident-response evidence بیان کیا تھا، جبکہ اس وقت Adobe Commerce پر الگ public reproduction دستیاب نہیں تھی۔ اب vendor confirmation سے Commerce کا خطرہ محض نظریاتی نہیں رہا، لیکن اس سے ہر Commerce deployment کا compromised ہونا بھی ثابت نہیں ہوتا۔

Hotfix آ چکا ہے، مگر compatibility محدود طور پر verify ہوئی

VULN-39341 لگانا فوری حفاظتی اقدام ہے، مکمل incident cleanup نہیں۔ Hotfix کی سرکاری compatibility testing مخصوص 2026-aug builds پر ہوئی ہے؛ اسی branch کی پرانی supported build پر patch کام کر سکتا ہے، مگر اسے باقاعدہ verified configuration نہیں کہا جا سکتا۔ Operator کو اپنے عین product، branch اور deployment model کے مطابق package منتخب کرنا چاہیے۔

Adobe Commerce Cloud میں Quality Patches Tool کے ذریعے VULN-39341 کا status “Applied” دیکھنا تنصیب کی تصدیق کا حصہ ہے۔ On-premises ماحول میں بھی deployment record، patch file اور بدلے ہوئے code کی جانچ ضروری ہے؛ صرف کامیاب composer command یا cache flush کو کافی ثبوت نہ سمجھا جائے۔

Patch نئی exploitation کا راستہ بند کرتا ہے، لیکن پہلے سے چلتا implant، cron persistence یا PHP web shell خود نہیں ہٹاتا۔ اسی طرح encryption key بدلنے سے پہلے ظاہر ہو چکے admin passwords، integration tokens، OAuth secrets، payment-gateway credentials، database credentials، deployment keys یا extension API keys خود منسوخ نہیں ہوتے؛ انہیں متعلقہ اصل system یا provider پر تبدیل کرنا ہوگا۔

Failed-payment email سے code کیسے چلا

دستیاب technical outline میں حملہ دو مرحلوں پر مشتمل ہے۔ پہلے attacker-controlled PHP مواد ایسی log یا error file میں داخل کیا جاتا ہے جسے Magento خود لکھتا ہے، اور malicious input کو styles properties کے ذریعے موجودہ safeguards سے گزارا جاتا ہے۔ پھر “Payment Transaction Failed Reminder” email render کروا کر اسی poisoned file کو template processing کے راستے execute کیا جاتا ہے۔

کسی خریدار یا ملازم کو email کھولنے کی ضرورت نہیں، کیونکہ code message تیار ہوتے وقت چلتا ہے اور delivery ناکام ہونے پر بھی chain کامیاب ہو سکتی ہے۔ غیر معمولی failed-payment notices، raw template variables یا مشکوک صفر-total transaction تفتیش کا اشارہ ہو سکتے ہیں، مگر کوئی ایک email قطعی ثبوت نہیں؛ جائز declined payment بھی یہی اطلاع پیدا کر سکتی ہے۔

کامیاب exploitation کے بعد Rust پر مبنی background implant دیکھا گیا، جو Linux کے مانوس process ناموں کے پیچھے چھپتا ہے۔ BleepingComputer کی تکنیکی تفصیل میں [kworker/u:8:0] اور fc-cache نام، cron persistence اور remote commands وصول کرنے کی صلاحیت بیان کی گئی ہے۔ صلاحیت کی موجودگی الگ بات ہے؛ ہر متاثرہ host سے ڈیٹا چوری یا payment skimming اس سے خود بخود ثابت نہیں ہوتی۔

IOC جانچ اور recovery کی ترجیح

1. اپنے Magento Open Source، Adobe Commerce یا Commerce B2B release کو متاثرہ فہرست سے ملائیں، درست VULN-39341 hotfix لگائیں اور تنصیب کی قابلِ جانچ تصدیق محفوظ کریں۔
2. var/report، application logs، site user کی home directory، temporary directories، running processes، cron spool اور pub/media میں غیر متوقع PHP files دیکھیں۔ جانچ کو صرف web root تک محدود نہ کریں، کیونکہ مشاہدہ شدہ implants home directory اور temporary paths میں بھی ملے ہیں۔
3. [kworker/u:8:0]، fc-cache یا chronyd جیسے process نام کو صرف نام کی بنیاد پر malicious قرار نہ دیں۔ process owner، executable path، resident memory، parent process، cron entry اور network activity کو ملا کر فیصلہ کریں، کیونکہ یہی نام جائز Linux components بھی استعمال کرتے ہیں۔
4. IOC ملنے پر process ختم کرنے سے پہلے running executable، متعلقہ logs، cron data اور filesystem changes کا forensic record محفوظ کریں۔ نامعلوم تبدیلیوں والے host کو صرف reboot یا process kill کے بعد صاف قرار دینا قابلِ اعتماد recovery نہیں ہے۔
5. Patch کے بعد encryption key، admin accounts، active sessions، API اور integration tokens، payment credentials، database secrets اور deployment keys تبدیل کریں۔ اگر compromise کی حد واضح نہ ہو تو معلوم طور پر صاف build یا host سے بحالی زیادہ محفوظ راستہ ہے۔

GraphQL بند کرنا patch سے پہلے ایک عارضی containment تھا، مستقل حل نہیں۔ Headless storefront، PWA، mobile application یا checkout integration اس API پر منحصر ہو تو اسے بند کرنے سے storefront یا ادائیگی کا عمل رک سکتا ہے۔ اب official hotfix دستیاب ہونے کے بعد GraphQL shutdown یا WAF rule کو patch کا متبادل نہیں سمجھنا چاہیے؛ ایسے controls صرف محدود اضافی تہہ ہیں۔

موجودہ حالت: patch اور compromise investigation الگ کام ہیں

StyleSmuggler کی active exploitation، Magento Open Source پر clean reproduction اور server-side backdoor deployment ثابت ہو چکے ہیں۔ CVE-2026-75650 کے لیے VULN-39341 دستیاب ہونے سے “patch ابھی نہیں” والی ابتدائی حالت ختم ہو گئی، مگر patch لگنے سے پہلے compromise ہونے والے اسٹور کی خودکار صفائی نہیں ہوتی۔

Adobe Commerce کو متاثرہ product مان کر patch کرنا ضروری ہے، جبکہ ہر deployment میں compromise کا فیصلہ اس host کے evidence سے ہوگا۔ اگلی اہم معلومات میں متاثرہ merchants کے forensic نتائج، نئے payload variants اور پرانی supported builds پر hotfix کی عملی compatibility شامل ہیں؛ تب تک prevention، detection اور recovery کو تین الگ ذمہ داریاں سمجھنا درست operational مؤقف ہے۔

یہ بھی پڑھیں:

• PaperCut zero-day کے لیے دوسرا emergency patch؛ پہلے والا کافی نہیں
• پاکستان میں Stripe اور PayPal نہیں، international payment قانونی طور پر کیسے لیں؟
• Genesys کا AI agent ابھی مکمل نہیں—A2A اور نئی voice بعد میں آئیں گے