كشفت شركة الأمن الهولندية Sansec، المتخصصة في حماية التجارة الإلكترونية، عن ثغرة يوم صفري تحمل اسم StyleSmuggler، تتيح للمهاجمين تنفيذ تعليمات برمجية عن بُعد دون مصادقة (RCE) في منصتي Magento Open Source وAdobe Commerce.
تشهد هذه الثغرة استغلالاً نشطاً منذ الرابع من سبتمبر 2026، ما دفع الشركة لنشر التفاصيل مبكراً نتيجة تعرض المتاجر للاختراق الفعلي. وحتى السادس من سبتمبر 2026، يغيب أي تصحيح رسمي أو حل بديل أو معرّف CVE من شركة Adobe، في حين توقف فهرس النشرات الأمنية لمنصة Adobe Commerce عند تحديث الحادي عشر من أغسطس الماضي.
تؤثر هذه الثغرة على جميع الإصدارات الحالية للمنصة، بما فيها الإصدار 2.4.9. وقد تمكنت Sansec من إعادة إنتاج سلسلة الاستغلال الكاملة على تثبيتات نظيفة من Magento Open Source للإصدارات 2.4.7 و2.4.8 و2.4.9. وسُجل أول اختراق لمتجر يعمل بالإصدار 2.4.6-p15، والذي يتضمن التحديثات الأمنية لشهري يوليو وأغسطس 2026، ليمثل أحدث مستوى تصحيح متاح لهذا الفرع.
آلية الاستغلال ومؤشرات الاختراق
تعتمد آلية الهجوم على حقن شيفرة خبيثة في نظام القوالب الخاص بمنصة Magento عبر استغلال خصائص styles لتجاوز الضوابط الأمنية. تُنفذ العملية على مرحلتين؛ تتضمن الأولى تسميم شيفرة PHP من خلال توليد تقرير فشل، وتجبر المرحلة الثانية منصة Magento على تنفيذ الشيفرة المسمومة أثناء توليد رسالة بريد إلكتروني خاصة بفشل الدفع. وتكتمل عملية التنفيذ بمجرد معالجة النظام للرسالة، بغض النظر عن فتح المستلم لها أو حتى نجاح تسليمها.
يتوج نجاح الاستغلال بزرع باب خلفي مستمر على خادم المتجر. وتتضمن مؤشرات الاختراق الرئيسية ظهور عملية خلفية تتنكر تحت اسم خيط شرعي في نواة Linux وهو [kworker/u:8:0]، وارتباطها بملف تنفيذي مُثبت في المسار ~/.local/share/.gvfsd/gvfsd-user داخل مجلد المستخدم الخاص بالموقع بعيداً عن جذر الويب. كما تشمل المؤشرات الاستعانة بنطاق 247.cdnflare[.]xyz وعناوين IP محددة تضم 99.84.67[.]186 و88.216.72[.]181 و5.181.86[.]133. ولضمان استمرارية الباب الخلفي، يُضاف إدخال في جدولة cron يعيد تشغيل العملية كل خمس دقائق، ويُكتب مباشرة في ملف التخزين المؤقت تحت مسار /var/spool/cron/crontabs/ لتجنب تسجيل النظام لأي استبدال في الجدولة.
الأدلة المستقلة والتأثير التشغيلي
قدمت شركة Disrex Group، المتخصصة في استضافة وتطوير متاجر Magento، أدلة مستقلة عبر مستودع للاستجابة للحوادث نُشر في الخامس من سبتمبر. تعاملت الشركة مع متجرين مخترقين وثالث تعرض لهجوم فاشل.
عمل المتجر الأول بالإصدار 2.4.8 وكان محمياً بمنتج Sansec Shield، ورغم فعالية الحماية ضد حركات خبيثة أخرى، وقع الاختراق في الساعة 23:10 بالتوقيت العالمي من الرابع من سبتمبر، قبل ساعات من تفعيل قواعد الحجب الخاصة بالثغرة. أما المتجر الثاني، فعمل بالإصدار 2.4.7-p2، وتعرض للهجوم في الساعة 00:55 بالتوقيت العالمي من الخامس من سبتمبر. وأكدت الشركة حدوث الاختراقات خلال نافذة زمنية قاربت ثماني ساعات بين أول استغلال رصدته Sansec وتوفر دفاع فعال، مشددة على أن مستوى التصحيح لم يكن العامل الحاسم في منع الهجوم.
أظهرت تحليلات Disrex أن الملف التنفيذي للباب الخلفي عبارة عن برنامج Rust مُجرد ومربوط ثابتًا بحجم 1.9 ميغابايت، مبني لمعماريتي x86-64 وarm64. واكتفت البرمجية الخبيثة في أحد المتاجر بالاحتفاظ بـ28 اتصالاً داخلياً بخادم Redis على المنفذ 6379 لقراءة مخزن جلسات Magento، متجنبة إجراء أي اتصال صادر إلى خوادم القيادة والتحكم، مما يحد من فعالية استراتيجيات الكشف القائمة على مراقبة حركة البيانات الخارجية.
التوصيات والإجراءات الوقائية
عملت المتاجر المتأثرة في حسابات معزولة بصلاحيات محدودة، ما منع الباب الخلفي من تنفيذ أي حركة جانبية أو الوصول لبيانات خارج نطاق المتجر المستهدف. وتم احتواء الحوادث خلال 14 ساعة من الاتصال الأول، دون رصد تسريب للبيانات أو حقن لأدوات سرقة بيانات الدفع.
تتمثل التوصية الوقائية المؤقتة للمتاجر في تعطيل واجهة GraphQL لحين إصدار Adobe لتصحيح رسمي، مع الأخذ في الاعتبار أن هذا الإجراء يؤثر على واجهات المتاجر المنفصلة (headless) وتطبيقات الويب التقدمية، بينما لا تحتاجه الواجهات الكلاسيكية وواجهات Hyvä.
ينصح المشغلون بإجراء فحوصات يدوية دقيقة تشمل مسارات var/report/ بحثاً عن العلامة X_TRACE_، ومسار var/log/system.log، نظراً لاحتمالية تغير مؤشرات الاختراق خلال الحملة المستمرة وتفاوت طرق الكشف بين الجهات الأمنية.
