دليل عملي

PHP2Shell: إصلاح CVE-2026-109618 وCVE-2026-109619

الأمان والمراقبة9 دقائق للقراءةعدد الخطوات: 13

في 21 أكتوبر 2026، نشر فريق أمن PHP على وجه الاستعجال الإصدارات ‎PHP 8‎.5‎.12 و‎8‎.4‎.27 و‎8‎.3‎.36 و‎8‎.2‎.35. تُصلح هذه الإصدارات ثغرتين أُطلق عليهما اسم «PHP2Shell»: CVE-2026-109618 وCVE-2026-109619، وقد حصلت كلٌّ منهما على ‎9‎.2 من 10 وفق CVSS ‎4‎.0. تستهدف الثغرتان المفسِّر نفسه لا تطبيقًا بعينه: يكفي طلب HTTP واحد مجهول المصدر، حتى قبل أن تبدأ شيفرتك في التنفيذ. وقد رُصدت محاولات استغلال منذ يوم النشر. إليك ما تفعله هاتان الثغرتان، وكيف تعرف ما إذا كانت خوادمك مكشوفة، وكيف تصلحهما على Debian وUbuntu وRHEL وcPanel وDocker.

المحتويات· PHP2Shell باختصار1/14
  1. 01PHP2Shell باختصار
  2. 02ما يجب تذكّره
  3. 03لماذا تشكّل هاتان الثغرتان خطرًا كبيرًا
  4. 04أي إصدار تثبّت حسب فرعك
  5. 05تحقّق مما إذا كانت خوادمك مكشوفة
  6. 06جرد إصدارات PHP المخدومة
  7. 07طبّق التصحيح
  8. 08حدّث PHP حسب بيئتك
  9. 09إذا لم تتمكن من التحديث فورًا
  10. 10أضف حاجزًا أمام PHP
  11. 11ابحث عن آثار الاستغلال
  12. 12فحوص يجب إجراؤها بعد التصحيح
  13. 13على الاستضافة المشتركة
  14. 14التوثيق الرسمي

PHP2Shell باختصار

ليست PHP2Shell ثغرة في WordPress أو Laravel أو في إضافة ما: المشكلة في محرّك PHP نفسه. لذا فإن كل تطبيق PHP يستجيب لطلبات الويب معنيّ بها، أيًّا كانت شيفرته. ويذكر التنبيه الأمني كلًّا من PHP-FPM وApache مع mod_php وphp-cgi وFrankenPHP وLiteSpeed.

تشترك الثغرتان في آلية واحدة. فعندما يقطع PHP طلبًا بشكل مفاجئ (نفاد الذاكرة، خطأ فادح)، قد يترك خلفه حالة داخلية مهيّأة جزئيًّا أو محرَّرة مسبقًا. ثم يعيد طلب لاحق، يعالجه عملية PHP نفسها، استخدام تلك الحالة: وهذا ما يفتح الباب أمام تنفيذ شيفرة عن بُعد.

ما يجب تذكّره

  • CVE-2026-109618 — تلف في الذاكرة عند تجاوز memory_limit: بيانات طلب مهيّأة جزئيًّا تُعامَل لاحقًا على أنها صالحة أثناء التنظيف.
  • CVE-2026-109619 — حالة عامة منتهية الصلاحية: حالة خاصة بطلب ما تبقى بعد تحرير ذاكرته، ويمكن أن يقرأها الطلب التالي على العملية نفسها.
  • الدرجة: ‎9‎.2 من 10 وفق CVSS ‎4‎.0 لكل منهما، دون الحاجة إلى مصادقة أو تفاعل من المستخدم.
  • الإصدارات المصحَّحة: ‎PHP 8‎.5‎.12 و‎8‎.4‎.27 و‎8‎.3‎.36 و‎8‎.2‎.35. لم يعد المشروع ينشر إصدارات للفرع ‎8‎.1 والفروع الأقدم.
  • الاستغلال: تفيد watchTowr برصد محاولات استغلال في مصائدها الشبكية منذ 21 أكتوبر 2026.
  • النطاق: يقدّر الباحثون أن الفروع المتأثرة تعود حتى ‎PHP 5‎.4، دون أن يُختبر كل إصدار على حدة.

لماذا تشكّل هاتان الثغرتان خطرًا كبيرًا

تتطلب معظم ثغرات الويب نموذجًا محددًا أو حسابًا أو إضافة معرّضة للخطر. أما PHP2Shell فلا تحتاج إلى أي من ذلك: المحفّز الأكثر شيوعًا هو معالجة إرسال من نوع multipart/form-data مع تتبّع تقدّم الجلسات (session.upload_progress)، وهي آلية يفعّلها PHP افتراضيًّا وتُنفَّذ قبل أول بايت من تطبيقك. لذلك فإن جدار حماية تطبيقات مدمجًا في شيفرتك، أو إضافة أمان لـ WordPress، أو middleware في Laravel، كلها تصل بعد فوات الأوان.

العامل الثاني هو نموذج التنفيذ نفسه. إذ يعيد PHP-FPM وApache استخدام العملية نفسها لمئات الطلبات المتتالية: وهذا تحديدًا ما يسمح لطلب مفخّخ بأن يلوّث الطلب الذي يليه. ووفقًا لـ Imperva، تتراوح التقنيات المنشورة بين إسقاط العملية وقراءة ملفات عشوائية عبر ذاكرة OPcache المؤقتة، مرورًا بتسريب نحو 67 كيلوبايت من ذاكرة العملية داخل ملف تعريف ارتباط PHPSESSID متضخّم. وقد تحتوي هذه الذاكرة على كلمات مرور قاعدة البيانات أو مفاتيح API.

أي إصدار تثبّت حسب فرعك

مرّر الجدول أفقيًا

فرع PHPالإصدار المصحَّحما العمل
‎8‎.5‎8‎.5‎.12التحديث ثم إعادة تشغيل PHP
‎8‎.4‎8‎.4‎.27التحديث ثم إعادة تشغيل PHP
‎8‎.3‎8‎.3‎.36التحديث ثم إعادة تشغيل PHP
‎8‎.2‎8‎.2‎.35التحديث، ثم التخطيط للانتقال إلى ‎8‎.3 أو ‎8‎.4
‎8‎.1، ‎8‎.0، ‎7‎.4لا يوجد إصدار رسميحزمة مصحَّحة من توزيعتك، أو نقل عكسي للتصحيح من المصدر، وإلا فالانتقال
‎7‎.3 وما قبلها، ‎5‎.xلم يُنشر أي تصحيحالانتقال إلى فرع مدعوم

تحقّق مما إذا كانت خوادمك مكشوفة

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

جرد إصدارات PHP المخدومة

  1. اعرض الإصدارات المثبّتة

    على Debian أو Ubuntu:

    dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'php*' | awk '$1=="ii"' | grep -E 'php[0-9.]+-(fpm|cli|common)|libapache2-mod-php'

    على RHEL أو AlmaLinux أو Rocky Linux:

    rpm -qa 'php*' 'ea-php*' 'alt-php*' | sort
  2. حدّد عمليات PHP قيد التشغيل

    systemctl list-units --type=service --state=running | grep -E 'php|apache2|httpd|lsws'

    كل خدمة phpX.Y-fpm نشطة هي إصدار يجب التحقق منه وتصحيحه.

  3. اقرأ الإصدار الذي يخدم موقعًا ما

    ضع ملفًا مؤقتًا في جذر الموقع، واستعلم عنه، ثم احذفه فورًا:

    echo '<?php echo PHP_VERSION, " ", PHP_SAPI;' > /var/www/monsite/v-check.php
    curl -s https://monsite.example/v-check.php
    rm /var/www/monsite/v-check.php

    تشير نتيجة مثل 8.3.36 fpm-fcgi إلى إصدار مصحَّح يخدمه PHP-FPM.

  4. افحص حاويات Docker

    docker ps --format '{{.Names}}' | while read c; do echo "$c: $(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null)"; done

    الحاوية التي لا تحتوي على PHP لا تعرض شيئًا بعد اسمها.

طبّق التصحيح

تلقّت توزيعات Linux ومزوّدو الدعم الممتد التصحيحات قبل النشر. لذلك لا تحمل الحزمة المصحَّحة في توزيعتك بالضرورة الرقم ‎8‎.3‎.36: فمثلًا تُصلح Ubuntu ‎24‎.04 إصدارها ‎8‎.3‎.6 ضمن الحزمة 8.3.6-0ubuntu0.24.04.13. اعتمد على التنبيه الأمني الخاص بتوزيعتك بدلًا من رقم إصدار PHP وحده. وفي جميع الأحوال، إعادة التشغيل ضرورية: فما دامت العمليات القديمة تعمل، فإن الشيفرة القديمة هي التي تستجيب.

حدّث PHP حسب بيئتك

  1. Debian وUbuntu

    sudo apt update
    sudo apt install --only-upgrade $(dpkg-query -W -f='${db:Status-Abbrev} ${Package}\n' 'php*' | awk '$1=="ii"{print $2}')
    sudo systemctl restart 'php*-fpm'
    sudo systemctl restart apache2   # if you use mod_php

    إذا كانت إصداراتك تأتي من مستودع خارجي (مثل PPA ondrej/php)، فتحقّق من أن الإصدار المثبّت بعد التحديث هو فعلًا إصدار مصحَّح.

  2. RHEL وAlmaLinux وRocky Linux

    sudo dnf upgrade 'php*'
    sudo systemctl restart php-fpm
    sudo systemctl restart httpd

    نشرت AlmaLinux حزمها المصحَّحة في 21 أكتوبر 2026. أما مستودع Remi المجتمعي فلم يكن يوفّر أي تحديث لحظة الإعلان: إذا كنت تعتمد عليه، فتحقّق من الإصدار المثبّت بعد ذلك.

  3. خادم cPanel (EasyApache 4 أو CloudLinux)

    sudo dnf upgrade 'ea-php*' 'alt-php*'
    /scripts/restartsrv_apache_php_fpm
    /scripts/restartsrv_httpd

    على خادم أقدم، استبدل dnf بـ yum. ثم افحص كل إصدار في WHM › MultiPHP Manager: يجب نقل أي حساب لا يزال مضبوطًا على فرع بلا تصحيح (‎7‎.x، ‎8‎.0، ‎8‎.1) إلى إصدار مدعوم.

  4. حاويات Docker

    docker compose pull
    docker compose up -d --force-recreate
    docker compose exec app php -r 'echo PHP_VERSION;'

    إذا كان ملف Dockerfile الخاص بك ينطلق من صورة php:8.3-fpm، فأعد بناء الصورة باستخدام docker compose build --pull: فبدون --pull يعيد Docker استخدام الصورة الأساسية القديمة المخزّنة مؤقتًا.

  5. تحقّق من النتيجة

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

إذا لم تتمكن من التحديث فورًا

يقترح التنبيه الرسمي لـ PHP إعدادات تقلّل من التعرّض دون أن تجعل التثبيت آمنًا. فهي تفيد في كسب بضع ساعات، لا في الاستغناء عن التصحيح. ويجب وضعها في php.ini أو في مجمّع PHP-FPM أو في إعدادات خادم الويب، وليس أبدًا عبر ini_set() أو ملف .user.ini: فهذان يُقرآن بعد فوات الأوان، بعد تحليل الطلب.

في مواجهة CVE-2026-109619، عطّل تتبّع تقدّم عمليات الرفع. وعلى ‎PHP 8‎.5، عطّل أيضًا تتبّعات الأخطاء الفادحة:

; in the FPM pool, e.g. /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 only:
php_admin_flag[fatal_error_backtraces] = off

وفي مواجهة CVE-2026-109618، يوصي التنبيه بفرض memory_limit = -1 عبر php_admin_value، حتى لا يتمكن أي تطبيق من إعادة تعريفه، وبتحديد حجم الطلب (post_max_size = 8M، أو 32M إذا كنت تحتاج إلى رفع الملفات). وفي المقابل، يجب وضع سقف للذاكرة في مكان آخر، عبر حدّ للحاوية أو لـ cgroup. لا تستخدم RLIMIT_AS ولا RLIMIT_DATA: فهما يتسبّبان تحديدًا في فشل التخصيص المعرَّض للثغرة.

أعد بعد ذلك تشغيل جميع عمليات PHP حتى تُطبَّق الإعدادات.

أضف حاجزًا أمام PHP

حدّد حجم الطلبات على مستوى خادم الويب، قبل أن تصل إلى PHP: client_max_body_size 8m; في nginx، وLimitRequestBody 8388608 في Apache. وإذا كان موقعك يمرّ عبر Cloudflare في الوضع الوكيل (proxied)، فقد نُشرت قواعد WAF تستهدف نواقل PHP2Shell المعروفة لجميع الحسابات، بما فيها الخطة المجانية. هذه شبكات أمان فقط: وحده تحديث PHP يغلق الثغرة.

ابحث عن آثار الاستغلال

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

فحوص يجب إجراؤها بعد التصحيح

  1. ابحث عن عمليات PHP-FPM المُنهاة

    sudo grep -E 'exited on signal (11|6)' /var/log/php*-fpm.log | tail -20

    إن إنهاء عمليات بالإشارة 11 (SIGSEGV) بشكل متكرر منذ 21 أكتوبر علامة تحذير.

  2. ابحث عن تجاوزات الذاكرة

    sudo grep -rh 'Allowed memory size' /var/log/php* /var/log/nginx /var/log/apache2 2>/dev/null | tail -20
  3. حدّد ملفات PHP المُنشأة حديثًا

    sudo find /var/www /home -name '*.php' -newermt '2026-10-20' -not -path '*/vendor/*' -not -path '*/cache/*' -ls

    أي ملف مجهول باسم عام، في مجلد رفع أو في /tmp، يجب فحصه قبل أي حذف.

  4. عند الشك، تعامل مع الخادم على أنه مخترق

    اعزل الجهاز، واحتفظ بنسخة من السجلات، ثم جدّد كلمات مرور قاعدة البيانات ومفاتيح API والأسرار الموجودة في ملفات .env: فتسريب الذاكرة قد يكون كشفها دون أن يترك أي أثر آخر.

على الاستضافة المشتركة

على الاستضافة المشتركة، لست أنت من يحدّث PHP: بل مزوّد الاستضافة هو من يصون الإصدارات المعروضة. ويتمثّل دورك في التحقق من أن موقعك يستخدم فرعًا لا يزال يتلقى التصحيحات. في cPanel، تُظهر أداة اختيار الإصدار (MultiPHP Manager، أو Select PHP Version على خادم CloudLinux) الإصدار النشط لكل نطاق. إذا كان موقعك لا يزال يعمل على ‎7‎.4 أو ‎8‎.0 أو ‎8‎.1، فهذه الفروع لم تعد تتلقى إصدارات رسمية من PHP: انتقل إلى ‎8‎.3 أو ‎8‎.4 بعد اختبار موقعك، باتباع قائمة التحقق الخاصة بنا للانتقال بين إصدارات PHP.

التوثيق الرسمي

نُشرت التفاصيل التقنية وإعدادات الالتفاف في التنبيه الأمني لـ PHP وفي تنبيهات GitHub GHSA-w8hw-w9fx-j79w (CVE-2026-109618) وGHSA-6wmf-4rv5-p3rp (CVE-2026-109619). وبالنسبة إلى حزم التوزيعات، راجع إعلان Ubuntu وإعلان AlmaLinux.

تحكّم في إصدارات PHP الخاصة بك

على خادم VPS من ServOrbit.com، تحصل على صلاحيات root: تطبّق تصحيح PHP فور نشره، وتختار إصدار كل موقع، وتعيد تشغيل خدماتك متى قرّرت ذلك.

بحاجة إلى مساعدة؟

تصفّح مركز المساعدة والأسئلة الشائعة، أو تواصل مع فريقنا — معاودة اتصال أو WhatsApp أو بريد إلكتروني. الدعم بـالعربية والفرنسية والإنجليزية.

راسلنا على WhatsAppيُفتح في علامة تبويب جديدة