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 المخدومة
اعرض الإصدارات المثبّتة
على 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حدّد عمليات PHP قيد التشغيل
systemctl list-units --type=service --state=running | grep -E 'php|apache2|httpd|lsws'كل خدمة
phpX.Y-fpmنشطة هي إصدار يجب التحقق منه وتصحيحه.اقرأ الإصدار الذي يخدم موقعًا ما
ضع ملفًا مؤقتًا في جذر الموقع، واستعلم عنه، ثم احذفه فورًا:
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.افحص حاويات 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 حسب بيئتك
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)، فتحقّق من أن الإصدار المثبّت بعد التحديث هو فعلًا إصدار مصحَّح.RHEL وAlmaLinux وRocky Linux
sudo dnf upgrade 'php*' sudo systemctl restart php-fpm sudo systemctl restart httpdنشرت AlmaLinux حزمها المصحَّحة في 21 أكتوبر 2026. أما مستودع Remi المجتمعي فلم يكن يوفّر أي تحديث لحظة الإعلان: إذا كنت تعتمد عليه، فتحقّق من الإصدار المثبّت بعد ذلك.
خادم 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) إلى إصدار مدعوم.حاويات 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 استخدام الصورة الأساسية القديمة المخزّنة مؤقتًا.تحقّق من النتيجة
أعد تشغيل فحص الخطوة السابقة على كل موقع. لا يُعدّ التصحيح مطبَّقًا إلا إذا كان الإصدار الذي يخدمه الويب مصحَّحًا، لا الإصدار المثبّت على القرص فحسب.
إذا لم تتمكن من التحديث فورًا
يقترح التنبيه الرسمي لـ 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 كبيرة الحجم على نحو غير طبيعي. إذا كان خادمك مكشوفًا قبل التحديث، فخصّص عشر دقائق للتحقق.
فحوص يجب إجراؤها بعد التصحيح
ابحث عن عمليات PHP-FPM المُنهاة
sudo grep -E 'exited on signal (11|6)' /var/log/php*-fpm.log | tail -20إن إنهاء عمليات بالإشارة 11 (SIGSEGV) بشكل متكرر منذ 21 أكتوبر علامة تحذير.
ابحث عن تجاوزات الذاكرة
sudo grep -rh 'Allowed memory size' /var/log/php* /var/log/nginx /var/log/apache2 2>/dev/null | tail -20حدّد ملفات PHP المُنشأة حديثًا
sudo find /var/www /home -name '*.php' -newermt '2026-10-20' -not -path '*/vendor/*' -not -path '*/cache/*' -lsأي ملف مجهول باسم عام، في مجلد رفع أو في
/tmp، يجب فحصه قبل أي حذف.عند الشك، تعامل مع الخادم على أنه مخترق
اعزل الجهاز، واحتفظ بنسخة من السجلات، ثم جدّد كلمات مرور قاعدة البيانات ومفاتيح 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.