StyleSmuggler: ثغرة Magento صفرية تحوّل ملفات السجل إلى بوابة لتنفيذ الكود على الخادم

لم يحتج المهاجم إلى حساب إداري، ولم يكن الخادم متأخرًا في التحديثات. أحد خوادم Magento التي كانت تديرها Disrex اختُرق بعد نحو 50 دقيقة فقط من أول استغلال مؤكد عالميًا لثغرة StyleSmuggler، رغم أن الخادم كان محدثًا بالكامل.

الأخطر لم يكن مجرد الوصول إلى التطبيق، بل الطريقة التي تحوّل بها ملف يُفترض أنه سجل تشخيصي عادي إلى جزء قابل للتنفيذ من سلسلة الهجوم. يكتب المهاجم شيفرة PHP خبيثة داخل ملف يستطيع Magento الوصول إليه، ثم يدفع منظومة القوالب وDependency Injection إلى تضمين ذلك الملف باستخدام include أو require_once. عندها لا يعود السجل مجرد نص؛ بل يصبح شيفرة تنفذ داخل الخادم.

بعد نجاح الاستغلال، يمكن للهجوم أن يغادر حدود مجلد Magento بالكامل. في الحوادث التي حققتها Disrex، ظهر زرع برمجي أصلي على Linux متخفيًا باسم يشبه خيطًا من خيوط النواة، مع استمرارية عبر cron وملفات مخفية خارج مجلد المتجر، وهو ما يجعل الفحص المحدود لملفات التطبيق وحدها غير كافٍ.

#TL;DR

  • StyleSmuggler ثغرة Zero-Day غير مرقعة رسميًا وقت نشر المصدر، تؤثر في Magento Open Source وAdobe Commerce وتتيح Unauthenticated Remote Code Execution.
  • Sansec أعلنت الحملة في 5 سبتمبر 2026 بعد رصد استغلال فعلي وإعادة إنتاج السلسلة على إصدارات Magento 2.4.7 و2.4.8 و2.4.9.
  • أول ضحية مؤكدة كانت تعمل على Magento 2.4.6-p15 محدث بالكامل، ما يعني أن مستوى التحديث وحده لم يكن كافيًا للحماية.
  • السلسلة تعتمد على تلويث ملف سجل أو تقرير بشيفرة PHP، ثم إجبار مكونات داخلية في Magento على تضمينه وتنفيذه.
  • بعد التنفيذ، يمكن إطلاق زرع برمجي أصلي على Linux والانتقال خارج مجلد المتجر مع آليات استمرارية مثل cron.
  • Disrex نشرت تصحيحًا طارئًا يغلق مسار الاستغلال المعروف عبر جعل ثلاث دوال ماسح Dependency Injection تعمل من CLI فقط، لكنه ليس إصلاحًا رسميًا من Adobe ولا ينظف خادمًا سبق اختراقه.

#نافذة الهجوم سبقت قواعد الكشف

جميع الأوقات التالية بتوقيت UTC يومي 4 و5 سبتمبر 2026:

الوقتالحدث
4 سبتمبر، 22:20أول استغلال مؤكد عالميًا لـ StyleSmuggler
4 سبتمبر، 23:10اختراق خادم Magento تديره Disrex بعد 50 دقيقة
5 سبتمبر، 07:15تفعيل أول قواعد Sansec Shield المخصصة لـ StyleSmuggler
5 سبتمبر، 13:51Disrex تؤكد الاختراق أثناء الاستجابة للحادث
5 سبتمبر، بعد 14:00 بقليلبدء الاحتواء في البيئات المتأثرة

عمليًا، كان المهاجمون داخل بعض الخوادم الضعيفة لنحو ثماني ساعات قبل توفر أول قواعد كشف مخصصة للحملة. خلال هذه الفترة لم يكن هناك تصحيح رسمي، ولم تكن توجد قاعدة كشف عامة خاصة بـ StyleSmuggler.

هذا يفسر لماذا لا يمكن النظر إلى كون النظام «محدثًا» باعتباره إثباتًا على سلامته عندما تكون الثغرة مجهولة ولم يصدر لها إصلاح بعد.

#ما هي StyleSmuggler؟

تحوّل StyleSmuggler مكونات موجودة أصلًا في Magento إلى سلسلة Remote Code Execution (RCE) لا تتطلب تسجيل الدخول.

تعمل السلسلة في مرحلتين أساسيتين:

  1. يجبر المهاجم Magento على كتابة شيفرة PHP خبيثة داخل ملف يستطيع التطبيق الوصول إليه، مثل var/log/system.log أو ملف داخل var/report/.
  2. يرسل طلبًا ثانيًا يدفع نظام القوالب إلى المرور عبر سلسلة Object Injection حتى يصل إلى ماسح ضمن آلية Dependency Injection يقوم بتضمين الملف المسموم باستخدام include أو require_once.

الخطر هنا أن include في PHP لا يقرأ الملف كنص فقط. إذا احتوى الملف على شيفرة PHP، فسيتم تحليلها وتنفيذها. بهذا تتحول سجلات يفترض أن تكون تشخيصية إلى وسيط تنفيذي داخل التطبيق.

يقدم تحليل Disrex التقني شرحًا للسلسلة من البداية إلى النهاية، لكنه يتعمد عدم نشر الطلب الكامل المركب اللازم لإعادة إنتاج الاستغلال:

Technical analysis of the StyleSmuggler chain

#كيف تمر سلسلة الاستغلال داخل Magento؟

على مستوى عالٍ، المسار المعروف للهجوم هو:

text
1. Attacker-controlled input reaches Magento's template filter
2. A template directive starts an object-injection chain
3. Attacker-controlled parameters steer Magento through internal classes
4. A DI scanner includes a file chosen by the attacker
5. The chosen log or report file already contains poisoned PHP
6. PHP executes the payload and launches a native implant

المصب القابل للاستغلال يوجد داخل مترجم Dependency Injection في Magento. ثلاث فئات Scanner تقبل مسار ملف ثم تمرره إلى include أو require_once.

هذه الفئات موجودة أساسًا لخدمة الأمر:

bash
bin/magento setup:di:compile

ولا يوجد سبب شرعي لتشغيلها ضمن طلب ويب عادي.

هذه النقطة تحديدًا هي الأساس الذي بنت عليه Disrex التصحيح الطارئ: السماح لهذه الماسحات بالعمل من سطر الأوامر، ورفض تشغيلها عندما تأتي عبر Web SAPI.

#من ملف Log إلى Implant يعمل على Linux

نجاح الاستغلال لا يبقى بالضرورة داخل Magento. في الحوادث التي حققتها Disrex، أطلق الاستغلال زرعًا برمجيًا أصليًا على Linux حاول الظهور كأنه Kernel Worker:

text
[kworker/u:8:0]

الاسم بحد ذاته تمويه. خيوط نواة Linux الحقيقية تعمل تحت المستخدم root ولا تملك ذاكرة مقيمة عادية بالشكل نفسه الذي يظهر في العمليات التقليدية. لذلك فإن عملية باسم محاط بأقواس مربعة، تعمل تحت مستخدم المتجر وتستهلك ذاكرة فعلية، تعد مؤشرًا قويًا على الاشتباه.

الزرع البرمجي الذي رصدته Disrex قام بعد ذلك بعدة خطوات:

  • نقل نفسه إلى ~/.local/share/.gvfsd/gvfsd-user.
  • أنشأ ملفات قفل داخل مجلد المستخدم و/tmp.
  • أضاف مهمة cron تعيد تشغيله كل خمس دقائق.
  • استطاع إعادة الاستمرارية بعد إزالة مدخل cron.
  • واصل العمل من deleted inode حتى بعد تغير الملف الموجود على القرص.
  • تواصل مع خدمة Redis المحلية الخاصة بـ Magento دون الحاجة بالضرورة إلى اتصال خارجي مريب.

وهذا يغيّر طريقة التعامل مع الحادث جذريًا. حذف ملف خبيث من var/ أو إعادة تثبيت Magento لا يعني أن الخادم أصبح نظيفًا، لأن العملية النشطة وآليات الاستمرارية وأي حمولات إضافية قد تكون موجودة خارج Document Root.

#لماذا قد تفشل الفحوص المعتادة؟

#مجلد Magento النظيف لا يعني أن الخادم نظيف

الكثير من أدوات فحص التطبيقات تركز على ملفات تثبيت Magento نفسها. في الحالة التي حققتها Disrex، كان الزرع البرمجي موجودًا داخل مجلد مستخدم Linux، أي خارج مجلد المتجر.

#فحص var/report/ وحده غير كافٍ

بعض صور الهجوم تسمم ملفات تقارير الأعطال، لكن الإصابات التي حققتها Disrex استخدمت:

text
var/log/system.log

لذلك يجب فحص كل من:

text
var/report/
var/log/

#غياب الاتصالات الخارجية لا يثبت سلامة الخادم

في إحدى الإصابات المرصودة لم يفتح الزرع أي اتصال خارجي مريب. بدلًا من ذلك تواصل مع Redis المحلي عبر:

text
127.0.0.1:6379

وبالتالي فإن عدم رؤية اتصال إلى عنوان Command and Control منشور لا يكفي للحكم بأن النظام نظيف.

#البصمة على القرص قد لا تطابق العملية في الذاكرة

قد يختلف الملف التنفيذي النشط في الذاكرة عن النسخة الموجودة على القرص. إذا كانت هناك عملية مشتبه بها، يوصي المصدر بالحفاظ على الملف التنفيذي النشط وأخذ بصمته من:

text
/proc/<pid>/exe

ضمن إجراءات التحقيق.

#خطأ PHP لا يعني أن الاستغلال فشل

عند تضمين سجل مسموم لا يعيد قيمة، قد يصل التنفيذ لاحقًا إلى array_merge() ويظهر Type Error.

لكن هذا الخطأ يحدث بعد أن يكون الملف قد نُفذ بالفعل. لذلك يجب التعامل مع ظهور هذا الخطأ على أنه دليل محتمل على نجاح التنفيذ، وليس دليلًا على فشل الاستغلال.

#فحوص فورية على خادم Magento

المصدر يقترح تشغيل الفحوص التالية بصلاحية مستخدم ملفات Magento، مع تعديل المسارات بما يناسب بيئة الاستضافة.

#البحث عن عمليات غير Root تتنكر كـ Kernel Threads

bash
ps -eo pid,user,rss,args --no-headers | awk '$4 ~ /^\[/ && $2 != "root"'

#فحص الاستمرارية والملفات المعروفة

bash
crontab -l 2>/dev/null | grep -i 'gvfsd\|\.kw_' ls -la ~/.local/share/.gvfsd/ /tmp/.kw_* /tmp/.gvfsd-* 2>/dev/null

#البحث عن PHP مسموم في تقارير وسجلات Magento

نفّذ الأمر التالي من جذر تثبيت Magento:

bash
grep -rl 'X_TRACE_\|<?php' var/report/ var/log/ 2>/dev/null

#البحث في Access Logs عن شكل الطلب المعروف

bash
grep -acE 'styles(\[|%5B)|generatorClass|with_resolved|cdnflare' /path/to/access.log

هذه الفحوص تغطي مؤشرات عالية الثقة من الحملة المرصودة، لكن النتيجة النظيفة ليست برهانًا مطلقًا على عدم وجود اختراق. قد تتغير المؤشرات، وقد يكون الخادم أعيد تشغيله، أو قد يكون المهاجم زرع بابًا خلفيًا ثانويًا مختلفًا.

للحصول على قائمة المؤشرات الكاملة والمحدثة كما نشرها المصدر:

Complete StyleSmuggler indicators of compromise

#ماذا تفعل عند العثور على مؤشر؟

لا يوصي المصدر بالبدء مباشرة بإعادة تشغيل الخادم أو حذف الملف التنفيذي أو تشغيل:

bash
composer install

لأن هذه الإجراءات قد تدمر أدلة مهمة مع بقاء آليات استمرارية أخرى.

الترتيب المقترح هو:

  1. Confirm: التحقق من أن العملية أو الملف أو مدخل cron أو محتوى السجل يطابق الحملة.
  2. Preserve evidence: حفظ العمليات والملفات المفتوحة والاتصالات والسجلات ومهام cron والملف التنفيذي النشط قدر الإمكان.
  3. Contain: إزالة الاستمرارية أولًا، ثم إيقاف العمليات الخبيثة، ثم إزالة الملفات المعروفة.
  4. Hunt: فحص systemd timers ومواقع cron الأخرى وملفات Shell وSSH keys وإعدادات PHP وكود Magento وحسابات الإدارة وتكاملات API ومحتوى CMS وإعدادات قاعدة البيانات.
  5. Rotate secrets: تغيير كل بيانات الاعتماد التي كان يمكن لمستخدم ملفات Magento أو التطبيق قراءتها، بما في ذلك بيانات قاعدة البيانات والإدارة والتشفير والتكاملات.
  6. Assess impact: تحديد البيانات التي كان يمكن للعملية الوصول إليها وما إذا كانت هناك التزامات قانونية أو تعاقدية للإبلاغ عن الاختراق.
  7. Mitigate: بعد الاحتواء، تطبيق طبقات الحماية المتاحة ومراقبة عودة النشاط.

المصدر ينبه أيضًا إلى الانتظار لأكثر من دورة cron واحدة مدتها خمس دقائق، ثم إعادة فحص العمليات والاستمرارية، لأن البرمجية الخبيثة المرصودة استطاعت إعادة إنشاء مدخل cron بسرعة.

دليل التنظيف المنشور من Disrex:

StyleSmuggler cleanup guide

#التصحيح الطارئ لإصدارات Magento 2.4.6 حتى 2.4.9

نشرت Disrex تصحيحًا على مستوى المصدر لحزمة:

text
magento/magento2-base

يقوم التصحيح بجعل الدوال الثلاث المتأثرة في ماسحات Dependency Injection قابلة للتشغيل من CLI فقط. بهذا يغلق مسار include وrequire_once المعروف من خلال طلبات الويب، مع إبقاء عملية:

bash
bin/magento setup:di:compile

عاملة.

بحسب المصدر، التصحيح:

  • يطبق عبر composer-patches حتى يعاد تطبيقه بعد عمليات تثبيت Composer.
  • تمت مراجعته على مصادر Magento 2.4.6 و2.4.7 و2.4.8 و2.4.9.
  • طُبق وتم التحقق منه على بيئات حية تعمل بـ Magento 2.4.7-p2 و2.4.8-p4.
  • يسمح باستمرار تجميع Dependency Injection الطبيعي عبر CLI.
  • يرفض تنفيذ عمليات الماسحات المتأثرة خارج CLI.

رابط التصحيحات وتعليمات التثبيت:

StyleSmuggler patches and installation instructions

هذا التصحيح Mitigation طارئ وليس إصلاحًا رسميًا من Adobe. ويوصي المصدر باختباره على Staging، والاحتفاظ بنسخة احتياطية، وجعل فشل تطبيق التصحيح يوقف عملية النشر، ثم إزالة التصحيح أو استبداله عندما تصدر Adobe إصلاحًا رسميًا.

الأهم أن تطبيق التصحيح لا ينظف خادمًا سبق اختراقه. الكشف والاستجابة للحادث يجب أن يسبقا عملية التخفيف.

#طبقات دفاعية إضافية

#تعطيل دوال تشغيل العمليات في PHP

الـ Dropper الذي رُصد اختبر الدوال التالية واستخدم أول خيار متاح:

text
shell_exec, exec, system, passthru, proc_open, popen

يوصي المصدر بإضافة الدوال الست جميعها إلى disable_functions عندما تسمح توافقية التطبيق بذلك.

الإبقاء على proc_open وحدها قد يكون كافيًا لبدء الزرع البرمجي الأصلي حتى لو كانت الدوال الأربع الأولى معطلة.

#استخدام noexec على المجلدات المؤقتة

يمكن أن يساعد استخدام noexec على:

text
/tmp
/var/tmp
/dev/shm

في منع تشغيل ملف ثنائي تم تنزيله داخل هذه المسارات. لكن يجب التحقق من توافق ذلك مع بيئة النشر والاستضافة.

#قواعد Nginx أو Apache كمرشح مؤقت

يمكن لقواعد Nginx أو Apache حجب أنماط Query String المستخدمة في الحملة الحالية، لكن المصدر يتعامل معها كحاجز مؤقت لا أكثر.

السبب أن PHP يمكنه دمج معاملات GET وPOST، وقد يتجاوز المهاجم قاعدة تعتمد على Query String بنقل المعاملات إلى جسم الطلب.

أمثلة القواعد المنشورة:

Example Nginx and Apache rules

#تعطيل GraphQL إذا لم يكن مستخدمًا

تنصح Sansec المتاجر التي لا تستخدم Sansec Shield بالنظر في تعطيل GraphQL مؤقتًا حتى يتوفر إصلاح رسمي.

واجهات Classic وHyvä غالبًا لا تحتاج إلى GraphQL، بينما تعتمد عليه عادة المتاجر Headless وPWA. لذلك يجب التحقق من استخدامه فعليًا قبل حجب الـ Endpoint.

#مؤشرات الاختراق IOCs

المؤشرات المباشرة المذكورة في المصدر تشمل:

text
[kworker/u:8:0]

~/.local/share/.gvfsd/gvfsd-user

/tmp/.kw_*
/tmp/.gvfsd-*

var/log/system.log
var/report/

127.0.0.1:6379

X_TRACE_
<?php

styles[
styles%5B
generatorClass
with_resolved
cdnflare

كما يشير المصدر إلى قائمة IOCs الكاملة والمحدثة هنا:

Complete StyleSmuggler indicators of compromise

#التأثير التقني والمخاطر

StyleSmuggler لا تتوقف عند حدود Application Security. السلسلة تبدأ من داخل Magento، لكنها تنتهي بقدرة على تشغيل شيفرة على نظام التشغيل نفسه دون مصادقة.

هذا يضع الخادم أمام مجموعة مخاطر مترابطة: تنفيذ أوامر على المضيف، الوصول إلى أسرار يمكن لمستخدم التطبيق قراءتها، التفاعل مع خدمات محلية مثل Redis، زرع استمرارية خارج مجلد التطبيق، ثم احتمال الوصول إلى قواعد البيانات أو بيانات الاعتماد أو تكاملات API أو بيانات العملاء بحسب ما يملكه حساب التطبيق من صلاحيات.

ومن زاوية Incident Response، أخطر ما في الحادث أن تنظيف التطبيق وحده قد يترك النظام مخترقًا. إعادة تثبيت Magento أو حذف سجل مسموم لا يعالج عملية ما زالت تعمل في الذاكرة أو مهمة cron تعيد إنشاء الاستمرارية أو ملفًا مخفيًا داخل Home Directory.

أما من زاوية Business Continuity وData Protection، فالمصدر يربط الاستجابة الصحيحة بتحديد البيانات التي كان يمكن للزرع الوصول إليها، ثم تقييم ما إذا كانت هناك التزامات قانونية أو تعاقدية للإبلاغ عن الاختراق.

#لماذا لا يكفي Clean Scan؟

تكشف StyleSmuggler عن فجوة مهمة بين فحص التطبيق وفحص الخادم. Magento يكتب الحمولة، ثم ينفذ الملف المسموم، وبعدها تنتقل العملية إلى نظام التشغيل وتستقر خارج مجلد التطبيق.

ولهذا، فإن فحص vendor/ أو حذف ملف تقرير مشبوه أو إعادة تثبيت التطبيق يعالج جزءًا واحدًا فقط من الحادث. يجب فحص المضيف كاملًا، وحفظ الأدلة، والبحث عن الاستمرارية تحت مستخدم Linux الذي تعرض للاختراق.

إذا كان خادم Magento أو Adobe Commerce متصلًا بالإنترنت خلال نافذة الهجوم الأولى، فإن كون النسخة محدثة لا يحسم سلامته. أولى الإصابات المرصودة سبقت ظهور قواعد الكشف المخصصة للثغرة، وأحد الخوادم المؤكدة كان محدثًا بالكامل عند اختراقه.

#المصادر