دليل تطبيقي لمسؤولي الخوادم ومزودي الاستضافة والمطورين

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

تزداد أهمية هذه الخطوات في خوادم الاستضافة المشتركة أو الخوادم التي تستضيف عشرات المواقع، لأن كل موقع قد يستخدم إصدار PHP أو إعدادات تشغيل مختلفة.

في هذا الدليل، نستعرض إجراءات معالجة الثغرتين CVE-2026-109618 وCVE-2026-109619 على خادم يعمل بنظام AlmaLinux 8.10 مع WHM/cPanel، مع التمييز بين التحديث الأمني وإعادة تشغيل الخدمة والتحقق من المواقع.

تنبيه: الأوامر الواردة مخصصة لمسؤول مخوّل بإدارة الخادم. يجب تنفيذها بحساب root أو من خلال واجهة WHM المناسبة، وبعد التأكد من أن الأمر ملائم لبيئة الخادم. لا تستخدم أوامر حذف أو تنظيف شاملة أثناء عملية التحديث لمجرد توفير مساحة.

المرحلة الأولى: تحديد نطاق المشكلة

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

لا تفترض أن إصدار PHP الافتراضي في سطر الأوامر هو الإصدار المستخدم في جميع المواقع.

1. التحقق من إصدار cPanel

نفّذ:

/usr/local/cpanel/cpanel -V

يعرض الأمر إصدار لوحة التحكم المثبتة. ويساعد ذلك في التأكد من أن الخادم يعمل بإصدار يدعم حزم PHP والتحديثات المتاحة من cPanel.

2. حصر حزم PHP المثبتة

استخدم:

rpm -qa | grep -E '^ea-php[0-9]+'

هذا الأمر يعرض الحزم المطابقة لفروع PHP التي تديرها cPanel.

وللتحقق من الحزم المعنية بالثغرات المحددة:

rpm -q ea-php81 ea-php82 ea-php83 ea-php84 ea-php85

قد تظهر رسالة تفيد بأن بعض الحزم غير مثبتة؛ وهذا ليس خطأ بحد ذاته، بل يعني أن تلك الحزم غير موجودة ضمن الحزم المثبتة حاليًا.

3. التحقق من الإصدار المصحح

الإصدارات التي أعلن عنها مشروع PHP بوصفها إصدارات إصلاح أولى للثغرتين هي:

فرع PHP الإصدار المصحح
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35

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

المرحلة الثانية: تحديث الحزم بالطريقة المناسبة لـ cPanel

في خادم يديره WHM/cPanel، من الأفضل استخدام آلية تحديث الحزم المعتمدة من cPanel، بدل تثبيت ملفات PHP يدويًا من مصدر غير متوافق مع النظام.

1. تحديث مكونات cPanel

بعد التأكد من توفر مساحة كافية على القرص ووجود نسخة احتياطية مناسبة، يمكن لمسؤول الخادم تشغيل آلية تحديث cPanel المعتمدة:

/usr/local/cpanel/scripts/upcp

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

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

يمكن متابعة السجل باستخدام:

tail -n 100 /var/cpanel/updatelogs/last

إذا لم يكن ملف السجل متاحًا بهذا الاسم في بيئتك، فافحص ملفات السجل الموجودة في مجلد /var/cpanel/updatelogs/ وحدد سجل آخر عملية تحديث.

2. تحديث حزم PHP عبر واجهة WHM

من واجهة WHM، افتح EasyApache 4، ثم راجع حزم PHP المثبتة والتحديثات المتاحة لها. طبّق التحديثات الأمنية التي يوفرها مستودع cPanel المعتمد، مع المحافظة على فروع PHP التي تحتاج إليها المواقع.

قد تختلف أسماء الخيارات أو ترتيبها باختلاف إصدار WHM.

لماذا لا نثبت PHP يدويًا من موقع php.net؟

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

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

3. التحقق من سجل الإصدار

بعد التحديث، تحقق من رقم الحزمة المثبتة:

rpm -q ea-php82

ويمكن التحقق من رقم الإصدار الذي تعرضه أداة PHP:

/opt/cpanel/ea-php82/root/usr/bin/php -v

المسار السابق خاص بفرع PHP 8.2 في بيئة cPanel. استبدل ea-php82 بالفرع الذي تريد التحقق منه.

لاحظ أن نتيجة php -v من سطر الأوامر لا تثبت وحدها أن جميع المواقع تستخدم الإصدار نفسه؛ لذلك نحتاج إلى التحقق من إعدادات المواقع أيضًا.

المرحلة الثالثة: التأكد من أن الإصلاح الأمني موجود في الحزمة

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

لهذا السبب، يفيد فحص سجل تغييرات الحزمة:

rpm -q --changelog ea-php82 | grep -A2 -B2 -E 'CVE-2026-109618|CVE-2026-109619'

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

يمكن تكرار الأمر مع الفروع الأخرى المثبتة:

rpm -q --changelog ea-php81 | grep -A2 -B2 -E 'CVE-2026-109618|CVE-2026-109619'
rpm -q --changelog ea-php83 | grep -A2 -B2 -E 'CVE-2026-109618|CVE-2026-109619'

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

المرحلة الرابعة: معرفة إصدار PHP الذي تستخدمه المواقع

هذه خطوة أساسية على الخوادم متعددة المواقع.

يمكنك استخدام واجهة WHM أو أدوات cPanel للتحقق من إصدارات PHP المرتبطة بالمواقع الافتراضية.

في بيئة تدعم استدعاء WHM API من سطر الأوامر، يمكن تنفيذ:

whmapi1 php_get_vhost_versions

تعرض النتيجة معلومات عن المواقع الافتراضية وإصدار PHP المرتبط بكل منها، وقد تتضمن حالة PHP-FPM.

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

ومن المهم التفريق بين ثلاثة أمور:

  • الإصدار الافتراضي لسطر الأوامر: الذي يظهر عند تشغيل php -v.
  • إصدار PHP المرتبط بالموقع: الذي تحدده إعدادات cPanel لكل نطاق.
  • طريقة تشغيل PHP: مثل PHP-FPM أو CGI أو غيرهما.

هذه إعدادات مختلفة، وقد لا تتطابق نتائجها. لا تغيّر إعدادات SAPI أو طريقة تشغيل المواقع لمجرد أن نتيجة أمر واحد تبدو مختلفة عن المتوقع؛ بل تحقق من إعدادات الموقع الفعلية.

المرحلة الخامسة: إعادة تشغيل PHP-FPM عند الحاجة

بعد تحديث الحزمة، قد تحتاج الخدمات التي تستخدم PHP-FPM إلى إعادة تشغيل حتى تتوقف العمليات القديمة وتبدأ العمليات الجديدة باستخدام الملفات المحدثة.

في cPanel، يمكن التحقق من حالة الخدمة باستخدام:

/usr/local/cpanel/scripts/restartsrv_apache_php_fpm --status

إذا كان التحديث يتطلب إعادة تشغيل PHP-FPM، وكان ذلك مناسبًا لبيئة الخادم، يمكن استخدام:

/usr/local/cpanel/scripts/restartsrv_apache_php_fpm --hard

الأمر الثاني ينفّذ إعادة تشغيل قسرية لخدمة PHP-FPM التابعة لـ Apache في cPanel. وقد يؤثر ذلك مؤقتًا في الطلبات النشطة، لذلك يُفضّل تنفيذه في وقت مناسب، مع مراقبة حالة المواقع بعده.

لا تنفّذ إعادة تشغيل عشوائية لجميع الخدمات لمجرد الاحتياط. حدّد الخدمة التي تستخدم الحزمة المحدثة واتبع تعليمات cPanel ذات الصلة.

بعد إعادة التشغيل، أعد التحقق من الحالة:

/usr/local/cpanel/scripts/restartsrv_apache_php_fpm --status

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

المرحلة السادسة: التحقق بعد التحديث

ينبغي أن تشمل عملية التحقق ما يلي:

  1. رقم الحزمة: تأكد من أن حزم PHP المستهدفة محدثة.

  2. سجل التغييرات: تحقق من وجود إشارة واضحة إلى الإصلاح الأمني عند الحاجة.

  3. إصدارات المواقع: راجع جميع النطاقات المرتبطة بالخادم، وليس الموقع الرئيسي فقط.

  4. حالة PHP-FPM: تأكد من أن الخدمة تعمل بعد إعادة التشغيل.

  5. اختبار المواقع: افتح صفحات تسجيل الدخول والصفحات الديناميكية والنماذج والواجهات التي تعتمد على PHP.

  6. السجلات: راجع سجلات Apache وPHP-FPM وسجلات التطبيقات بحثًا عن أخطاء جديدة بعد التحديث.

  7. الخدمات المرتبطة: تحقق من المهام المجدولة والتكاملات وواجهات API التي تعتمد على PHP.

يجب إجراء الاختبارات من خلال بيئة تشغيل المواقع الفعلية. فنجاح أمر php -v في الطرفية لا يضمن وحده أن إصدار الويب المستخدم في جميع النطاقات قد تغير.

المرحلة السابعة: متابعة الثغرات الجديدة بعد إغلاق الثغرتين

إغلاق الثغرتين CVE-2026-109618 وCVE-2026-109619 لا يعني أن كل مخاطر PHP المستقبلية قد انتهت.

في 23 أكتوبر 2026، أشار المركز الكندي للأمن السيبراني إلى ثغرة إضافية هي CVE-2026-115560، مرتبطة بظروف محددة تتعلق بإعدادات الجلسات وتغيير معالج التسلسل أثناء تشغيل التطبيق.

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

session.upload_progress.enabled=0

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

المرحلة الثامنة: التعامل مع الإصدارات القديمة

إذا كان أحد المواقع يستخدم PHP 8.1 أو إصدارًا أقدم، فلا تفترض أن تثبيت الإصلاحات على PHP 8.2 أو 8.3 يعالج ذلك الموقع تلقائيًا.

يجب تحديد ما إذا كان المورد يقدم إصلاحًا رجعيًا موثوقًا للإصدار القديم. وإذا لم يكن الإصدار مدعومًا، فالأفضل التخطيط للانتقال إلى إصدار مدعوم ومتوافق مع التطبيق.

قبل الترقية الرئيسية، اختبر التطبيق والإضافات في بيئة تجريبية إن أمكن؛ فقد تؤثر تغييرات PHP في الدوال القديمة أو المكتبات أو التطبيقات غير المحدثة.

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

المرحلة التاسعة: ماذا لو اشتبهنا في استغلال سابق؟

تثبيت التحديث يعالج الثغرة في النسخة المحدثة، لكنه لا يثبت أن الخادم لم يتعرض لهجوم قبل التحديث.

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

من مؤشرات تستحق التحقيق:

  • عمليات غير متوقعة تُشغّلها عمليات PHP أو خادم الويب.
  • ملفات جديدة أو معدلة في مجلدات المواقع دون سبب معروف.
  • ارتفاع غير معتاد في أخطاء HTTP 500 أو انهيارات عمليات PHP.
  • طلبات HTTP غير مألوفة أو اتصالات صادرة غير مبررة.
  • تغييرات غير مصرح بها في الحسابات أو ملفات الإعدادات أو المهام المجدولة.

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

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

المرحلة العاشرة: قائمة تحقق نهائية لمسؤول الخادم

 

  • صر جميع فروع PHP المثبتة.
  • صر جميع المواقع وإصدارات PHP المرتبطة بها.
  • ثبيت الإصلاحات الأمنية من مستودعات cPanel المعتمدة.
  • لتحقق من رقم الحزمة وسجل التغييرات.
  • عادة تشغيل الخدمات المتأثرة عند الحاجة.
  • لتأكد من أن PHP-FPM والخدمات المعنية تعمل.
  • ختبار الوظائف الأساسية للمواقع.
  • راجعة السجلات بعد التحديث.
  • تابعة التنبيهات الأمنية الجديدة، بما فيها CVE-2026-115560.
  • لتخطيط لترقية الفروع التي وصلت إلى نهاية الدعم.
  • لاحتفاظ بنسخة احتياطية وخطة استعادة مجرّبة.

خاتمة

تحديث PHP في خادم إنتاج ليس مجرد تغيير رقم إصدار؛ بل عملية تشمل تحديد نطاق التأثر، وتحديث الحزم بطريقة صحيحة، والتحقق من إعدادات المواقع، وإعادة تشغيل الخدمات المطلوبة، ثم اختبار النتيجة ومراقبة السجلات.

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