إضافة السيو لديك وزّعت باباً خلفياً. التحديث ليس استعادة.

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

أعلنت Rank Math في 16 أكتوبر أن بعض نسخ Rank Math SEO PRO 3.0.123 التي تم تنزيلها أو تحديثها تلقائياً بين 15 أكتوبر الساعة 20:02 UTC و16 أكتوبر الساعة 07:12 UTC كانت تحتوي على شيفرة خبيثة. الحالة مسجلة باسم CVE-2026-111862 بتقييم 9.8. النسخة السليمة 3.0.124 صدرت. عند هذه الجملة تتوقف معظم الوكالات عن القراءة، ومن هنا تبدأ الحادثة فعلاً.

نافذة الإحدى عشرة ساعة

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

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

ما فعلته النسخة الخبيثة فعلاً

بحسب إشعار المورّد وتحليل Wordfence، كانت النسخة النشطة المتأثرة قادرة على:

• إنشاء وصول دائم والتواصل مع خادم أوامر خارجي على rank1cdn[.]com؛
• إعادة بناء بابها الخلفي المخفي عند كل زيارة صفحة، بحيث لا ينهي حذف الحمولة الوصول وحده؛
• إنشاء حسابات مدير مزيفة، غالباً بأسماء تبدأ بـ wpsupport_ أو بريد ينتهي بـ @wp-mail[.]net؛
• كشف بيانات دخول ووردبريس وقاعدة البيانات ومفاتيح التشويش في wp-config.php ومفاتيح الدفع وSMTP وAPI، وأي سر يستطيع خادم الويب قراءته؛
• زرع ملف مزيف في نواة النظام، وشيفرة PHP موزعة في mu-plugins ومجلدات inc للقوالب ومجلد الرفع، وقواعد .htaccess تنفّذ ملفات .cache كـ PHP؛
• تسجيل مهام cron على الخادم موسومة بـ #ms6v46، إضافة إلى صفوف في قاعدة البيانات بأسماء مثل _uf6qdn2hmm.

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

التحديث نظافة، وليس استجابة للحوادث

هذه هي الجملة المهمة في كل محادثة مع عميل هذا الأسبوع: إذا كانت نسخة متأثرة نشطة على موقع، فتعامل مع الموقع كمخترق واستعده من نسخة احتياطية أُخذت قبل 15 أكتوبر الساعة 20:02 UTC.

تثبيت 3.0.124 يغيّر الملفات على القرص. لا يزيل المدير المزيف، ولا صفوف wp_options المحقونة، ولا مدخلات cron، ولا توجيه .htaccess، ولا النسخة المشفرة أثناء النقل من بيانات دخولك على خادم شخص آخر. الباب الخلفي الذي يعيد بناء نفسه عند تحميل الصفحة لا يهمه أن صفحة الإضافة تقول الآن "أحدث إصدار".

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

الجزء الذي لا يُدرج في الميزانية: الثقة

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

حوادث سلسلة التوريد هذا العام تكرر النقطة نفسها من زوايا مختلفة: النشر الموثوق في npm، وبيانات OAuth مسروقة من مورّد نسخ احتياطي، والآن قناة تنزيل إضافة مدفوعة. العامل المشترك ليس استغلالاً ذكياً. إنه خط ثقة مخترق مرة واحدة ثم استخدامه على نطاق واسع.

في aratech نتعامل مع تحديثات الإضافات والاعتماديات كتغيير مُدار، لا كراحة خلفية:

1. لقطة قبل النافذة. نقطة استعادة لقاعدة البيانات والملفات لكل موقع، تُؤخذ تلقائياً وتُحفظ بعد دورة التحديث.
2. طرح متدرج. تجربة على موقع منخفض الحركة، ثم المحفظة كلها. هكذا تحصل النسخة الخبيثة على مضيف واحد، لا أربعين.
3. انضباط الخروج. قوائم وجهات مسموحة في حسابات الاستضافة. وجهة جديدة مثل rank1cdn[.]com إشارة مرئية، إذا كنت تراقب حركة الخروج.
4. جرد للأسرار. إذا لم تستطع حصر كل بيانات دخول يستطيع الموقع قراءتها، فلن تستطيع تدويرها في ساعة عند الحاجة.
5. فحوص سلامة لاحقة. wp core verify-checksums والتحقق من بصمات الإضافات، مع مقارنة بقائمة ملفات سليمة معروفة.

لا شيء من هذا غريب. كله ممل، ولهذا يعمل.

قائمة الفحص للمواقع التي تديرها

إذا كانت ووردبريس مصدر رزقك، فهذه أقصر نسخة مفيدة:

1. تحقق مما إذا ثُبّتت 3.0.123 ومتى. سجلات التنزيل، وتواريخ الملفات، وسجلات الاستضافة أو النسخ الاحتياطي.
2. إذا كانت النسخة المتأثرة نشطة، استعد الملفات وقاعدة البيانات من حالة قبل 15 أكتوبر الساعة 20:02 UTC، ثم ثبّت 3.0.124 من حسابك.
3. إذا اضطررت للتنظيف في المكان: احذف مجلد rank-math-pro بالكامل (إلغاء التنشيط لا يكفي)، وأزل صفوف wp_options المعروفة، واحجب حركة الخروج إلى rank1cdn[.]com، ثم ابحث عن بقية المؤشرات.
4. دقّق حسابات المديرين. ابحث عن حسابات wpsupport_ ورسائل غير متوقعة وتغييرات في التحقق بخطوتين.
5. دوّر كل سر يستطيع الموقع الوصول إليه: كلمات مرور ووردبريس وقاعدة البيانات، ومفاتيح التشويش، ومفاتيح API والدفع، ولوحة الاستضافة، وSFTP وSSH.
6. راقب عودة الملفات المحذوفة. الاستمرارية التي تعالج نفسها ستعود خلال يوم إذا فوّتت موضع تثبيت واحد.

ماذا يعني هذا لعملك

إذا كنت مؤسساً تقرأ هذا صباح الاثنين، فالسؤال العملي ليس "هل نحن على 3.0.124". السؤال هو: "من في فريقي يعرف أي الإضافات حُدّثت الأسبوع الماضي، وماذا يحدث في الساعة الأولى بعد اكتشاف أن إحداها كانت عدائية؟"

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

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

سلسلة توريد إضافاتك أصبحت جزءاً من سطح هجومك. تعامل مع زر التحديث كما هو: عملية نشر.