StyleSmuggler يخترق متاجر Magento بلا تسجيل دخول ولا تصحيح رسمي
كُشف في 5 سبتمبر 2026 عن استغلال StyleSmuggler لاختراق متاجر Magento وتشغيل شفرة على خوادمها من دون مصادقة، بعد رصد الهجمات في 4 سبتمبر. وأثبت تحليل Sansec الفني السلسلة كاملة على تثبيتات نظيفة من Magento Open Source 2.4.7 و2.4.8 و2.4.9، بينما كان أول متجر رصدته الشركة يعمل بالإصدار 2.4.6-p15 مع تحديثات يوليو وأغسطس 2026.
حتى 6 سبتمبر 2026، لم يكن هناك تصحيح رسمي أو نشرة أمنية أو رقم CVE أو إجراء مؤقت صادر عن Adobe لهذه الثغرة. كما وثق تحقيق The Hacker News تأكيدًا مستقلًا من Disrex لاختراق متجرين يعملان بـMagento Open Source، أحدهما على 2.4.8 والآخر على 2.4.7-p2؛ لذلك يجب فحص الخادم بحثًا عن الإصابة قبل اعتبار أي حجب وقائي حلًا للمشكلة.
ما الذي تفعله StyleSmuggler داخل Magento؟
تعمل السلسلة على مرحلتين داخل نظام القوالب. يحقن المهاجم شفرة PHP في ملف ينشئه التطبيق، مثل تقرير فشل أو سجل، مستفيدًا من خصائص styles لتجاوز وسائل الحماية، ثم يدفع Magento إلى تحليل الملف المسموم وتنفيذ محتواه ضمن عملية الخادم.
ترتبط مرحلة التنفيذ بإنشاء رسالة Magento القياسية المسماة «Payment Transaction Failed Reminder». تعمل الشفرة أثناء تصيير الرسالة؛ فلا يحتاج أحد إلى فتح البريد، وقد ينجح الهجوم حتى إذا فشل تسليمه. لذلك قد تكون الزيادة المفاجئة في هذه الرسائل إشارة تستحق التحقيق، لكن غيابها لا يثبت سلامة المتجر، كما أن حالات رفض الدفع المشروعة قد تنتج الرسالة نفسها.
عند نجاح الهجوم، تُشغّل غرسة مستمرة في الخلفية تحت حساب مستخدم الموقع. لم يُنشر بعد تفصيل كامل قابل لإعادة الإنتاج لكل أجزاء سلسلة الاستغلال، ولم تسمِّ المصادر جهة الهجوم أو تقدم حصيلة عامة موثوقة لعدد المتاجر المخترقة.
افحص العمليات والملفات قبل تطبيق الحجب
الحجب يمنع طلبات لاحقة لكنه لا يزيل غرسة وصلت إلى الخادم قبله. ابدأ بحفظ سجلات خادم الويب وPHP، وقائمة العمليات والاتصالات والمهام المجدولة، ثم افحص حساب تشغيل المتجر كاملًا، بما يشمل دليل المستخدم والمجلدات المؤقتة؛ فالاقتصار على document root قد يفوّت ملفًا موضوعًا في مستوى أعلى.
تشمل المؤشرات المنشورة عملية باسم [kworker/u:8:0] تعمل تحت مستخدم غير root، والملف ~/.local/share/.gvfsd/gvfsd-user، وملفات تبدأ بـ/tmp/.kw_ أو /tmp/.gvfsd-. ابحث كذلك عن مهمة cron تشغّل gvfsd-user كل خمس دقائق، وعن آثار غير معتادة في var/report وvar/log/system.log، وراجع طلبات POST إلى /graphql التي تحمل معاملات styles.
الترتيب العملي للفحص والاحتواء هو:
- احفظ السجلات والعمليات والاتصالات وcron قبل تغيير البيئة أو إعادة تشغيلها.
- افحص دليل المتجر ودليل مستخدم الاستضافة والمجلدات المؤقتة، لا مسار الموقع وحده.
- إذا ظهرت الغرسة، اعزل العقدة واحفظ نسخة من الأدلة، ثم أزل مهمة الاستمرارية قبل إيقاف العملية لأنها قد تعيد إنشاء المهمة.
- وسّع الفحص إلى البيئات التي تشارك الخادم المصاب في حساب تشغيل أو أسرار أو وصول إلى النسخ الاحتياطية.
تعطيل GraphQL احتواء مؤقت له أثر تشغيلي
في غياب تصحيح Adobe، يبقى تعطيل GraphQL مؤقتًا خيارًا للمتاجر التي لا تحتاج إليه، لكنه ليس تصحيحًا ولا دليلًا على أن الخادم نظيف. ويبين تحديث Liquid Web الرسمي أنها طبقت في 5 سبتمبر حجبًا كاملًا لطلبات GraphQL في البيئات المتأثرة، ثم حذرت في 6 سبتمبر من أثر محتمل في واجهات headless وPWA والتطبيقات التي تعتمد عليه بكثافة، مع استمرار غياب تصحيح من المورّد.
إذا كان المتجر التقليدي لا يستخدم GraphQL في عرض المنتجات أو السلة أو الدفع، يمكن تطبيق الحجب الكامل مع اختبار رحلة الشراء فورًا. أما متجر headless أو PWA فقد يفقد وظائف أساسية أو يتوقف جزئيًا؛ وهنا يجب أن يوازن فريقا الاستضافة والتطوير بين استمرار الخدمة وتقليل مساحة الهجوم، مع إبقاء فحص الاختراق مسارًا مستقلًا.
قواعد WAF التي تبحث عن styles في query string قد تعترض نمط الحملة المرصود، لكنها لا تغلق الثغرة نفسها. يمكن أن تصل المعاملات في جسم POST أو JSON، ولذلك لا ينبغي تقديم قاعدة تعتمد على عنوان URL وحده باعتبارها حماية مكتملة.
عند ظهور مؤشر إصابة، انتقل إلى الاستجابة للحادث
وجود عملية أو ملف أو مهمة cron مطابقة ينقل الحالة من الوقاية إلى التعامل مع اختراق محتمل. بعد حفظ الأدلة وعزل البيئة، يكون إعادة بناء الخادم من مصدر موثوق أكثر أمانًا من افتراض أن حذف الملف الظاهر أعاد النظام إلى حالة سليمة؛ ويجب فحص النسخ الاحتياطية قبل استخدامها ومراجعة الملفات المعدلة والحسابات الإدارية والتكاملات والجلسات.
دوّر بيانات الاعتماد بحسب ما كان متاحًا لحساب العملية المخترقة، بما في ذلك كلمات مرور مسؤولي Magento ومفاتيح مزودي الدفع وأسرار التكامل الموجودة في app/etc/env.php. أبطل الجلسات النشطة وغيّر الأسرار المشتركة مع بيئات أخرى، لأن إزالة الغرسة لا تلغي بيانات ربما استطاع المهاجم قراءتها أثناء وجوده.
في المقابل، لا يجوز تحويل تنفيذ الشفرة المثبت إلى ادعاء غير مثبت عن سرقة بطاقات أو تسريب بيانات. لم تجد الاستجابة المستقلة في المتجرين الموثقين دليلًا على استخراج بيانات أو حسابات إدارية دخيلة أو أداة لسرقة المدفوعات، لكن هذا لا يثبت أن كل متجر آخر سليم؛ لكل بيئة سجلاتها ونطاق تعرضها.
حدود التأكيد وما يُنتظر من Adobe
الاختبارات العلنية تثبت السلسلة كاملة على Magento Open Source 2.4.7 و2.4.8 و2.4.9، وتثبت إصابة متجر على 2.4.6-p15، لكنها لا تعني أن كل إصدار أو كل تثبيت تعرض للاختراق. ولم تنشر Sansec إعادة إنتاج منفصلة على Adobe Commerce أو Adobe Commerce on Cloud، كما لم تحدد Adobe رسميًا نطاق الإصدارات المتأثرة حتى 6 سبتمبر.
كان الإصدار الأمني الدوري التالي لـAdobe مقررًا في 8 سبتمبر 2026، من دون تأكيد مسبق بأنه سيعالج StyleSmuggler. إلى أن يصدر تصحيح معتمد، يبقى التسلسل الصحيح هو البحث عن مؤشرات الإصابة أولًا، ثم احتواء مسار GraphQL مع قياس أثره، وتنفيذ تعافٍ كامل عند العثور على دليل اختراق بدل انتظار التصحيح على خادم قد يكون مصابًا بالفعل.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.