تبدأ حماية ووردبريس في هذا الحادث بتأكيد تصحيح PHP مع مسؤول الاستضافة، ثم اختبار الموقع والإضافات والوظائف التي يعتمد عليها العمل. حدّد من ينفّذ التحديث، ومن يفحص التوافق، ومن يعتمد النتيجة. وإذا كان الموقع متجر ووكومرس (WooCommerce)، أضف الدفع ورسائل الطلب ومطابقة السجلات إلى خطة التحقق نفسها.
راجعنا المصادر في 23 أكتوبر 2026. يحوّل هذا الدليل إرشادات الحادث العامة إلى طلب صيانة مناسب لووردبريس، مع توزيع واضح للمسؤوليات. القوائم والسيناريوهات التالية اختبارات قبول مقترحة تعدّلها بحسب موقعك، وليست نتائج فحص أجريناه أو دليلًا على وقوع اختراق في منشأتك.
يوجّه تنبيه ووردبريس الرسمي إلى تحديث PHP، ويؤكد عدم الحاجة إلى إصدار ووردبريس مخصص لهاتين الثغرتين أو التخطيط له. لذلك اطلب دليل المعالجة من مسؤول بيئة التشغيل، حتى لو أظهرت لوحة الإدارة أن الإضافات محدّثة. لكل مسار تحديث سجلّه ومن يؤكد اكتماله.
يتعلق الإعلان الأصلي بالثغرتين CVE-2026-109618 وCVE-2026-109619. يجمع دليل الحادث وإصدارات PHP المصححة تفاصيل الإصدارات وحزم المورّدين. احتفظ به مرجعًا إلى جانب قائمة ووردبريس، واطلب من الفريق الرجوع إلى النشرة الحالية عند اتخاذ القرار بدل الاعتماد على صورة قديمة لرقم الإصدار.
ويصف تنبيه PHP في 23 أكتوبر، المرتبط بالمعرّف CVE-2026-115560، حالة غير معتادة تجمع تغيير معالج الجلسات مع تتبع تقدم الرفع. اطلب تقييم انطباقها على التركيب الفعلي؛ لا يثبت التنبيه أن كل مواقع ووردبريس تستخدم هذه الحالة. وثّق قرارها مستقلًا عن التصحيح الأصلي.
ابدأ بطلب واحد يتضمن رابط الموقع، ومرجع حساب الاستضافة عبر قناة الدعم الخاصة، وإصدار PHP إن عرفته، والوظائف التي لا يستطيع العمل الاستغناء عنها. اذكر إن كان الموقع يستقبل طلبات متجر أو نماذج مبيعات. لا تضع كلمات مرور أو مفاتيح خدمات أو بيانات عملاء في الرسالة الأولى.
يمكنك استخدام هذه الصياغة المقترحة: «نحتاج تأكيد حزمة PHP التي تخدم هذا النطاق، ومرجع التنبيه الذي تعالجه، ووقت بدء تشغيل النسخة المصححة، وأي بيئة مرتبطة بالموقع ما زالت معلقة. نرجو أيضًا تقييم تنبيه 23 أكتوبر وتوضيح العمل المطلوب من مسؤول ووردبريس لدينا». عدّل التفاصيل بحسب طريقة دعم المزوّد.
إذا وصل رد مختصر يقول «تم التحديث»، فاطلب تحديد الموقع والبيئة التي فُحصت. نسخة المعاينة، ونسخة النقل القديمة، والموقع الذي يستقبل الزوار تحتاج أسماء واضحة في السجل. اسأل من سينسّق أي انقطاع ومن سيرسل دليل الاكتمال. ويساعدك دليل مسؤوليات الاستضافة والصيانة على ربط هذه الأسئلة بالعقد الذي تشتريه فعليًا.
أين تجد معلومات PHP داخل ووردبريس؟
تشير نشرة ووردبريس إلى المسار أدوات ← صحة الموقع ← معلومات ← الخادم لمعرفة الإصدار الظاهر. دوّن معه اسم النطاق والتاريخ وهل الفحص على الإنتاج أم التجربة. استخدم معلومات لوحة الاستضافة كمصدر إضافي عند توفرها، ثم اطلب من المزوّد تفسير أي اختلاف بين النتيجتين.
الرقم الظاهر بداية للحصر. يحتاج سجل الإغلاق إلى تحديد حزمة المورّد المناسبة والخدمة التي تستخدمها أمام الزوار. لا تنشر صفحة تشخيص عامة تعرض إعدادات داخلية، ولا ترسل ملف معلومات كاملًا إلى أشخاص لا يحتاجونه. شارك البيانات اللازمة فقط عبر القناة المتفق عليها مع المسؤول.
عندما يقول المزوّد إن حزمة ذات رقم أقدم تتضمن تصحيحًا منقولًا، اطلب معرّف الحزمة ومرجع نشرته. وعندما يطلب المطوّر ترقية كبيرة بسبب إضافة أو قالب، اطلب توضيح التوافق المطلوب. سجّل القرارين منفصلين، مع اسم صاحب المهمة وكيف ستتحقق من نتيجتها قبل إغلاق الطلب.
اكتب توزيع العمل قبل تحديد موعد التنفيذ. قد تتولى شركة واحدة عدة أدوار، لكن سمّ المسؤول عن كل قرار والنتيجة التي ستستلمها منه. يمكنك تحويل الجدول المقترح التالي إلى صفحة افتتاحية في تذكرة الصيانة، وإضافة اسم الشخص وموعد المراجعة بحسب اتفاقكم.
| العمل المطلوب | المسؤول الذي تسمّيه | الدليل الذي تحتفظ به |
|---|---|---|
| حزمة PHP والخدمة العاملة | مشغّل الاستضافة | مرجع التصحيح والحزمة وتأكيد البيئة الفعلية |
| توافق القالب والإضافات | مسؤول ووردبريس | الإصدارات المختبرة والاعتماديات المعلقة |
| الصفحات والنماذج والنشر | مسؤول المحتوى | النتائج المتوقعة والفعلية في اللغتين |
| الدفع ومعالجة الطلبات | مسؤول المتجر | سجلات الاختبار وقرار مطابقة الطلبات |
| الانقطاع أو الاستعادة | صاحب صلاحية الاعتماد | وقت التنفيذ وشروط التوقف ومسؤول الاستعادة |
حدّد من يستطيع إيقاف التغيير إذا تعطلت وظيفة أساسية، ومن يعتمد تأجيل مشكلة شكلية. مثلًا، يختلف أثر نموذج مبيعات لا يرسل عن اختلاف بسيط في تباعد النص. ضع الوظائف المهمة في أعلى القائمة، وأبلغ الشخص الذي يملك قرار العمل بموعد الاختبار كي لا ينتظر الفريق موافقة مجهولة المصدر.
ابدأ بحصر وظيفة كل إضافة، ومصدر تنزيلها، وصاحب الترخيص، ومسؤول تجديده وصيانته. أضف الإصدار الذي ستختبره والصفحات أو التكاملات التي تعتمد عليه. قبل حذف إضافة تبدو غير مستخدمة، راجع النماذج قليلة الزيارات، وصفحات اللغة الأخرى، والمهام التي تعمل في أوقات محددة ولا تظهر عند فتح الصفحة الرئيسية.
جهّز نسخة تجريبية محمية متى توفرت، وراجع اتصالاتها قبل تشغيل الاختبارات. اتفق على طريقة اختبار البريد والدفع وربط نظام العملاء والشحن، حتى لا تؤدي التجربة إلى رسالة أو طلب فعلي غير مقصود. استخدم سجلات اختبار ممثلة للوظيفة وبأقل قدر لازم من البيانات الشخصية، ووضّح للفريق كيف يميّز النسخة التجريبية عن الموقع الحقيقي.
يشرح دليل تقوية ووردبريس الرسمي مسؤوليات الاستضافة والتطبيق ومصادر البرمجيات والوصول والاستعادة. حوّل هذه المبادئ إلى قائمة تغييرات تخص موقعك. اترك إعادة التصميم والأفكار الجديدة لعملها المتفق عليه، إلا إذا كانت معالجة التوافق تتطلب تعديلًا بعينه قبل تشغيل البيئة المصححة.
إذا لم تتوفر نسخة تجربة، سجّل هذا القيد وناقش ما يمكن فحصه مسبقًا وكيف ستعمل الاستعادة وما الانقطاع المحتمل. لا تجعل غياب بيئة مريحة للاختبار سببًا لتأجيل المعالجة بلا موعد أو مسؤول. اطلب من المشغّل قرارًا واضحًا يناسب التعرض الحالي وإرشادات المورّد، مع توثيق ما تعذّر التحقق منه.
ما الوظائف التي تختبرها في موقع الشركة؟
اختر مهامًا ينفّذها موظفوك وزوارك بالفعل. في موقع يعتمد على النشر، اطلب من الكاتب إنشاء مسودة، ومن المحرّر مراجعتها، ومن صاحب الصلاحية نشرها. افتح النتيجة بحساب زائر غير مسجّل، وراجع الصور والتنقل والبحث والانتقال بين الصفحة العربية ونظيرتها الإنجليزية.
في نموذج التواصل، جرّب استفسارًا صحيحًا ومحاولة تنقصها خانة إلزامية. تحقّق من الرسالة التي يراها الزائر ومن وصول الاستفسار إلى وجهة الاختبار المتفق عليها. ظهور عبارة نجاح على الشاشة لا يكفي لإثبات وصول الطلب إلى فريق المبيعات. وإذا كان النموذج يدعم المرفقات فعلًا، أضف ملف اختبار مناسبًا ضمن الحدود المتفق عليها.
اكتب النتيجة المتوقعة قبل بدء الاختبار. عبارة «النموذج يعمل» لا توضح ما فُحص؛ أما «وصل الاستفسار مرة واحدة إلى الصندوق المحدد وبالحقول المرسلة» فتتيح مقارنة واضحة. احتفظ بمعرّف التجربة ووقتها ونتيجتها، وتجنب إدراج بيانات شخصية لا حاجة لها في الصور. كرر الفحوص المختارة بعد تغيير الإنتاج وفسّر أي فرق عن النسخة التجريبية.
أبقِ رحلة المتجر ضمن تذكرة الصيانة نفسها. حتى أكتوبر 2026، يوصي دليل تحديث WooCommerce بنسخة احتياطية حديثة وتجربة التحديث وفحص وظائف المتجر المهمة. الجدول التالي سيناريو قبول مقترح؛ عدّله بحسب بوابة الدفع والشحن وطريقة متابعة الطلبات في منشأتك.
| حالة الاختبار | النتيجة التي تتفق عليها مسبقًا |
|---|---|
| المنتج والسلة وعنوان التسليم | بقاء المنتج والكمية وخيار التسليم المناسب بصورة صحيحة |
| دفع تجريبي ناجح | تسجيل الطلب المتوقع مرة واحدة وربطه بعملية الاختبار |
| دفع مرفوض أو ملغى | ظهور الرسالة المناسبة ومعالجة الطلب وفق السياسة المتفق عليها |
| إشعار حالة الدفع | توافق سجل المتجر مع سجل الاختبار دون إجراء مكرر غير مقصود |
| رسالة الطلب والمخزون | وصول الرسالة للمستلم التجريبي واتباع قواعد المخزون المعتمدة |
| صفحة الدفع باللغتين | وضوح الحقول والتنبيهات والتأكيد على شاشة هاتف |
استخدم بيئة الاختبار التي تدعمها البوابة على نسخة محمية. نجاح الدفع التجريبي يثبت نتيجة في ذلك الإعداد، ولا يتحقق تلقائيًا من بيانات الدخول للإنتاج أو جميع مسارات الدفع الحقيقية. اتفق مع مسؤول المتجر ومشغّل الدفع على طريقة مناسبة للتحقق في الإنتاج قبل اعتماد التغيير، وحدّد من يراجع النتيجة المالية والتشغيلية.
راجع أيضًا ما يحدث للطلبات التي تدخل أثناء نافذة التغيير. قبل استعادة قاعدة البيانات، حدّد آخر نسخة موثوقة، ومن سيطابق الطلبات والمدفوعات وتحديثات التجهيز اللاحقة معها. قد تنجح الاستعادة تقنيًا ويبقى اختلاف يحتاج معالجة في سجلات العمل. ينبغي أن يشارك مسؤول الطلبات في هذا القرار إلى جانب الشخص الذي يعيد الملفات والبيانات.
اطلب تجربة استعادة في بيئة منفصلة وسجلًا يوضح ما استعيد وما لم ينجح. دوّن مكان الاستعادة وبيانات الوصول اللازمة والشخص المصرّح له باستخدامها. اتفق على مدة الاحتفاظ بالنسخ وتكرار تجارب الاستعادة بحسب احتياج الموقع والخدمة المشتراة. وجود مهمة نسخ مجدولة لا يساوي وجود تجربة تعافٍ موثّقة يستطيع موظف آخر تنفيذها.
راجع الحسابات المسماة في ووردبريس ولوحة الاستضافة ومسجّل النطاق. نظّم إلغاء وصول المورّد السابق ضمن تسليم معروف، واحتفظ بمعلومات الاستعادة تحت سيطرة المنشأة. افصل مهام النشر اليومية عن إدارة النظام متى سمح توزيع الأدوار، وحدّد من يستقبل تجديد تراخيص الإضافات وتنبيهات مورّديها حتى لا تتوقف التحديثات على بريد شخص غادر الفريق.
تدخل هذه القرارات في تسليم الموقع أيضًا. يساعدك دليل ملكية ووردبريس ومسؤوليات صيانته عند مقارنة إبقاء التركيب الحالي بتكليف فريق بعمل أوسع. احتفظ بقائمة الوصول والتراخيص ومهام الصيانة مع مستندات المنشأة، وحدّث أسماء أصحابها عندما يتغير الفريق أو المورّد بدل انتظار حادث جديد لكشف الفراغ.
اتفق مسبقًا على شروط إيقاف التغيير: تعطل نموذج أساسي، أو اختلاف نتيجة الدفع، أو ظهور دليل يحتاج تحقيقًا. احتفظ بسجل التغييرات واطلب من المشغّل المسؤول تحديد الإجراء التالي. لا تجعل الرجوع التلقائي إلى بيئة معرضة للثغرة هو الرد الوحيد على صفحة توقفت عن العمل؛ ناقش الاحتواء ومعالجة التوافق وفق الحالة.
تتناول إرشادات NCSC للحادث، التي راجعناها في أكتوبر 2026، الاحتواء عند تعذر المعالجة العاجلة وتقييم الاختراق عندما يتعذر التحديث أو التعطيل سريعًا. إذا ظهرت حسابات غير متوقعة أو ملفات معدّلة أو أدلة أخرى تثير الاشتباه، استعِن بمسؤول مؤهل للاستجابة للحادث. نجاح الدفع وتثبيت التصحيح لا يثبتان عدم وقوع اختراق سابق.
اطلب سجلًا واحدًا يضم الموقع المقصود، ودليل بيئة التشغيل، وتغييرات التطبيق، ومرجع النسخة الاحتياطية، ونتائج الاختبارات، والعمل المعلق وأسماء مسؤوليه. أرفق تقييم التنبيه اللاحق بصورة مستقلة. إذا لم يُنفّذ اختبار، اكتب أنه غير مختبر مع سبب القيد؛ لا تحوّل عدم ظهور شكوى إلى نتيجة نجاح في التسليم.
الخلاصة العملية: أكّد إصلاح الاستضافة، واختبر الوظائف التي تجلب الاستفسارات أو تعالج الطلبات، ثم سمّ مسؤول الصيانة التالية. لا يكفي أن تبدو لوحة الإدارة مرتبة؛ ينبغي أن يوضح المستند ماذا تغيّر وكيف تحققت منه المنشأة. احتفظ به في مكان يصل إليه من سيتولى المهمة عند غياب المسؤول الحالي.
نحدد عمل صيانة ووردبريس وتسليمه وفق تركيب موقعك وتغيير PHP المناسب وفحوص التطبيق ووظائف الأعمال المتفق عليها. تتضمن خدمة ووردبريس تسليمًا يوثّق مسؤوليات التحديث والنسخ الاحتياطي وبيانات الدخول، ونتفق على الرعاية المستمرة الأوسع بنطاق مستقل. نراجع التوافق مع الفريق المعني، ونسجّل نتيجة التحقق والعمل الإضافي المطلوب بوضوح.
اطلب فحص أمان موقعك. أرسل الرابط وشركة الاستضافة وإصدار PHP إن عرفته والنماذج أو مسارات الدفع المهمة، واذكر وجود اشتباه باختراق. نؤكد النطاق والموعد والسعر بعد المراجعة. نحدد التحقيق وتنظيف الشيفرة الضارة والتعديلات الكبيرة والصيانة المستمرة منفصلة حيث يلزم، ونتفق على وسيلة آمنة لمشاركة الوصول بعد تعريف العمل، دون إرسال أسرار في الطلب الأول.
