ترقيع ماجنتو وحده لا ينقذ متجرك — المهاجمون دخلوا قبل صدوره بثلاثة أيام

ثغرة بدرجة 10 من 10 في ماجنتو وأدوبي كوميرس: ما الذي حدث بالضبط

الجواب المباشر أولا: في الرابع من سبتمبر 2026 بدأ مهاجمون استغلال ثغرة غير مرقّعة في منصة ماجنتو المفتوحة وأدوبي كوميرس، تحمل الرقم CVE-2026-75650 ودرجة خطورة 10.0 وهي أعلى درجة ممكنة. الثغرة تسمح بتنفيذ أوامر على خادم المتجر دون تسجيل دخول ودون أي صلاحية، وأصدرت أدوبي ترقيعها مساء السابع من سبتمبر. أي أن هناك ثلاثة أيام كاملة كانت فيها المتاجر مكشوفة بلا أي حماية. لهذا السبب تحديدا فإن تركيب الترقيع وحده لا يكفي: إذا كان متجرك يعمل على هذه المنصة فالافتراض الآمن هو أنك ربما اختُرقت قبل أن يصدر الإصلاح، والواجب أن تبحث عن آثار الدخول وتبدّل مفاتيح التشفير وكل بيانات الاعتماد، لا أن تركّب التحديث وتكمل يومك.

من المتأثر بالضبط

القائمة واسعة إلى درجة غير معتادة، لأنها تشمل أحدث إصدار متاح وقت الاكتشاف:

• ماجنتو المفتوحة وأدوبي كوميرس: الإصدارات من 2.4.4 إلى 2.4.9 بكل تحديثاتها حتى أغسطس 2026.
• أدوبي كوميرس B2B: الإصدارات من 1.3.3 إلى 1.5.3 حتى تحديث أغسطس 2026.
• الإصدارات الأقدم من 2.4.4: خارج الدعم أصلا، وهي الأخطر لأن الترقيع الرسمي لا يغطيها.

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

كيف يعمل الهجوم من دون كلمة مرور

الهجوم يمر بمرحلتين، ويستغل قدرة ماجنتو على توليد قوالب رسائل البريد. في المرحلة الأولى يرسل المهاجم طلبا مصنوعا إلى مسار استجابة الدفع، فيُكتب محتوى الطلب كاملا داخل ملف تقرير أخطاء على الخادم. في المرحلة الثانية يرسل طلبا إلى واجهة GraphQL يشير إلى ذلك الملف الملوّث، فيُنفّذ محتواه أثناء تجهيز رسالة تذكير بفشل عملية الدفع.

النقطة التي تستحق انتباه صاحب العمل ليست التفاصيل التقنية، بل ما تكشفه: مسارات عامة يفترض أنها بريئة تماما — استجابة بوابة دفع، وواجهة استعلام للواجهة الأمامية، ورسالة بريد آلية — اجتمعت لتصنع طريقا كاملا إلى داخل الخادم. الثغرات الخطيرة نادرا ما تكون بابا واحدا مفتوحا، وغالبا ما تكون سلسلة من أبواب صغيرة كلٌّ منها يبدو منطقيا وحده.

ماذا زرع المهاجمون بعد الدخول

هنا يظهر الفرق بين عابث وجهة منظمة. الحمولات التي رُصدت لم تكن رسالة تشفير ابتزازية صاخبة، بل أدوات بقاء صامتة:

• باب خلفي مكتوب بلغة Rust يتنكر في صورة عملية من عمليات نواة النظام، فلا يلفت نظر من يتصفح قائمة العمليات بسرعة.
• اتصال مموّه بخوادم التحكم عبر منفذ مزامنة الوقت، بحيث يبدو النشاط في سجلات الشبكة وكأنه ضبط ساعة اعتيادي.
• أصداف ويب بلغة PHP تُكتب داخل مجلدات ذاكرة صور المنتجات، وهي أماكن لا يفتشها أحد عادة لأنها مليئة بملفات مؤقتة.
• أدوات تحكم عن بعد إضافية من مهاجم ثانٍ بأدوات مختلفة، ما يعني أن الثغرة استُغلت من أكثر من جهة في الوقت نفسه.

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

لماذا لا يكفي تركيب التحديث

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

الترقيع يوقف النزيف. تدوير المفاتيح هو ما يخرج الضيف غير المدعو من البيت.

خطة عمل عملية لصاحب المتجر

• أولا — تأكد أن الإصلاح مركّب فعلا لا أن أحدهم قال إنه ركّبه. اطلب من فريقك إثباتا من سجل الترقيعات على الخادم نفسه، لا رسالة تطمين.
• ثانيا — افحص آثار الاختراق: عمليات تشغيل مشبوهة بأسماء تحاكي عمليات النظام، ملفات PHP داخل مجلدات الوسائط والصور، وملفات تقارير أخطاء غير معتادة.
• ثالثا — راجع سجل البريد الصادر. الارتفاع المفاجئ في رسائل تذكير فشل عمليات الدفع مؤشر مباشر على محاولة استغلال، وهو مؤشر يستطيع أي مسؤول تشغيل قراءته دون خبرة أمنية عميقة.
• رابعا — دوّر كل المفاتيح بلا استثناء، وبالذات بيانات بوابة الدفع. هذه خطوة تحتاج نافذة صيانة مخططة لا قرارا مرتجلا وقت الذروة.
• خامسا — إن كانت نسختك أقدم من 2.4.4 فلا تنتظر ترقيعا رسميا لن يأتي. ضع خطة ترقية بتاريخ محدد، واعزل المتجر خلف جدار حماية تطبيقات في الأثناء.
• سادسا — وثّق ما فعلته. إن تبين لاحقا تسرّب بيانات عملاء فستحتاج سجلا زمنيا لما قمت به ومتى.

البعد النظامي في السعودية: بيانات العملاء ليست شأنا تقنيا فقط

متجر إلكتروني يخزّن أسماء عملاء وعناوين وأرقام جوال وسجل طلبات يتعامل مع بيانات شخصية تخضع لنظام حماية البيانات الشخصية. وقوع حادثة تسرّب لا يبقى مسألة داخلية بين المتجر ومزوّد الاستضافة، بل يرتب التزامات تجاه الجهة المختصة وتجاه أصحاب البيانات أنفسهم. ولهذا فإن السؤال الذي يجب أن يطرحه صاحب المتجر اليوم ليس «هل رُقّع الخادم» فقط، بل «هل أستطيع أن أثبت أن بيانات عملائي لم تُمس».

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

كيف نتعامل مع هذا النوع من الحوادث في أوريجامي

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

وإذا كنت تدير متجرا على ماجنتو ولا تملك فريقا تقنيا مخصصا، فالخطوة الصحيحة اليوم بسيطة: اطلب تقريرا مكتوبا من مزوّد الاستضافة أو الشريك التقني يجيب عن ثلاثة أسئلة فقط — متى رُكّب الإصلاح بالضبط، ما نتيجة فحص آثار الاختراق، وهل دُوّرت المفاتيح. ثلاثة أسئلة تكشف جاهزية أي شريك تقني أكثر من أي عرض تقديمي.

المصادر

• بيان أدوبي كوميرس الرسمي حول التحديث الأمني APSB26-146 والإصلاح العاجل: experienceleague.adobe.com
• تحليل Sansec التقني للثغرة CVE-2026-75650 وأدلة الاختراق: sansec.io/research/stylesmuggler-0day
• سجل الثغرات المستغلة المعروفة لدى وكالة الأمن السيبراني الأمريكية CISA: cisa.gov
• نظام حماية البيانات الشخصية — الهيئة السعودية للبيانات والذكاء الاصطناعي: sdaia.gov.sa