أصدرت Adobe إصلاحاً طارئاً للثغرة CVE-2026-75650، وهي ثغرة حرجة في Adobe Commerce وMagento Open Source يمكن أن تسمح بتنفيذ تعليمات برمجية عن بُعد من دون مصادقة. تصنّف Adobe الخلل بدرجة 10.0 وفق CVSS، وتقول إنه يُستغل فعلياً. كما حثّ المركز الأسترالي للأمن السيبراني ووكالة الأمن السيبراني في سنغافورة المؤسسات المتأثرة على تثبيت الإصلاح فوراً.

رسم توضيحي تحريري للأمن السيبراني: متجر إلكتروني يحميه تصحيح أمني ودرع من تهديدات الشبكة

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

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

ما الذي تتأثر به CVE-2026-75650

CVE-2026-75650 خلل في تحييد مدخلات غير سليمة داخل محرك قوالب. تصنّف Adobe أثره على أنه تنفيذ عشوائي للتعليمات البرمجية، وتقول إن المصادقة غير مطلوبة، وتمنحه درجة أساس 10.0 وفق CVSS 3.1. وتعكس الدرجة مسار هجوم يمكن الوصول إليه عبر الشبكة، من دون امتيازات مطلوبة أو تفاعل من المستخدم، مع احتمال إحداث أثر مرتفع في السرية والسلامة والتوافر.

تشمل عائلة المنتجات المتأثرة Adobe Commerce وAdobe Commerce B2B وMagento Open Source. تسرد نشرة Adobe الصادرة في 7 سبتمبر إصدارات Adobe Commerce من 2.4.4 حتى 2.4.9، بما في ذلك الإصدارات التي تحمل علامة بناء 2026-August، ضمن النطاق المتأثر. كما تسرد إصدارات Adobe Commerce B2B من 1.3.3 حتى 1.5.3، وإصدارات Magento Open Source من 2.4.6 حتى 2.4.9. وتبقى نشرة Adobe المرجع المعتمد لتحديد تركيبة الحزمة والبناء بدقة؛ لذلك ينبغي للتاجر مقارنة التثبيت قيد التشغيل والشفرة المنشورة بتلك النشرة، لا الاكتفاء باسم عائلة المنتج.

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

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

لماذا يغيّر التوقيت طريقة الاستجابة

نشرت Adobe النشرة APSB26-146 في 7 سبتمبر 2026، مع منحها أعلى درجة أولوية. وتقول النشرة إن الشركة على علم باستغلال الثغرة فعلياً. أما Sansec، التي نشرت بحثها في 5 سبتمبر، فأفادت بأنها رصدت هجمات بدأت في 4 سبتمبر، ووصفت المشكلة وقت الكشف بأنها ثغرة يوم صفري لتنفيذ التعليمات البرمجية عن بُعد من دون مصادقة. وقد حُدّثت صفحة Sansec في 13 سبتمبر، وتقول إن الإصلاح الطارئ صدر بعد ثلاثة أيام من أول استغلال مؤكد.

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

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

القرار الأول: الترقيع أم الاحتواء

إذا كان المتجر متأثراً وكان بالإمكان تطبيق الإصلاح بأمان، فالإجراء الفوري هو اتباع تعليمات Adobe لتثبيت إصلاح CVE-2026-75650. وتعرّف Sansec الإصلاح بأنه Adobe hotfix VULN-39341، ويُقدّم على هيئة رقعة Composer. يجب أن تأتي الحزمة الدقيقة والإصدار المدعوم وطريقة النشر من ملاحظات إصدار Adobe ومن اتفاقية دعم التاجر. لا تستبدل الرقعة بنسخة من منشور غير موثوق في منتدى، ولا تفترض أن نتيجة عادية من security:patch-status تثبت تثبيت هذا الإصلاح الطارئ.

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

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

ينبغي للفرق توخي الحذر مع الفروع غير المدعومة. تفيد Sansec بأن تغطية الإصلاح الطارئ التي اختبرتها Adobe مرتبطة بإصدارات 2026-August المدعومة، وتقول إن الفروع الأقدم متأثرة لكنها لم تتحقق منها Adobe بالطريقة نفسها. إذا كانت المؤسسة تستخدم إصداراً خارج الدعم، فالخيار المسؤول هو إشراك مشرف Commerce أو جهة مؤهلة للاستجابة للحوادث، واختبار ترقية مدعومة أو backport تمت مراجعته، وتجنب تغيير إنتاجي غير مختبر بينما يواصل المتجر خدمة المعاملات.

الترقيع ليس نهاية المهمة

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

ابدأ التحقيق بخط زمني دقيق. حدّد متى كانت كل نسخة من Commerce المواجهة للإنترنت ضعيفة، ومتى كانت نقطة النهاية /graphql قابلة للوصول، ومتى ظهرت أولى علامات الطلبات المشبوهة، ومتى طُبّق الإصلاح، وما إذا كان التطبيق قد أُعيد تشغيله أو نشره بعد ذلك. ضمّن سجلات CDN وWAF والوكيل العكسي وموازن التحميل وخادم الويب وPHP-FPM والتطبيق ونظام التشغيل والمهام المجدولة وتدقيق السحابة. استخدم منطقة زمنية موحدة، واحتفظ بالملفات الأصلية قبل التصفية أو التدوير.

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

يصف تقرير Sansec نمطاً من مرحلتين يسمّم فيه المهاجم شفرة مرتبطة بنظام قوالب Magento، ثم يجعل Magento يعرض تلك الشفرة عبر مسار إشعار فشل الدفع. ويمنح هذا السلوك العام المدافعين أسئلة عملية من دون محاولة إعادة إنتاج الاستغلال: هل ارتفعت إشعارات فشل الدفع فجأة؟ هل تغيرت بيانات مرتبطة بالقوالب خارج نشر اعتيادي؟ هل نفّذ عامل Commerce كتابة ملف أو اتصالاً صادراً غير معتاد في الوقت نفسه؟ لا تكفي الإشارة وحدها لإثبات الاختراق. فقد تنتج المدفوعات المرفوضة أو الإضافات أو الصيانة المجدولة أحداثاً مشابهة، لذا يجب ربط النتائج بسجلات النشر وطلبات الوصول.

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

الأسرار التي قد تحتاج إلى تدوير

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

قد تشمل القائمة كلمات مرور المديرين، ورموز تكامل REST وSOAP وGraphQL، وأسرار عملاء OAuth، وبيانات اعتماد بوابة الدفع، وكلمات مرور قاعدة البيانات، ومفاتيح SSH، ومفاتيح النشر، وبيانات اعتماد السحابة، ومفاتيح API لإضافات الجهات الخارجية. دوّرها عند مصدرها، لا بمجرد تعديل قيمة داخل إعدادات Commerce. فتغيير بيانات اعتماد الدفع داخل المتجر لا يلغي المفتاح القديم لدى مزود الدفع؛ بل يجب على المزود إصدار بيانات الاعتماد أو إبطالها. وينطبق المبدأ نفسه على IAM السحابي، وإدارة الشفرة المصدرية، والمراقبة، والشحن، ومنصات التسويق.

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

تغيير مفتاح تشفير Commerce وحده ليس استجابة مكتملة. قد يحمي القيم المستقبلية التي تُكتب بالمفتاح الجديد، لكنه لا يسترجع أو يمحو ما قرأه المهاجم مسبقاً. كما أنه لا يزيل web shell أو مهمة مجدولة أو إضافة معدلة أو جلسة مسروقة. ينتمي تدوير بيانات الاعتماد إلى مرحلة ما بعد حفظ الأدلة، وإلى جانب معالجة المضيف، لا بديلاً عنها.

من يجب أن يتحرك

على التجار الذين يشغّلون Adobe Commerce أو Magento Open Source حصر كل متجر، وكل نشر إقليمي، وموقع اختبار، ونسخة للتعافي من الكوارث، ونسخة تديرها جهة شريكة. قد تعرف الشركة متجرها الرئيسي وتغفل موقع علامة تجارية خاملاً، أو بوابة طلبات داخلية، أو نشراً سحابياً تديره وكالة. يجب أن يسجل الحصر فرع البرنامج الدقيق، وأسماء المضيفين العامة، وانكشاف GraphQL، وحالة الرقعة، والمالك، ووقت آخر مراجعة موثقة.

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

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

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

ما الذي لا ينبغي استنتاجه من الأدلة المتاحة

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

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

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

تسلسل عملي للاستجابة

بالنسبة إلى متجر لا يزال مكشوفاً، يمكن إسناد التسلسل بسهولة أثناء الحادث: حدّد النسخة والمالك، وقيّد الوصول إذا تعذر تطبيق الإصلاح فوراً، واحفظ السجلات ونسخة احتياطية سليمة، وطبّق إصلاح Adobe الخاص بـ CVE-2026-75650، وتحقق من النشر انطلاقاً من المصنّف العامل، ثم راجع إمكانية الوصول العامة مرة أخرى. لا تبدأ بإتلاف الأدلة أو بإعادة البناء من نسخة احتياطية لم يتم التحقق منها.

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

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

الدرس المفيد لأمن التجارة الإلكترونية

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

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

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

المصادر

أُسندت الوقائع المتعلقة بالنشرة والإصلاح إلى نشرة Adobe الأمنية APSB26-146 وملاحظات إصدار الإصلاح VULN-39341. واستندت التفاصيل التشغيلية والتنبيهات الإقليمية إلى المركز الأسترالي للأمن السيبراني ووكالة الأمن السيبراني في سنغافورة. كما يتناول تقرير Sansec عن StyleSmuggler نمط الاستغلال المرصود، بينما يقدّم سجل NVD للثغرة CVE-2026-75650 سياقاً إضافياً.