يستغل مهاجمون ثغرة جديدة غير مُصلَحة في Magento Open Source وAdobe Commerce تتيح لهم تنفيذ شفرة خبيثة على خادم المتجر دون تسجيل دخول، بحسب تنبيه نشرته شركة أمن التجارة الإلكترونية الهولندية Sansec في 5 سبتمبر ونقله The Hacker News. أطلقت Sansec على الثغرة اسم StyleSmuggler وقالت إن الهجمات بدأت في 4 سبتمبر: «ننشر مبكرًا لأن المتاجر تُخترق الآن».
من المتأثر؟
قالت Sansec إن كل الإصدارات الحالية متأثرة، بما فيها 2.4.9، وإنها أعادت إنتاج سلسلة الاستغلال الكاملة دون مصادقة على منشآت Magento Open Source نظيفة بالإصدارات 2.4.7 و2.4.8 و2.4.9. أول ضحية رصدتها كانت تشغّل 2.4.6-p15 مع تحديثات يوليو وأغسطس 2026 الأمنية مطبّقة — أي أحدث مستوى تصحيح تقدّمه أدوبي لهذا الخط.
لم تنشر Sansec إعادة إنتاج على Adobe Commerce أو Adobe Commerce on Cloud، ولم تؤكد أدوبي الإصدارات المتأثرة، ولم تُعلن Sansec عدد المتاجر المخترقة.
«حالة التصحيح لم تكن ذات صلة هنا، وهذا ما يحتاج التجار إلى سماعه أكثر من أي شيء.» — Disrex Group لـ The Hacker News
كيف يعمل الهجوم؟
بحسب مخطط Sansec، يعمل الهجوم على مرحلتين:
- تلويث ملف يكتبه Magento بنفسه — مثل تقرير عطل يولّده النظام — بشفرة PHP مضمّنة.
- إجبار Magento على تنفيذ ذلك الملف عبر تشغيل رسالة البريد القياسية «Payment Transaction Failed Reminder». تعمل الشفرة أثناء عرض Magento للرسالة، فلا يحتاج أحد إلى فتحها، وينجح الهجوم حتى لو فشل إرسال البريد.
قراءة Disrex Group — شركة استضافة وتطوير Magento استجابت لمتجرين مخترقين — أن توجيهًا داخل النص المحقون يقود سلسلة من فئات Magento نفسها إلى شفرة موجودة حصرًا لخدمة مُصرِّف حقن الاعتماديات في سطر الأوامر، وتنتهي بتضمين مسار ملف يختاره المهاجم: السجل الملوَّث قبل لحظة. ثم يجرّب المُنزِّل ست دوال PHP لبدء عملية، وينزّل الغرسة ويشغّلها. لم تؤكد Sansec هذه القراءة بعد، ووعدت بتفصيل كامل للسلسلة والمُنزِّل والغرسة في تحديث لاحق.
الغرسة: Rust يتنكّر في خيط نواة
الغرسة عملية خلفية تتخفى تحت الاسم [kworker/u:8:0] — اسم يعود لخيط في نواة لينكس — ببرنامج Rust ثابت الربط بحجم 1.9 ميغابايت لمعماريتي x86-64 وarm64، مثبَّت في ~/.local/share/.gvfsd/gvfsd-user تحت مجلد المستخدم لا داخل جذر الويب، مع إدخال cron يعيد تشغيله كل خمس دقائق ويُكتب مباشرة في ملف spool فلا يظهر استبدال crontab في سجل النظام. في أحد المتاجر تكررت السطر 1,728 مرة، وأعادت الغرسة إضافته خلال ثانية من حذفه.
تفصيل مهم من Disrex: على أحد المتجرين لم تُجرِ الغرسة أي اتصال خارج؛ احتفظت بـ 28 اتصالًا إلى Redis المحلي وقرأت تخزين جلسات Magento منه — أي أن قواعد الجدار الناري الخارجة وحدها لا تكشفها. وعلى المتجر نفسه كان الملف التنفيذي في الذاكرة بناءً مختلفًا عن الملف على القرص.
كيف تكتشفها؟
أين تبحث | ما تبحث عنه |
|---|---|
var/report/ وvar/log/system.log | علامة بشكل X-TRACE- أو X- متبوعة بعشرة أحرف سداسية — ابحث عن الشكل لا النص الحرفي؛ فحص Sansec المنشور يغطي var/report فقط وفاته كلا متجري Disrex |
system.log | خطأ TypeError من array_merge() بوسيطة عددية مباشرة بعد التضمين = نجح الاستغلال (متغير أخفى لا يترك شيئًا) |
قائمة العمليات | عملية باسم بين أقواس مربعة مملوكة للمستخدم غير root ولها ذاكرة مقيمة — خيط النواة الحقيقي مملوك لـ root بلا ذاكرة. فحص حقل comm لا يكفي؛ استخدم /proc/<pid>/exe |
بريد المالك | رسائل «Payment Transaction Failed Reminder» بقوالب غير مفكوكة ({{var ...}} خام)، عنوان عميل على نطاق .invalid، ومجموع صفر — أوضح إنذار مبكر ولا يحتاج أدوات |
| filename | [kworker/u:8:0] | اسم العملية المنتحَل — مملوكة لمستخدم غير root |
| filename | ~/.local/share/.gvfsd/gvfsd-user | الغرسة على القرص |
| filename | /tmp/.kw_<random> · /tmp/.gvfsd_<8hex>.lock | ملفات مؤقتة وقفل |
| sha256 | e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 | عينة Sansec |
| sha256 | 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef | على القرص في متجري Disrex |
| sha256 | 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 | في الذاكرة على أحد المتاجر |
| domain | 247[.]cdnflare[[.]]xyz | مضيف تنزيل الغرسة |
| ipv4 | 99[.]84[.]67[[.]]186:443 | تحكّم عبر WebSocket/TLS (Sansec) |
| ipv4 | 88[.]216[.]72[[.]]181 · 5[.]181[.]86[[.]]133 | مصادر الهجوم |
الروابط والعناوين معطَّلة (defanged) للحماية
ماذا تفعل حتى يصدر الإصلاح؟
- عطّل GraphQL مؤقتًا — نصيحة Sansec للمتاجر التي لا تستخدم منتجها Shield. تنبيه: واجهات headless وتطبيقات PWA تحتاج GraphQL؛ أغلب الواجهات الكلاسيكية وHyvä لا.
- قواعد nginx/Apache من Disrex تحجب معاملات الاستغلال في سلسلة الاستعلام — لكن اختبار Disrex نفسه أظهر أن المعاملات ذاتها في جسم POST أو JSON تصل إلى PHP. هذه القواعد توقف الحملة بشكلها الحالي لا الثغرة.
- تعديل Disrex الرئيسي: إضافة فحص إلى ثلاث دوال في ماسحات حقن الاعتماديات يمنع تشغيلها خارج سطر الأوامر. يُلغى مع كل
composer install، فالشركة تنشر أيضًا رقعة composer. - وسّع نطاق الفحص: eComscan أعطى نتيجة «نظيف» على متجر مصاب لأنه فحص جذر المستند بينما الغرسة تجلس مجلدًا أعلى. افحص مجلد المستخدم كاملًا.
- دوّر بيانات اعتماد Magento أينما وُجدت العملية، حتى دون دليل على استخدام الباب الخلفي.
- راقب إصدار أدوبي في 8 سبتمبر وطبّقه فور صدوره إن غطّى الثغرة.
*سنحدّث هذا التقرير عند صدور تنبيه أدوبي أو التفصيل التقني الكامل من Sansec.*
