الثغرة في فقرة واحدة، والباقي إجراء
تخص النشرة SA-CONTRIB-2026-254 وحدة Commerce Core (drupal/commerce). تصنّفها drupal.org بأنها «Highly critical» بدرجة 21 من 25، وتصفها بأنها تجاوز للصلاحيات: فالوحدة لا تحمي بما يكفي بعض المسارات وبعض حقول الكيانات. وتذكر النشرة أن مستوى المصادقة المطلوب هو «الجميع/المجهولون»، وتوضح أن الثغرة قد تترتب عليها آثار مالية على البائع. كما تؤكد أنها مستغَلة فعليًا.
لا تسمّي النشرة المسارات ولا الحقول المعنية. لذلك لا نستنتج شيئًا: لا قائمة مسارات تُحجب، ولا توقيع يُبحث عنه في السجلات. المعرّف CVE-2026-118539 مأخوذ من صفحة النشرة؛ ولم نقارنه بقاعدة NVD، فاذكره بوصفه «المعرّف المنشور في النشرة» إلى أن تتم هذه المقارنة.
جدول مرجعي: الفرع، الإصدار المتأثر، الإصدار المصحَّح
مرّر الجدول أفقيًا
| وضعك | الحالة بحسب النشرة | الإجراء |
|---|---|---|
| Commerce 3.x، من 3.0.0 إلى ما قبل 3.3.13 | معرَّض للثغرة | الانتقال إلى 3.3.13 أو أحدث |
| Commerce 2.x (8.x-2.x)، قبل 8.x-2.41 | معرَّض للثغرة | الانتقال إلى 8.x-2.41 أو أحدث |
| Commerce 3.3.13 أو 8.x-2.41 مثبَّت مسبقًا | مصحَّح | دقّق مع ذلك الطلبات السابقة للتحديث |
| Drupal ^10.3 أو 11 | الفرع 3.x معلَن متوافقًا | التحديث داخل الفرع 3.x |
| Drupal ^9.3 أو ^10 | الفرع 2.x معلَن متوافقًا | التحديث داخل الفرع 2.x دون تغيير الفرع في الوقت نفسه |
| الوحدة غائبة عن `composer.lock` | خارج نطاق هذه النشرة | سجّل الغياب في الجرد |
| متجر بلا وصول إلى Composer أو بشيفرة منسوخة يدويًا | إصدار مجهول | اعرف الإصدار قبل أي استنتاج |
لماذا لا يكفي التصحيح
تقولها النشرة صراحة: على المواقع أن تدقق طلباتها، لأن الثغرة مستغَلة. المتجر الذي يُنقل اليوم إلى 3.3.13 ربما زِيرَ قبل ذلك. التحديث يغلق الباب، لكنه لا يصلح طلبًا عُدّل مبلغه أو حالته أو وضع دفعه. ولا تقول النشرة منذ متى بدأ الاستغلال: اختر نافذة تدقيق واسعة، واكتبها في الملف، ولا تختصرها في يوم التحديث.
ثم تأتي عقبة عادية: بلا جرد مركزي لا يعرف أحد أي المتاجر تضم Commerce، ولا في أي فرع. طريقة الجرد هي نفسها المتبعة مع ثغرة إضافة ووردبريس، وقد شرحناها في دليلنا عن Bricksforge. فترتيب العمل: الجرد، النسخة الاحتياطية، التحديث، التدقيق، الإثبات المؤرَّخ. وتأتي أولًا المتاجر التي تحصّل أكثر المدفوعات.
جرد إصدار Commerce في كل متجر
قراءة الإصدار بواسطة Composer
cd /var/www/boutique-clientcomposer show drupal/commerce
يعرض الأمر الإصدار المثبَّت. بالنسبة للفرع 2.x تتحدث drupal.org عن 8.x-2.41؛ أما Composer فيعرض الرقم دون البادئة 8.x. قارن الرقم لا السلسلة النصية. المسار مثال: كيّفه مع استضافتك.المقارنة مع Drush
drush pm:list --type=module --status=enabled --filter=commerce
تبيّن القائمة هل Commerce مفعَّل وبأي إصدار. قد يحمل الموقع الشيفرة دون تفعيل الوحدة: دوّن ذلك، فالوضع يتغير إن فعّلها أحدهم لاحقًا.قراءة ملف القفل بدل المجلد
grep -A1 '"name": "drupal/commerce"' composer.lock
يقول الملفcomposer.lockما هو مثبَّت فعلًا دون تشغيل Drupal. وهي القراءة الأسلم على متجر لا تريد إجهاده أثناء التدقيق.المرور على كل متاجر الخادم
find /home -name composer.lock -not -path '*/vendor/*' -exec grep -H -A1 '"name": "drupal/commerce"' {} +
كل ملف مذكور يحتوي Commerce، ويلي الاسمَ السطرُversion. راجع القائمة: مجلد اختبار منسي أو نسخة احتياطية يُحسبان أيضًا.تسجيل النتيجة في جدول
سطر لكل متجر: العميل، المستضيف، المسار، الفرع، الإصدار المرصود، إصدار Drupal، تاريخ القراءة ووقتها. أضف عمودين يُملآن لاحقًا: «التحديث تم» و«تدقيق الطلبات تم». يصبح هذا الجدول القطعة المركزية في الملف المسلَّم للعملاء.
النسخ الاحتياطي قبل لمس الشيفرة
يصعب التراجع عن تحديث وحدة دون نقطة عودة. قبل كل متجر: نسخة من قاعدة البيانات والشيفرة على وسيط لا يمسّه التحديث، مع تدوين تاريخها في الجدول. وفي متجر نشط تتغير القاعدة مع كل طلب: تثبّت النسخة الحالة التي ستقارن انطلاقًا منها الطلبات لاحقًا. لا تستبدلها بالتي تليها ما لم يُغلق التدقيق. تخدم مرتين: للرجوع إلى الوراء، ولإثبات ما كان يحتويه المتجر قبل الإصلاح.
تحديث متجر واحد
تثبيت الحالة
drush sql:dump --gzip --result-file=/chemin/sauvegarde/boutique-avant.sql
انسخ أيضًا مجلد المشروع: الشيفرة وcomposer.jsonوcomposer.lockوالملفات. دوّن في الجدول مكان النسخة.التحقق مما يسمح به قيد Composer
composer why-not drupal/commerce 3.3.13
إذا ثبّتcomposer.jsonإصدارًا معيّنًا فإن هذا الأمر يسمّي ما يمنع التحديث. المتجر على 2.x يبقى على 2.x ويستهدف 8.x-2.41: تغيير الفرع مشروع مستقل يُخطَّط له على حدة.تحديث الوحدة وتبعياتها
composer update drupal/commerce --with-dependencies
راجع قائمة الحزم المعدَّلة قبل التأكيد: قد تتحرك وحدة Commerce أخرى معها.تطبيق تحديثات قاعدة البيانات
drush updatedb -ydrush cache:rebuild
ينفّذ الأمر الأول تحديثات المخطط المعلقة، ويفرغ الثاني الذاكرة المؤقتة.التحقق من الإصدار المثبَّت
أعد تشغيل
composer show drupal/commerce. يجب أن يبلغ الإصدار 3.3.13 في الفرع 3.x، أو الرقم 2.41 في الفرع 2.x. دوّنه في الجدول مع التاريخ والوقت.إجراء طلب تجريبي
في بيئة ما قبل الإنتاج، أو في الوضع التجريبي لبوابة الدفع، أضف منتجًا إلى السلة وأتمّ الطلب وتحقق من المبلغ والحالة والدفع. التحديث الذي يعطّل مسار الشراء يجب أن يُكتشف قبل أن يكتشفه العميل.
إجراء لكل بيئة
لا يُطبَّق الإصلاح نفسه بالطريقة نفسها في كل مكان. يحدد الجدول التالي لكل بيئة الإجراء المنتظر والإثبات الواجب حفظه. وبيئة ما قبل الإنتاج العامة تُحسب متجرًا.
التحديثات التلقائية للنظام، الموصوفة في دليلنا عن Debian وUbuntu، لا تمس وحدة Drupal: يبقى هذا الإجراء من شأن الوكالة.
التطوير وما قبل الإنتاج والإنتاج: الإجراء والإثبات
مرّر الجدول أفقيًا
| البيئة | الإجراء | الإثبات الواجب حفظه |
|---|---|---|
| الإنتاج | نسخة احتياطية، تحديث، `drush updatedb`، طلب تجريبي، ثم تدقيق | نسخة مؤرَّخة، الإصدار المرصود، نتيجة التدقيق |
| ما قبل الإنتاج المتاح من الإنترنت | التحديث أولًا إن كانت الشيفرة مطابقة، أو حمايته بكلمة مرور في الأثناء | الإصدار المرصود، الحماية المعتمدة |
| ما قبل الإنتاج المغلق أو المحلي | التحديث وإعادة الطلب التجريبي قبل الإنتاج | لقطة للطلب التجريبي، التاريخ |
| التطوير | مواءمة `composer.lock` مع الإنتاج كي لا يعود الإصدار القديم في النشر التالي | إيداع ملف القفل، الإصدار المرصود |
| نسخة أو احتياطي مستعاد | لا تُعده إلى الخدمة دون التحديث | إشارة في ملف العميل |
تدقيق الطلبات دون افتراض أسلوب المهاجم
تحديد النافذة
اختر تاريخ بداية واسعًا ودوّنه. لا تعطي النشرة تاريخ بدء الاستغلال: خذ على الأقل الفترة التي تغطيها نسخك الاحتياطية وسجلاتك، واكتب السبب.
سرد طلبات النافذة
صدّر الطلبات برقمها وتاريخَي إنشائها وإتمامها وحالتها ومجموعها وعملتها. تكفي واجهة الإدارة. وفي قاعدة البيانات ابدأ بقراءة أسماء الأعمدة:
drush sql:query "DESCRIBE commerce_order"
تتوقف الأسماء الدقيقة على إصدارك: لا تفترضها.البحث عن التناقضات الداخلية
قارن في كل طلب المجموع بحساب بنوده وتعديلاته. مجموع لا يطابق بنوده، أو خصم لم يضبطه أحد، أو سعر بند يختلف عن الكتالوج: كل تناقض يستحق التحقيق.
المطابقة مع بوابة الدفع
طلب مكتمل بلا دفعة مقابلة لدى المزوّد، أو دفعة يختلف مبلغها عن المجموع، يستحق الفحص. كشف المزوّد هو المرجع للأموال المحصَّلة: أجرِ المطابقة على الملفات المصدَّرة لا على ما يعرضه المتجر.
مراجعة انتقالات الحالة
حدّد الطلبات التي تغيرت حالتها دون تدخل بشري ودون دفع متسق: مصادَق عليها دون المرور بالدفع، أو بلغت حالة نهائية في ثوانٍ. تساعد سجلات الوصول في تأريخ ما جرى. لا تفصّل النشرة أي مسار: البحث بالمسار قرينة لا دليل غياب.
ما لا يثبته التدقيق
التدقيق النظيف يقول إنه لا يظهر أي تناقض في الطلبات. ولا يقول إنه لم يُسَأ استخدام الثغرة بأي طلب: فالنشرة تتحدث عن مسارات وحقول كيانات دون تسميتها. اكتب في التقرير ما نظرت فيه وما لم تنظر فيه.
إذا وُجد طلب متناقض
- لا تحذف شيئًا — احتفظ بالطلب ودفعاته والنسخة المؤرَّخة: هي قطع الملف.
- أوقف التسليم — امنع الشحن أو الوصول إلى المنتج الرقمي إلى أن يتأكد الدفع لدى المزوّد.
- أبلغ عميل الوكالة — يذكر تقريرك الطلب والتناقض المرصود والتاريخ والمبلغ المعني.
- استعلم من مزوّد الدفع — فهو يحتفظ بكشف التحصيلات؛ اطلب تفاصيل المعاملة.
- احفظ السجلات — انسخ سجلات الوصول وسجلات التطبيق للفترة قبل تدويرها.
- راجع الحسابات — إذا وجدت حسابًا أو دورًا لم ينشئه أحد، فغيّر كلمات مرور الإدارة ومفاتيح البوابة.
- قدّر قبل أن تستعيد — العودة إلى نسخة سابقة للحادثة تمحو أيضًا الطلبات المشروعة التي تمت منذ ذلك الحين.
نشرات Commerce الأخرى في اليوم نفسه
في 28 أكتوبر 2026 نشرت drupal.org نشرات أخرى تمس منظومة Commerce، من الرقم 255 إلى الرقم 265: Commerce Core وCommerce Shipping وCommerce License وCommerce Stripe. هي مصنَّفة أقل خطورة من 254، والنشرة 254 وحدها تعلن استغلالًا فعليًا. غير أن إحداها، المتعلقة بـ Commerce Stripe، تبلغ «Critical» (15 من 25).
فلا تحدّث Commerce Core وحدها. اسرد حزم Commerce في كل متجر بالأمر composer outdated 'drupal/commerce*' واقرأ كل نشرة في drupal.org/security قبل أن تقرر.
من يتولى علاقة العميل، وماذا تسلّمه
حين يُعثر على طلب احتيالي يتصل العميل بالوكالة. احتفظ بهذا الدور: الوكالة تتولى العلاقة وتقرير التدقيق وقرار الاسترداد أو الاستعادة. والمنصة تتولى البنية التحتية: حساب معزول لكل عميل، ونسخ احتياطية قابلة للاستعادة، ووصول SSH أو WHM للتحديث دون انتظار تذكرة. لا نعدّل شيفرة تطبيق المتجر مكانك؛ وتحديث Commerce يبقى من شأن الوكالة.
سلّم العميل صفحة مؤرَّخة: الإصدار قبل التحديث وبعده، تاريخ التحديث ووقته، مرجع النسخة الاحتياطية، نافذة التدقيق، عدد الطلبات المفحوصة، التناقضات المكتشفة أو انعدامها، وما لم يُفحص. احتفظ بالنموذج: ستتبع النشرة التالية عن وحدة Drupal التسلسل نفسه، بسطر آخر في الجرد. ويوصف إيقاع المراجعة الشهرية في قائمة تدقيق VPS العميل.
