في 21 أكتوبر 2026، أصدر مشروع PHP تحديثات طارئة لسدّ ثغرتين حرجتين، هما CVE-2026-109618 وCVE-2026-109619، وتُعرفان الآن باسم PHP2Shell. وعند استغلالهما معًا، يستطيع المهاجم تشغيل تعليمات برمجية على الخادم بطلب HTTP واحد مُعدّ خصيصًا. ولا يحتاج المهاجم إلى تسجيل دخول، ولا إلى إضافة مصابة بثغرة، ولا إلى أي خطأ في الإعدادات. فإذا كانت PHP تستجيب لطلبات الويب على خادمك، فهو مكشوف للخطر حتى يتم تحديثه.
كان المهاجمون يختبرون الثغرة قبل صدور الإصلاح بأيام، وبدأ الاستغلال الواسع خلال ساعات من صدوره. ويقدّر باحثو الأمن أن ما بين 1.3 و1.9 مليون خادم متصل بالإنترنت كان مكشوفًا. يشرح هذا الدليل ماهية الثغرتين، والإصدارات المُصلَحة، وطريقة تحديث الخادم الخاص خطوة بخطوة، وكيف تتحقق مما إذا كان أحدهم قد سبقك إلى الدخول.
أهم النقاط
- PHP2Shell عبارة عن ثغرتين حرجتين في PHP (بدرجة CVSS 9.2) تتيحان تنفيذ التعليمات البرمجية عن بُعد دون مصادقة بطلب HTTP واحد.
- جميع إصدارات PHP بدءًا من 5.4 متأثرة عندما تخدم حركة مرور الويب: mod_php وPHP-FPM وCGI وFrankenPHP وLiteSpeed.
- الإصدارات المُصلَحة هي 8.2.35 و8.3.36 و8.4.27 و8.5.12. أعد تشغيل جميع عمليات PHP بعد التحديث.
- جميع خوادم cPanel وManaged WordPress لدى WebGee محدّثة بالفعل، ولا يحتاج العملاء إلى اتخاذ أي إجراء.
- بدأ استغلال الثغرة قبل صدور الإصلاح، لذا افحص السجلات والملفات بحثًا عن علامات الاختراق حتى بعد التحديث.
عملاء WebGee: أنتم محميون بالفعل حدّث مهندسونا جميع خوادم cPanel المشتركة وخوادم الموزعين لدى WebGee، وجميع خوادم استضافة Managed WordPress، إلى إصدارات PHP المُصلَحة، ثم أعادوا تشغيل جميع عمليات PHP. لا تحتاج إلى فعل أي شيء. هذا الدليل مخصص للخوادم التي تديرها بنفسك، مثل الخوادم الافتراضية الخاصة (VPS) أو الخوادم المخصصة أو الخوادم السحابية التي تملك فيها صلاحيات root.
ما هي PHP2Shell؟
PHP2Shell هو الاسم الذي أُطلق على ثغرتين في أمان الذاكرة ضمن آلية معالجة الطلبات الأساسية في PHP. وتقع كلتاهما في تعليمات برمجية تعمل قبل أن يتلقى تطبيقك (سواء كان WordPress أو Laravel أو Magento أو أي تطبيق آخر) الطلب. ولهذا السبب لا يحميك تحديث نظام إدارة المحتوى والإضافات في هذه الحالة.
CVE-2026-109618: تلف ناتج عن نفاد الذاكرة أثناء تحليل الطلب
عندما تحلّل PHP محتوى طلب بصيغة multipart/form-data (وهي الصيغة المستخدمة في النماذج ورفع الملفات)، فإن نفاد الذاكرة في منتصف العملية يترك الهياكل الداخلية مهيأة جزئيًا فقط. ثم تتعامل شيفرة التنظيف في PHP مع هذه الحالة المعطوبة على أنها سليمة. ويمكن لطلب مُعدّ خصيصًا أن يفرض هذا الوضع حتى على الخوادم التي تعمل بحدود ذاكرة عادية.
CVE-2026-109619: حالة عامة قديمة واستخدام ذاكرة بعد تحريرها (use-after-free)
تعالج PHP الأخطاء الفادحة باستخدام longjmp()، التي تقفز خارج الشيفرة المتعثرة دون التراجع عنها بشكل منظم. وبعد خطأ الذاكرة المذكور أعلاه، قد تبقى الحالة العامة المرتبطة بالطلب مشيرةً إلى ذاكرة سبق تحريرها. وعندها يمكن للطلب التالي الذي تعالجه عملية PHP نفسها أن يستخدم تلك الذاكرة. وقد أكد الباحثون إمكانية تسريب محتوى الذاكرة وتنفيذ التعليمات البرمجية عن بُعد بشكل كامل.
ومعًا، تحوّل هاتان الثغرتان طلب POST واحدًا مشوّهًا إلى واجهة أوامر تعمل باسم مستخدم خادم الويب لديك (www-data أو apache أو nobody). ومن هناك يستطيع المهاجم قراءة ملف wp-config.php وبيانات اعتماد قاعدة البيانات، وزرع أبواب خلفية، وإرسال رسائل مزعجة، أو التوغل أعمق في شبكتك.
ما مدى خطورتها؟
- الخطورة: صُنّفت كلتا الثغرتين بدرجة CVSS v4.0 9.2 (حرجة). وقد تداولت النشرات الأمنية الأولى درجة 10.0.
- المصادقة: غير مطلوبة. يمكن الوصول إلى الثغرة عبر أي عنوان URL تعالجه PHP.
- الاستغلال: مؤكد على أرض الواقع، وهناك شيفرة إثبات مفهوم متداولة علنًا.
- التطبيقات: ثبتت إمكانية تنفيذ التعليمات البرمجية قبل المصادقة على WordPress وDrupal وJoomla وMagento.
- القِدم: يعود مسار الشيفرة المصاب إلى PHP 5.4.0، لذا فإن الخوادم القديمة جدًا متأثرة أيضًا.
من المتأثر؟
كل تثبيت لـ PHP يخدم حركة مرور الويب، أيًّا كانت واجهة الخادم البرمجية (SAPI) التي يستخدمها:
- Apache مع mod_php: الأعلى خطورة، لأن عملية التحليل المصابة تجري داخل عملية Apache نفسها.
- PHP-FPM خلف nginx أو Apache أو Caddy.
- php-cgi وFrankenPHP وLiteSpeed (LSAPI).
أما PHP التي تعمل من سطر الأوامر فقط (مثل مهام cron والعمليات التي لا تحلّل محتوى طلبات HTTP)، فلا يمكن الوصول إليها مباشرة، لكن الملف التنفيذي نفسه يكون عادةً مثبتًا لخدمة الويب أيضًا. لذا حدّث كل شيء.
إصدارات 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 أو أحدث
- PHP من 7.4 إلى 8.1: لا يوجد إصدار رسمي. تتوفر الإصلاحات فقط كتعديلات منقولة إلى الشيفرة المصدرية، ومن خلال موردين مثل CloudLinux (alt-php) وبعض توزيعات Linux.
- PHP من 5.4 إلى 7.3: منتهية الدعم ولا يوجد لها إصلاح. قم بالترقية، أو أزِل الموقع من الإنترنت العام.
الخطوة 1: تحقق من إصدار PHP الذي يعمل على خادمك
تحقق من الملف التنفيذي لسطر الأوامر ومن الإصدار الذي يستخدمه خادم الويب فعليًا، فهما يختلفان في كثير من الأحيان.
# Command-line PHP
php -v
# Every PHP binary installed on the server
ls /usr/bin/php* /usr/sbin/php-fpm* /opt/cpanel/ea-php*/root/usr/bin/php /opt/alt/php*/usr/bin/php 2>/dev/null
# The version your web server serves: drop a temporary file, fetch it, then delete it
echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/v.php >/dev/null
curl -s https://your-domain.com/v.php; echo
sudo rm /var/www/html/v.phpلا تترك ملفات phpinfo() على الخادم إذا استخدمت ملف phpinfo() أو ملفًا لعرض الإصدار من أجل التحقق، فاحذفه فور الانتهاء. يبحث المهاجمون عن هذه الملفات للتعرف على الخوادم المصابة.
الخطوة 2: حدّث PHP على خادمك
اختر القسم الخاص بمنصتك. بعد التحديث، يجب عليك إعادة تشغيل جميع عمليات PHP، إذ تستمر العمليات القديمة في تشغيل الشيفرة المصابة إلى أن يتم استبدالها.
Ubuntu وDebian
sudo apt update
sudo apt install --only-upgrade 'php*-common' 'php*-cli' 'php*-fpm' 'libapache2-mod-php*'
# Restart PHP-FPM (repeat for each installed version)
sudo systemctl restart php8.3-fpm
# Using mod_php? Restart Apache instead
sudo systemctl restart apache2
# Confirm
php -vإذا كنت تثبّت PHP من مستودع ondrej/php PPA أو من مستودع خارجي مشابه، فتأكد من أن هذا المستودع قد نشر الإصدارات المُصلَحة قبل أن تفترض أن خادمك محدّث.
AlmaLinux وRocky Linux وRHEL
sudo dnf clean all
sudo dnf upgrade 'php*'
# Restart PHP-FPM and the web server
sudo systemctl restart php-fpm
sudo systemctl restart httpd # or nginx
php -vخوادم cPanel وWHM (EasyApache ea-php)
توفّر cPanel لغة PHP في صورة حزم ea-php. حدّثها جميعًا دفعة واحدة:
# CloudLinux / CentOS 7
yum clean all && yum update "ea-php*"
# AlmaLinux / CloudLinux 8, 9 and 10
dnf clean all && dnf upgrade "ea-php*"
# Restart PHP-FPM for all accounts, then Apache or LiteSpeed
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd
# Check each installed version
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo -n "$p: "; $p -r 'echo PHP_VERSION, PHP_EOL;'; doneCloudLinux alt-php (PHP Selector)
تنقل CloudLinux الإصلاح إلى جميع فروع alt-php، بما فيها الإصدارات المنتهية الدعم مثل 5.6 و7.4. ولا يتغير رقم الإصدار، لذا تحقق من سجل تغييرات الحزمة بدلًا من php -v:
yum clean all && yum update 'alt-php*' 'ea-php*' -y
# Confirm the fix is in the installed package (example: alt-php 7.4)
rpm -q --changelog alt-php74 | grep -m1 -i 'CVE-2026-109618'Docker والحاويات
الحاويات لا تُحدّث نفسها تلقائيًا. اسحب الصورة الرسمية المُصلَحة، ثم أعد البناء والنشر:
# Pin to a fixed release (or newer)
FROM php:8.3.36-fpm
# ...your existing build stepsdocker pull php:8.3.36-fpm
docker compose build --pull
docker compose up -d
# Confirm inside the running container
docker compose exec app php -vالخطوة 3: إجراءات حماية مؤقتة إن لم تتمكن من التحديث اليوم
هذه الإعدادات تقلل من التعرض للخطر لكنها لا تُصلح الثغرة. استخدمها فقط لكسب الوقت ريثما تجدول الترقية، كما هو الحال مثلًا مع PHP 7.3 أو الإصدارات الأقدم التي لا يتوفر لها إصلاح.
تقوية إعدادات php.ini
يعتمد الاستغلال على بلوغ حد الذاكرة الخاص بـ PHP أثناء التحليل. ويؤدي تعطيل هذا الحد على مستوى PHP (مع فرض حد صارم في موضع آخر، كما هو موضح أدناه) إلى إغلاق المُحفِّز الرئيسي. كما أن تتبع تقدم الرفع يمثل مسارًا آخر للوصول إلى الشيفرة المصابة.
; /etc/php/8.3/fpm/conf.d/99-php2shell.ini (adjust the path to your version)
; Interim mitigation for CVE-2026-109618 / CVE-2026-109619
memory_limit = -1
session.upload_progress.enabled = 0
post_max_size = 1M
; PHP 8.5 only
fatal_error_backtraces = 0تقوم تطبيقات مثل WordPress برفع قيمة memory_limit بنفسها أثناء التشغيل. لذا ثبّت القيم في مجموعة PHP-FPM (pool) حتى لا تتمكن الشيفرة من تجاوزها:
; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_flag[session.upload_progress.enabled] = offاقرن دائمًا memory_limit = -1 بحد صارم في غياب حد للذاكرة في PHP، قد يستهلك سكربت واحد خارج عن السيطرة كل ذاكرة الخادم. لذا ضع حدًا للذاكرة على مستوى العملية بدلًا من ذلك، باستخدام MemoryMax في systemd لخدمة PHP-FPM أو حد ذاكرة للحاوية، بحيث يتولى النظام إيقاف العملية الخارجة عن السيطرة بدلًا من PHP.
# Cap PHP-FPM memory with systemd
sudo systemctl edit php8.3-fpm
# [Service]
# MemoryMax=2G
# Or, for Docker:
docker update --memory 2g --memory-swap 2g <container>تحديد حجم محتوى الطلب على مستوى خادم الويب
ارفض المحتوى الكبير الحجم قبل أن يصل إلى PHP أصلًا. يحظر ذلك الحمولات الكبيرة المُعدّة خصيصًا المستخدمة في أدوات الاستغلال المتداولة، لكنه سيحظر أيضًا عمليات الرفع الكبيرة المشروعة، لذا ارفع الحد فقط على المسارات التي تحتاج إليه.
# nginx: inside http {} or server {}
client_max_body_size 1m;
# Allow bigger uploads only where needed, e.g. the WordPress media uploader
location = /wp-admin/async-upload.php {
client_max_body_size 64m;
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}# Apache: in the vhost or .htaccess (bytes)
LimitRequestBody 1048576ثم أعد تشغيل جميع عمليات PHP حتى لا تبقى أي منها محتفظة بحالة تالفة:
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx # or: sudo systemctl restart apache2إذا كان موقعك خلف Cloudflare، ففعّل قواعد WAF المُدارة الخاصة بهذه الثغرة؛ فقد أتاحت Cloudflare الحماية حتى في الخطة المجانية. لكن تعامل مع WAF كطبقة حماية إضافية، لا كبديل عن التحديث. كما يوصي فريق CERT-EU بعزل تطبيقات PHP المتصلة بالإنترنت التي لا يمكن تحديثها فورًا.
الخطوة 4: تحقق مما إذا كان خادمك قد اختُرق بالفعل
بدأ الاستغلال قبل أن يتمكن معظم الناس من التحديث، لذا فإن التحديث ليس نهاية المهمة. ابحث عن العلامات التالية.
أخطاء نفاد الذاكرة عند السطر 0
تترك المحاولات الفاشلة والناجحة على حد سواء خطأ ذاكرة فادحًا دون ملف أو سطر حقيقي، وعادةً ما يكون مصحوبًا بطلب POST كبير على نحو غير معتاد:
sudo grep -R "Allowed memory size of .* exhausted .* in Unknown on line 0" \
/var/log/php*-fpm.log /var/log/apache2/error.log /var/log/httpd/error_log \
/var/log/nginx/error.log 2>/dev/null | tail -n 50تعطل العمليات
# Apache children dying with segfaults
sudo grep -R "AH00052: child pid .* exit signal Segmentation fault" /var/log/apache2/ /var/log/httpd/ 2>/dev/null
# PHP-FPM workers killed by signals
sudo grep -R "exited on signal" /var/log/php*-fpm.log 2>/dev/nullواجهات أوامر شغّلها مستخدم خادم الويب
# A shell running under apache, www-data or php-fpm is a red flag
ps aux | grep -E "(apache|www-data|php-fpm|nobody)" | grep -E "\b(sh|bash|dash)\b" | grep -v grep
# Unexpected outbound connections from the web user
sudo ss -tunp | grep -E "php|apache|httpd|nginx"الأبواب الخلفية وآليات البقاء
# PHP files changed in the last 7 days
sudo find /var/www -type f -name "*.php" -mtime -7 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -n 50
# PHP files in upload folders (they should never be there)
sudo find /var/www -path "*uploads*" -name "*.php"
# Cron jobs added for the web user
sudo crontab -u www-data -l 2>/dev/null; sudo crontab -u apache -l 2>/dev/nullفي سجلات الوصول، ابحث عن طلبات POST تحتوي على أسماء حقول نماذج ضخمة (أكثر من 1 MB)، أو بايتات ثنائية أو فارغة (null) في المحتوى، أو بنية مثل =[binary]&a=1&[long field][x]=1.
لا يتسبب الاستغلال الناجح دائمًا في أي تعطل، لذا فإن خلو السجلات من الأخطاء ليس دليلًا على أنك في أمان. إذا وجدت أيًّا من هذه العلامات، فافترض أن الخادم مخترق:
- أوقف الموقع أو ضعه في وضع الصيانة؛
- غيّر كلمات مرور قاعدة البيانات ومفاتيح API ومفاتيح التشفير (salts) في WordPress؛
- استعد الموقع من نسخة احتياطية مأخوذة قبل 17 أكتوبر 2026؛
- ثم حدّث الخادم قبل إعادة الموقع إلى العمل.
قائمة التحقق للاستجابة لثغرة PHP2Shell
- حدّد جميع إصدارات PHP على الخادم، سواء لسطر الأوامر أو للويب
- قم بالترقية إلى 8.2.35 أو 8.3.36 أو 8.4.27 أو 8.5.12 أو إلى إصلاح منقول من أحد الموردين
- أعد تشغيل PHP-FPM أو Apache أو LiteSpeed حتى لا تبقى أي عمليات قديمة
- أعد بناء الحاويات ونشرها من صور مُصلَحة
- طبّق إعدادات php.ini المؤقتة وحدود حجم المحتوى على كل ما لا يمكنك تحديثه بعد
- ابحث في السجلات عن أخطاء الذاكرة عند السطر 0 وأخطاء segfault
- تحقق من وجود واجهات أوامر لمستخدم الويب وملفات PHP جديدة ومهام cron جديدة
- غيّر بيانات الاعتماد إذا بدا أي شيء مريبًا
لماذا يتكرر هذا، وكيف تساعدك الاستضافة المُدارة
انتقلت PHP2Shell من أول رصد في مصيدة اختراق إلى الاستغلال الواسع في أقل من أسبوع، وحدث معظم ذلك قبل توفر أي إصلاح. وبالنسبة إلى أي شركة تدير خادمها الخاص، فإن التصدي لذلك يعني وجود شخص يتابع النشرات الأمنية على مدار الساعة، ويختبر التحديثات، ويطبّقها على كل إصدار من PHP وكل عملية فور صدورها. وكثيرًا ما يتعين القيام بذلك في الثانية صباحًا أو في عطلة نهاية الأسبوع، بينما تُستخدم أدوات الاستغلال المتداولة بالفعل.
وهذا تحديدًا ما يقوم به فريقنا لعملاء WebGee. ففي حالة PHP2Shell، قام مهندسونا بما يلي:
- تطبيق إصدارات PHP المُصلَحة على جميع خوادم cPanel المشتركة وخوادم الموزعين؛
- تحديث جميع خوادم استضافة Managed WordPress إلى أحدث إصدار مُصلَح من PHP؛
- إعادة تشغيل جميع عمليات PHP حتى لا تبقى أي عملية مصابة قيد التشغيل؛
- إنجاز كل ذلك دون الحاجة إلى أي إجراء من العملاء.
وإلى جانب التحديثات، تتضمن استضافة WebGee فحص البرمجيات الخبيثة على مستوى الخادم، وجدار حماية لتطبيقات الويب، ونسخًا احتياطية يومية. فإذا نجح هجوم ما في التسلل بطريقة أو بأخرى، تكون لديك نقطة استعادة نظيفة.
إذا كنت تشغّل WordPress أو WooCommerce أو أي تطبيق PHP آخر على خادم يتعين عليك تحديثه بنفسك، ففكّر في أن تترك لنا هذه المهمة. سننقل موقعك مجانًا ودون أي توقف عن العمل.
تفضّل الاحتفاظ بخادمك الخاص؟
إذا كنت تحتاج إلى صلاحيات root، فإن الخادم السحابي من WebGee يمنحك تحكمًا كاملًا، ويمكن لمهندسي الدعم لدينا مساعدتك في تحديثه وتقويته ومراقبته. أما المواقع التي تحتاج فقط إلى البقاء سريعة وآمنة، فإن استضافة Managed WordPress والاستضافة السحابية مع cPanel تحافظان على تحديث PHP نيابةً عنك. لست متأكدًا من الخيار الأنسب لك؟ تحدّث إلى فريقنا.
الأسئلة الشائعة
موقعي مستضاف لدى WebGee. هل يجب أن أفعل شيئًا؟
لا. حدّثنا جميع خوادم cPanel المشتركة وخوادم الموزعين لدى WebGee، وجميع خوادم استضافة Managed WordPress، إلى إصدارات PHP المُصلَحة، وأعدنا تشغيل جميع عمليات PHP. أما إذا كنت تدير خادمًا سحابيًا أو مخصصًا خاصًا بك بصلاحيات root، فاتبع الخطوات الواردة في هذا الدليل أو تواصل مع فريق الدعم لدينا للمساعدة.
هل يؤدي تحديث WordPress أو الإضافات إلى إصلاح PHP2Shell؟
لا. الثغرتان موجودتان في PHP نفسها، وتُفعَّلان قبل تشغيل WordPress أو أي تعليمات برمجية لتطبيق آخر. يجب عليك تحديث حزم PHP على الخادم ثم إعادة تشغيل PHP.
ما إصدارات PHP التي تُصلح CVE-2026-109618 وCVE-2026-109619؟
PHP 8.2.35 و8.3.36 و8.4.27 و8.5.12 أو أي إصدار أحدث. أما الإصدارات من PHP 7.4 إلى 8.1 فلا تتوفر لها سوى إصلاحات منقولة إلى الشيفرة المصدرية وإصدارات من موردين مثل CloudLinux alt-php. ولا يوجد أي إصلاح للإصدارات من PHP 5.4 إلى 7.3.
أستخدم إصدارًا قديمًا من PHP ليس له إصلاح. ماذا أفعل؟
قم بالترقية إلى فرع مدعوم من PHP في أسرع وقت ممكن. وإلى ذلك الحين، طبّق إعدادات php.ini المؤقتة وحدود حجم الطلبات الواردة في هذا الدليل، أو ضع الموقع خلف جدار حماية لتطبيقات الويب (WAF)، أو أزِله من الإنترنت العام. كما يتضمن CloudLinux alt-php إصلاحات منقولة للعديد من الإصدارات المنتهية الدعم.
هل يكفي جدار حماية تطبيقات الويب؟
لا. يستطيع WAF حظر أنماط الاستغلال المعروفة ويمنحك بعض الوقت، لكن المهاجمين يغيّرون حمولاتهم باستمرار. تحديث PHP هو الحل الحقيقي الوحيد.
كيف أعرف إن كان خادمي قد تعرّض للاختراق؟
ابحث عن أخطاء 'Allowed memory size ... in Unknown on line 0'، وعن عمليات تتعطل بخطأ segfault، وعن واجهات أوامر (shells) تعمل باسم مستخدم خادم الويب، وملفات PHP عُدّلت مؤخرًا، وملفات PHP داخل مجلدات الرفع، ومهام cron جديدة. قد لا يترك الهجوم الناجح أي أثر لتعطل، لذا إن ساورك الشك فغيّر بيانات الاعتماد واستعد الموقع من نسخة احتياطية مأخوذة قبل 17 أكتوبر 2026.
