OUFRIDعماد أوفريد

🛡️ ثغرة حرجة في PHP ‏(PHP2Shell): كيف تعرف إن كان موقعك معنيًّا وكيف تحميه

🌐 Français · English · العربية

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

آخر تحديث: 22 أكتوبر 2026

باختصار

1. ماذا حدث؟

في 21 أكتوبر 2026، نشر فريق PHP نشرة أمنية بعنوان «ثغرات حرجة لتنفيذ الشيفرة عن بُعد، حدِّثوا الآن». وهي تصلح ثغرتين منفصلتين، تقييم كل منهما 9.2 من 10 (وفق CVSS v4):

الثغرةطبيعتها (دون تفاصيل تقنية)النشرة الرسمية
CVE-2026-109618تلف في البيانات الداخلية عند نفاد ذاكرة PHPGHSA-w8hw-w9fx-j79w
CVE-2026-109619حالة داخلية تبقى من طلب إلى الطلب الذي يليهGHSA-6wmf-4rv5-p3rp

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

من المعرَّض للخطر: حسب النشرة الرسمية، كل تثبيت لـ PHP يخدم صفحات الويب، أيًّا كان نمط التشغيل: PHP-FPM، أو Apache مع mod_php، أو php-cgi، أو FrankenPHP، أو LiteSpeed. ويرى فريق PHP أن الخطر أعلى مع mod_php.

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

الإصدارات المصحَّحة:

وماذا عن الإصدارات الأقدم؟ لم يعد PHP 8.1 وما قبله يتلقى تحديثات رسمية. ومع ذلك قدّم فريق PHP إصلاحات مصغّرة للإصدارات 7.4 و8.0 و8.1 لتوزيعات لينكس والجهات التي توفر دعمًا ممتدًّا. عمليًّا، إذا كان خادمك يستخدم PHP الذي توفره توزيعة لينكس (AlmaLinux أو Rocky أو Red Hat أو Debian أو Ubuntu…)، فالمهم هو تحديث حزمة التوزيعة، لا رقم الإصدار الظاهر. على سبيل المثال، أصدرت AlmaLinux منذ 21 أكتوبر تحديثًا لحزمة PHP 8.0 يصلح الثغرتين، بينما بقي الرقم «8.0.30» على حاله.

للتذكّر. ينتهي دعم PHP 8.2 في 31 ديسمبر 2026. إذا كنت ما زلت على 8.2 أو أقدم، فهذه هي اللحظة المناسبة للتخطيط للانتقال إلى 8.3 أو أحدث.

2. هل أنا معنيّ؟

يتوقف الجواب على طريقة استضافة موقعك. ابحث عن حالتك.

الاستضافة المشتركة (cPanel وPlesk وhPanel…)

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

  1. تحقق من الإصدار المختار لموقعك في لوحة التحكم: «Select PHP Version» أو «MultiPHP Manager» في cPanel، و«PHP Settings» في Plesk، و«PHP Configuration» في hPanel. سجّل الفرع (8.1 أو 8.2 أو 8.3…).
  2. إذا كنت على 8.1 أو أقدم، انتقل إلى 8.3 أو أحدث، بعد التأكد من أن قالبك وإضافاتك تدعمه (انظر أدناه).
  3. راسل الدعم الفني لمزوّد الاستضافة: «هل طبّقتم إصلاحات PHP الصادرة في 21 أكتوبر 2026 ‏(CVE-2026-109618 وCVE-2026-109619) على خادمي؟». المزوّد الجادّ يجيب بوضوح وبسرعة. وإن لم يفهم ما تتحدث عنه، فتلك معلومة ثمينة عن مدى موثوقيته.

موقع ووردبريس

في لوحة التحكم: أدوات ← صحة الموقع ← معلومات ← الخادم. يبيّن سطر «إصدار PHP» الإصدار الذي يستخدمه موقعك. في الاستضافة المشتركة، لا يكشف هذا الرقم دائمًا إن كان الإصلاح مطبَّقًا (انظر الملاحظة حول التوزيعات أعلاه): عند الشك، اسأل مزوّد الاستضافة.

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

خادم VPS أو خادم مخصّص

أنت المسؤول عن الإدارة: الأمر بين يديك. الفخ الرئيسي أن الخادم قد تُثبَّت عليه عدة إصدارات من PHP في الوقت نفسه، وأن الأمر php -v لا يُظهر إلا إصدار سطر الأوامر، وليس بالضرورة الإصدار الذي يخدم مواقعك.

تحقق بهذا الترتيب:

1. الإصدارات المثبَّتة:

# AlmaLinux, Rocky, Red Hat
rpm -qa | grep -E '^php[0-9]*(-php)?-(common|fpm)'

# Debian, Ubuntu
dpkg -l | grep -E 'php[0-9.]*-(common|fpm)'

2. خدمات PHP-FPM العاملة (هي التي تشغّل مواقعك فعليًّا):

systemctl list-units --type=service --state=running | grep -i php

3. أي إصدار يخدم كل موقع: راجع إعدادات خادم الويب لتعرف إلى أي «مجمّع» (pool) من PHP-FPM يرسل كل موقع طلباته، ثم إلى أي إصدار ينتمي هذا المجمّع. في لوحات مثل Virtualmin وcPanel وPlesk، تظهر هذه المعلومة أيضًا في إعدادات كل نطاق.

4. التحديثات المتاحة:

# AlmaLinux, Rocky, Red Hat
dnf check-update 'php*'

# Debian, Ubuntu
apt update && apt list --upgradable | grep -i php

إذا ظهر تحديث لـ PHP، فاعتبر نفسك معنيًّا حتى يثبت العكس.

عادة يجب التخلي عنها: صفحة phpinfo العلنية

لمعرفة الإصدار، ينشئ كثيرون ملف info.php يحتوي على phpinfo(). لا تتركه منشورًا أبدًا. فهذه الصفحة تعرض الإصدار الدقيق والامتدادات ومسارات الخادم وجزءًا من الإعدادات: خريطة ثمينة لأي مهاجم. إن اضطررت لاستخدامها، فلثوانٍ معدودة ثم احذف الملف. شاشة «صحة الموقع» في ووردبريس أو سطر الأوامر خياران أفضل بكثير.

3. الإصلاح

التحديث

على خادم VPS، يكفي أمر واحد:

# AlmaLinux, Rocky, Red Hat
dnf upgrade 'php*'

# Debian, Ubuntu
apt update && apt install --only-upgrade 'php*'

قبل ذلك، إذا كنت تدير مواقع مهمة، خذ نسخة احتياطية (قاعدة البيانات والملفات). نادرًا جدًّا ما يُعطِب تحديثُ إصلاحٍ داخل الفرع نفسه (مثلًا من 8.3.35 إلى 8.3.36) شيئًا، لكن النسخة الاحتياطية لا تكلّف سوى دقائق.

إعادة تشغيل PHP: الخطوة التي ينساها الجميع

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

systemctl restart php-fpm            # the exact name depends on your setup
systemctl restart php8.3-fpm         # Debian, Ubuntu

ومع mod_php، أعد تشغيل Apache.

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

ps -eo pid,lstart,cmd | grep "php-fpm: master"

يجب أن يكون وقت البدء لاحقًا لوقت التحديث. على أنظمة Red Hat ومشتقاتها، يعرض الأمر dnf needs-restarting -s أيضًا الخدمات التي ما زالت تستخدم إصدارات قديمة.

فحص كل موقع

لا تكتفِ بالصفحة الرئيسية، فهي كثيرًا ما تُقدَّم من ذاكرة التخزين المؤقت. لكل موقع، اختبر:

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

4. التخفيف إن تعذّر التحديث فورًا

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

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

5. هل تعرّضتُ للاختراق؟

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

find /path/to/site -name '*.php' -newermt '2026-10-20' -not -path '*/cache/*'

في ووردبريس، وجود ملف PHP داخل wp-content/uploads مريب في أغلب الأحيان.

إن عثرت على شيء: لا تكتفِ بحذف الملف. ضع الموقع في وضع الصيانة، وغيّر كل كلمات المرور (الإدارة وقاعدة البيانات وFTP والاستضافة)، واستعد نسخة احتياطية سليمة سابقة للحادث إن توفرت، وحدّث كل شيء، ثم راقب. وإن لم تكن واثقًا، فاستعن بمحترف: فالتنظيف الجزئي كثيرًا ما يترك بابًا خلفيًّا مفتوحًا.

6. كي لا تُفاجأ مرة أخرى

التحديثات الأمنية التلقائية

على الخادم، فعّل التثبيت التلقائي للإصلاحات الأمنية:

الفخ الذي اكتشفته

على خادم أتولى إدارته، لا يأتي PHP من التوزيعة، بل من مستودع خارجي واسع الانتشار (مستودع Remi Collet)، يتيح تثبيت عدة إصدارات حديثة من PHP. ينشر هذا المستودع إصلاحاته بسرعة، لكنه لا يصنّفها «تحديثات أمنية» في البيانات الوصفية التي تقرؤها الأدوات التلقائية. والنتيجة: إعداد «تثبيت التحديثات الأمنية فقط» كان سيتجاهل إصلاح PHP2Shell، بينما يبدو الخادم محميًّا.

الحل الذي اعتمدته وأوصي به:

  1. مهمة ليلية تطبّق الإصلاحات الأمنية للتوزيعة و، بشكل صريح، تحديثات حزم PHP ‏(dnf upgrade --security ثم dnf upgrade 'php*')؛
  2. إعادة تشغيل تلقائية لـ PHP-FPM كلما حُدِّث PHP؛
  3. فحص كل موقع بعد العملية، مع تنبيه إذا توقف أحدها عن الاستجابة.

تحديثات الإصلاح داخل الفرع نفسه من PHP مصمَّمة كي لا تُعطِب شيئًا، فأتمتتها أمر معقول؛ أما الانتقال بين الفروع (من 8.3 إلى 8.4 مثلًا) فيبقى قرارًا يُتَّخذ يدويًّا بعد الاختبار.

متابعة الإعلانات

قائمة التحقق

الأسئلة الشائعة

هل موقعي على ووردبريس معنيّ حتى لو كان محدَّثًا؟

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

هل يتكفّل مزوّد الاستضافة بذلك تلقائيًّا؟

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

حدّثت PHP، هل هذا كافٍ؟

فقط إذا أُعيد تشغيل PHP بعد ذلك. فما دامت عمليات PHP-FPM (أو Apache مع mod_php) لم تُعَد تشغيلها، يواصل الإصدار القديم المعرَّض للخطر خدمة صفحاتك.

الأمر php -v يعرض إصدارًا قديمًا، فهل أنا معرَّض للخطر حتمًا؟

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

هل يحميني تعطيل session.upload_progress؟

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

ما زلت على PHP 7.4 أو 8.0، ماذا أفعل؟

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

كيف أعرف إن كانت هناك محاولة لاستغلال الثغرة على موقعي؟

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

المصادر

هل تحتاج مساعدة؟

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

→ كل الأدلة

→ كل الأدلة