PHP2Shell: ثغرتا PHP الحرجتان وكيف تحمي خادمك

في 21/10/2026، الساعة 18:00 بتوقيت دبي، أصدر فريق PHP تحديثات طارئة لأربعة فروع دفعة واحدة، لثغرتين حرجتين بدرجة 9.2 على مقياس CVSS 4.0 سمّاهما الباحثون PHP2Shell. الثغرتان تسمحان بـ تنفيذ الأوامر عن بُعد دون تسجيل دخول، وتقعان في نواة PHP نفسها لا في إطار عمل أو إضافة، وPHP تشغّل قرابة 70% من المواقع التي تُعرف لغة خادمها بحسب W3Techs. أوقفت مؤسسة Wikimedia عدداً من خدماتها احتياطاً، وأغلقت جهات حكومية في أوروبا وكندا بوابات رسمية حتى رقّعتها، ورصدت مصائد Amazon أول محاولة استغلال قبل الإعلان بأربعة أيام. في هذا المقال: ما الذي حدث يوماً بيوم، وكيف تعمل الثغرتان، وكيف تفحص خادمك وترقّعه أو تحميه مؤقتاً، وكيف تبحث عن أثر اختراق، ثم كيف تعاملنا معها في إليفانتي.

01ما الذي حدث، يوماً بيوم

بدأت القصة في صيف 2026، حين وجد باحث من شركة Calif إحدى الثغرتين أثناء تدقيق شيفرة PHP بمساعدة نموذج ذكاء اصطناعي، ووصل فريق من Wiz إليهما مستقلاً بأدوات مماثلة، وأُبلغ فريق أمان PHP ضمن إفصاح منسق. وWiz هي التي سمّتهما PHP2Shell، لأن نهاية الاستغلال سطر أوامر على الخادم. ثم جرت الأحداث أسرع من الخطة:

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

02كيف تعمل الثغرتان

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

CVE-2026-109618: ذاكرة نصف مهيأة

حين يصل نموذج POST، يحوّل PHP حقوله إلى المصفوفة $_POST ويخزنها في جدول تجزئة. في الكود المتأثر يزيد PHP عداد العناصر قبل أن يحجز ذاكرة المفتاح الجديد، فإن تجاوز الحجز قيمة memory_limit توقف الإدخال وبقيت خانة محسوبة لم تُهيأ قط. وعند إنهاء الطلب يمرّ PHP على كل الخانات المحسوبة ليحررها، فيقرأ ما بقي في تلك الخانة من بايتات قديمة. والمهاجم يصمم طلب multipart يستنزف الذاكرة في اللحظة المناسبة، ويرتب ما يبقى فيها، فيقود دالة التنظيف إلى تنفيذ أمر من اختياره.

CVE-2026-109619: حالة عالقة بين طلبين

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

• تتبع تقدم رفع الملفات: خاصية session.upload_progress مفعّلة افتراضياً، وتعمل حتى لو لم يستدعِ تطبيقك session_start. ثبت الاستغلال عبرها على mod_php وعلى PHP-FPM.
• تتبع الأخطاء القاتلة في PHP 8.5: الإعداد fatal_error_backtraces مفعّل افتراضياً في هذا الفرع، وثبت الاستغلال عبره على mod_php.

وما يصعّب الاكتشاف أن الاستغلال الناجح لا يُسقط العامل بالضرورة: في مختبر Datadog عاد الرد بالرمز 200 واستمر العامل في عمله. فغياب الانهيارات من سجلاتك ليس دليلاً على السلامة.

03من المتأثر

كل تثبيت PHP يخدم طلبات ويب متأثر، أياً كانت واجهة SAPI التي تربطه بخادم الويب: PHP-FPM، وApache مع mod_php، وphp-cgi، وFrankenPHP، وLiteSpeed. ويصنف فريق PHP mod_php الأعلى خطراً، لأن الاستغلال فيه يكتمل بطلب مجهول قبل أي كود للتطبيق. والثغرتان تطالان كل الإصدارات من 5.4 حتى 8.5:

وانتبه إلى ثلاث حالات يضلّلك فيها الفحص السريع:

• سطر الأوامر غير الموقع: الأمر php -v يقرأ نسخة CLI، والموقع قد يعمل بإصدار آخر عبر FPM أو LiteSpeed أو PHP Selector.
• الترقيع دون تغيير الرقم: التوزيعات وCloudLinux ومزودو الدعم الممتد يرقّعون أحياناً مع إبقاء رقم الإصدار، فالمعيار سجل تغييرات الحزمة لا الرقم.
• PHP المضمّن: الحاويات وبعض الأجهزة والتطبيقات تحمل نسختها الخاصة من PHP، ولا يصلها تحديث نظام التشغيل.

04افحص خادمك ورقّعه

ابدأ بالخوادم المكشوفة للإنترنت، وبأي خادم يعمل بـ mod_php. الخطوة الأولى أن تعرف ما الذي يخدم موقعك فعلاً، ثم أن تبحث عن رقمي الثغرتين في سجل تغييرات الحزمة:

# الإصدار وواجهة التشغيل كما يراهما موقعك، لا سطر الأوامر (احذف الملف فور الفحص)echo '<?php echo PHP_VERSION, " ", PHP_SAPI, " upload_progress=", ini_get("session.upload_progress.enabled");' | sudo tee /var/www/html/ver-91c.php >/dev/nullcurl -s https://dukkan-jbeil.com/ver-91c.php; echosudo rm /var/www/html/ver-91c.php# Debian وUbuntu: هل تحمل الحزمة الإصلاح؟ غيّر 8.3 إلى فرعكapt changelog php8.3-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]'# RHEL وAlmaLinux وCloudLinux: حزمة النظام، ثم حزمة alt-php لكل فرع تستخدمهrpm -q --changelog php-cli | grep -E 'CVE-2026-10961[89]'rpm -q --changelog alt-php74-common | grep -E 'CVE-2026-10961[89]'

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

# Debian وUbuntu: حدّث، ثم أعد تشغيل كل ما يشغّل PHP (عدّل الأسماء لخادمك)sudo apt update && sudo apt upgradesudo systemctl restart php8.3-fpm apache2# RHEL وAlmaLinuxsudo dnf upgrade 'php*'sudo systemctl restart php-fpm httpd# cPanel مع CloudLinux: حزم EasyApache وalt-php، ثم Apache وPHP-FPMsudo dnf clean all && sudo dnf upgrade 'ea-php*' 'alt-php*'sudo /scripts/restartsrv_httpd && sudo /scripts/restartsrv_apache_php_fpm# LiteSpeed: أعد تشغيل الخادم، ثم عمليات lsphp المنفصلة التي تبقى حية بعدهsudo /usr/local/lsws/bin/lswsctrl restartsudo touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt# Docker: أعد البناء بسحب الصورة الأساسية المرقّعة، فإعادة التشغيل لا تكفيdocker compose build --pull && docker compose up -d

المشكلةحدّثت PHP وما زال فحص الويب يعرض الإصدار القديم

الحلالعمّال القديمة ما زالت في الذاكرة. أعد تشغيل PHP-FPM أو Apache، وفي LiteSpeed أعد تشغيل عمليات lsphp المنفصلة أيضاً.

المشكلةالأمر php -v يعرض إصداراً مرقّعاً والموقع يعمل بإصدار آخر

الحلسطر الأوامر غير الذي يخدم الموقع. افحص عبر الويب، وحدّث الإصدار المختار في لوحة التحكم أو في إعداد الخادم.

المشكلةرقم الإصدار بعد التحديث أقدم من أرقام الجدول

الحلحزم التوزيعات وCloudLinux ترقّع أحياناً دون تغيير الرقم. ابحث عن رقمي الثغرتين في سجل تغييرات الحزمة.

المشكلةأعدت تشغيل الحاوية وما زالت مكشوفة

الحلالحاوية تعمل من الصورة نفسها. أعد البناء بسحب الصورة الأساسية المرقّعة، ثم انشر الصورة الجديدة.

المشكلةنموذج رفع يُرسل من نطاق آخر صار مرفوضاً بعد قواعد WAF الجديدة

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

05إن لم تستطع التحديث اليوم

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

• عطّل تتبع تقدم الرفع: اضبط session.upload_progress.enabled على 0 في php.ini أو في إعداد مجمع FPM، ثم أعد تشغيل كل العمّال. يغلق ذلك المسار المعروف لـ CVE-2026-109619 ومسار CVE-2026-115560 أيضاً، ولا يكفي فيه ini_set ولا ملف .user.ini.
• في PHP 8.5: اضبط fatal_error_backtraces على 0، فهو يغلق مسار تتبع الأخطاء القاتلة وحده.
• قلّص حجم الطلب: post_max_size بـ 8M إن لم تحتج رفع ملفات أو 32M إن احتجته، وupload_max_filesize أصغر منه، مع حدود في خادم الويب أو الوكيل لعدد الحقول والأجزاء والترويسات، تسري حتى حين يغيب Content-Length.
• memory_limit بقيمة -1، بحذر: يمنع الاستنزاف الذي تحتاجه CVE-2026-109618، لكنه يترك الذاكرة بلا سقف، فاقرنه بحد ذاكرة للحاوية أو cgroup يقتل العامل المتأثر وحده. ولا تستخدم RLIMIT_AS أو RLIMIT_DATA، فهما يستدعيان فشل الحجز نفسه.
• قواعد WAF: نشرت Cloudflare وAWS WAF وImunify360 قواعد في جدار حماية تطبيقات الويب تحجب أدوات الاستغلال المعروفة. هذا ترقيع افتراضي يصد ما يشبه الأدوات المنشورة، ولا يغطي مسار استنزاف الذاكرة.
• الفصل عن الإنترنت: إن تعذر كل ما سبق، فقد أوصت FBI وCERT-EU بعزل التطبيق عن الشبكة العامة أو إيقافه حتى يُرقّع.

# /etc/php/8.3/fpm/pool.d/www.conf: إجراءات مؤقتة حتى تحدّث، لا بديل عن التحديثphp_admin_value[session.upload_progress.enabled] = 0# PHP 8.5 وحدهphp_admin_value[fatal_error_backtraces] = 0# 8M دون رفع ملفات، أو 32M إن احتجته، والملف الواحد أصغر من الطلبphp_admin_value[post_max_size] = 8Mphp_admin_value[upload_max_filesize] = 6M# nginx، داخل كتلة server: الحد نفسه قبل أن يصل الطلب إلى PHPclient_max_body_size 8m;# ثم أعد تشغيل كل العمّال، واقرأ القيمة الفعلية عبر الويب كما في الفحص أعلاهsudo systemctl restart php8.3-fpm nginx

06هل اختُرق خادمك؟

التحديث يغلق الباب، ولا يُخرج من دخل قبله. والاستغلال يمر بمراحل تترك أثراً في السجلات حتى حين ينجح دون انهيار:

• استنزاف قبل أي سكربت: رسالة Allowed memory size التي تنتهي بـ in Unknown on line 0 تعني أن الذاكرة نفدت أثناء تهيئة الطلب. دفعة قصيرة منها على عامل واحد علامة تحضير للهجوم، مع أن الاستنزاف وحده لا يثبت هجوماً.
• انهيار العمّال: رسائل Segmentation fault أو SIGSEGV في سجل Apache أو FPM خلال الفترة نفسها.
• طلبات رفع شاذة: حقلا PHPSESSID وPHP_SESSION_UPLOAD_PROGRESS في صفحات لا ترفع ملفات، أو آلاف الأجزاء في طلب واحد، أو أسماء ملفات تحوي <?php أو |O:.
• عامل ويب يشغّل shell: أوضح دليل على الإطلاق: apache2 أو php-fpm أو lsphp أباً لعملية sh أو bash أو curl.

# استنزاف الذاكرة أثناء تهيئة الطلب: عدد الرسائل التي تنتهي بـ Unknown on line 0sudo grep -h "Allowed memory size" /var/log/php*-fpm.log /var/log/nginx/error.log /var/log/apache2/error.log 2>/dev/null | grep -c "Unknown on line 0"# انهيارات العمّال، آخر 20 منهاsudo grep -hE "Segmentation fault|SIGSEGV" /var/log/php*-fpm.log /var/log/apache2/error.log 2>/dev/null | tail -n 20# ملفات PHP جديدة أو معدّلة منذ 17/10: راجع القائمة سطراً سطراًsudo find /var/www -type f -name '*.php' -newermt 2026-10-17 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort# عمليات shell أو تنزيل يشغّلها عامل ويب الآنps -ef --forest | grep -A3 -E 'php-fpm|apache2|httpd|lsphp' | grep -E ' (sh|bash|curl|wget|nc) '

07كيف تعاملت إليفانتي مع PHP2Shell

خوادم استضافة cPanel في إليفانتي تعمل بنظام CloudLinux وخادم الويب LiteSpeed وحزمة Imunify360، ويختار كل عميل إصدار PHP لموقعه من 5.6 حتى 8.5 عبر PHP Selector. معنى ذلك أن على خوادمنا فروعاً لم يصدر لها PHP نفسه أي إصلاح، فلم يكن انتظار الإصدار الرسمي خياراً. وهكذا جرت المتابعة:

1. 01الإنذار: التقط فريق مراقبة الخوادم الإعلان المسبق في 20/10، وبدأ جرد الإصدارات وواجهات التشغيل على كل خادم قبل أن تصدر التفاصيل.
2. 02الحماية قبل الترقيع: وصلت قواعد Imunify360 إلى الخوادم تلقائياً، وكانت تحجب أداة الاستغلال المنشورة قبل الإصدار الرسمي بنحو ساعة.
3. 03الترقيع: ثبّتنا حزم alt-php وea-php المرقّعة فور وصولها إلى المستودعات المستقرة، ثم أعدنا تشغيل كل عمليات lsphp ليُحمَّل الكود الجديد.
4. 04التحقق: لم نكتفِ برقم الإصدار: بحثنا عن رقمي الثغرتين في سجل تغييرات كل حزمة، وفحصنا الإصدار الذي يخدم المواقع فعلاً.
5. 05التقصي: راجعنا سجلات الأخطاء والعمليات منذ 17/10 بحثاً عن العلامات السابقة، وفحص Imunify360 ملفات المواقع بحثاً عن أبواب خلفية.

ولم يحتج أي عميل استضافة إلى تغيير إصدار PHP أو تعديل كود موقعه. وهذا ما جعل ذلك ممكناً:

Imunify360: حماية قبل صدور الترقيع

تصل قواعد Imunify360 إلى الخوادم دون تدخل منا. صدرت المجموعة 8.83 الساعة 13:08 بتوقيت دبي يوم 21/10، فحجبت طلب الاستغلال المنشور على Apache وnginx، ثم 8.84 الساعة 17:07، فحجبت أداة الاستغلال على كل خوادم الويب بما فيها LiteSpeed، أي قبل الإصدار الرسمي بـ 53 دقيقة. وتبعتها مجموعات أغلقت النسخ المعدّلة من الأداة، وصولاً إلى 8.88 في 23/10، مع تحدي CAPTCHA للعناوين التي تفحص الخوادم أو تحاول الاستغلال. ونحن نعامل هذه القواعد على حقيقتها: ترقيع افتراضي اشترى ساعات، لا بديل عن الإصلاح، فهي لا تغطي مسار استنزاف الذاكرة.

CloudLinux: ترقيع كل الإصدارات، حتى القديمة

هنا الفرق الأكبر. PHP نفسه رقّع أربعة فروع، وترك 7.4 و8.0 و8.1 برقع مصدرية، وما قبلها بلا شيء. أما CloudLinux فأوصلت حزم ea-php المرقّعة من 5.2 حتى 8.5 إلى المستودع المستقر قبل الواحدة من فجر 22/10 بتوقيت دبي، وحزم alt-php لكل الفروع من 5.2 حتى 8.5 في الرابعة من فجر اليوم نفسه. فبقي موقع يعمل بـ PHP 7.4 على 7.4، مرقّعاً، دون ترقية قسرية قد تكسر كوده.

وعزل CloudLinux يحدّ من الضرر إن نجح هجوم قبل الترقيع. ينفّذ الاستغلال أوامره بصلاحيات العامل، أي بمستخدم حساب الموقع، وCageFS يحبس هذا المستخدم في نظام ملفات خاص به، فلا يرى ملفات الحسابات الأخرى على الخادم. وتقنية LVE تضع سقفاً لمعالج كل حساب وذاكرته، فطوفان طلبات الاستنزاف على موقع واحد لا يُبطئ جيرانه.

المتابعة على مدار الساعة

الأحداث لم تنتظر ساعات الدوام: الإصدار الرسمي في السادسة مساءً بتوقيت دبي، وحزم alt-php في الرابعة فجراً، وتحذير CVE-2026-115560 بعد يومين. مراقبة الخوادم والشبكة لدينا تعمل 24/7، فطُبّق كل تحديث حين وصل، لا صباح اليوم التالي. وإن كان لديك CoreVPS بصلاحيات root فإصدار PHP عليه بيدك: الأوامر أعلاه تكفيك، وحزمة الأمان Imunify360 + CloudLinux تجلب لخادمك القواعد نفسها والحزم المرقّعة نفسها، وفريق الدعم الفني معك على مدار الساعة إن احتجت يداً.

08ما بعد PHP2Shell

الترقيع أغلق المسارين المعروفين، لكن Datadog ترى أن النمط الذي أنتجهما، أي تحديث بيانات وصفية قبل حجز الذاكرة التي تصفها، ما زال في الكود، وتتوقع ظهور حالات جديدة منه. وCVE-2026-115560 ينتظر إصلاحه في الإصدار التالي. ثلاث خطوات تجعل المرة القادمة أسهل:

1. 01جرد دائم: اعرف لكل خادم وحاوية إصدار PHP الذي يخدم الطلبات، ومصدر حزمته، ومن يحدّثه. الجرد الذي تبنيه أثناء الأزمة يأتي متأخراً.
2. 02فرع مدعوم: خطط الآن للخروج من 8.1 وما قبلها، ومن 8.2 قبل نهاية دعمه في 31/12/2026، أو اعتمد مزوداً يرقّع فروعك القديمة كما فعلت CloudLinux.
3. 03تتبع تقدم الرفع معطلاً: أبقه كذلك ما لم يعتمد عليه تطبيقك فعلاً، فهو المسار المشترك بين ثغرتين من الثلاث.

وأعد تشغيل العمّال بعد كل تحديث لـ PHP كأنه جزء من التحديث نفسه، لا خطوة تتذكرها لاحقاً.