شاهد الفيديو (دقيقتان):
صباح يوم الاثنين. تفتح موقعك على WordPress فتجد أنه لم يعد ملكك. الصفحة الرئيسية تقول HACKED، والأسعار كلها $0.00، وهناك مدير (Administrator) جديد لم تُنشئه أنت.
لكنك حدّثت WordPress. وحدّثت كل إضافة. وكل قالب.
لم تكن الثغرة داخل WordPress، بل كانت تحته، في PHP.
ماذا حدث: PHP2Shell
في 21 أكتوبر 2026 أصدر مشروع PHP الإصدارات PHP 8.5.12 و8.4.27 و8.3.36 و8.2.35. تُصلح هذه الإصدارات ثغرتين أمنيتين حرجتين أطلق عليهما الباحثون الأمنيون اسم PHP2Shell:
| CVE | ما الخلل | الخطورة |
|---|---|---|
| CVE-2026-109618 | عندما تنفد الذاكرة من PHP أثناء قراءة طلب ما (مثل رفع ملف كبير أو مشوّه)، تبقى بيانات الطلب مبنيّة جزئيًا، ثم تتعامل معها عملية التنظيف على أنها سليمة. وقد يؤدي ذلك إلى تنفيذ شيفرة عن بُعد. | CVSS v4 9.2، حرجة |
| CVE-2026-109619 | تبقى بعض الحالة الداخلية موجودة بعد تحرير ذاكرتها، فيستخدمها الطلب التالي على العامل (Worker) نفسه. تأكّد ذلك عبر ميزة تتبّع تقدّم رفع الملفات في الجلسة (مفعّلة افتراضيًا)، وفي PHP 8.5 عبر تتبّع الأخطاء القاتلة (Fatal Error Backtraces). | CVSS v4 9.2، حرجة |
بعبارة بسيطة: طلب HTTP واحد مصمَّم بعناية، ودون أي تسجيل دخول، قد يسمح للمهاجم بتشغيل شيفرة على خادمك بصلاحيات مستخدم خادم الويب. ويقول فريق PHP إن الهجوم على Apache مع mod_php قد ينطلق حتى قبل أن تعمل أي شيفرة من تطبيقك.
حتى تاريخ 21 أكتوبر 2026، لم تُبلغ أيٌّ من النشرات الرسمية عن هجمات فعلية تستغل الثغرتين. هذه هي فرصتك: حدّث قبل أن تُغلق.
من المعرّض للخطر
- أي خادم يشغّل PHP، وليس WordPress فقط: WooCommerce وLaravel وDrupal وMoodle والتطبيقات المكتوبة بـ PHP خصيصًا، والعديد من الأجهزة الجاهزة. أما WordPress نفسه فلا يحتاج إلى تحديث، ولا يوجد تحديث مخطط له.
- الخطر الأعلى: Apache مع mod_php. ويتأثر أيضًا: PHP-FPM وphp-cgi وFrankenPHP وLiteSpeed (LSAPI).
- PHP 8.1 وما قبله لن يحصل على أي إصلاح رسمي من مشروع PHP. بعض موزّعي Linux ينقلون الإصلاح إلى إصداراتهم القديمة (Backport)، وإلا فعليك الترقية.
- ملاحظة: ينتهي دعم PHP 8.2 في 31 ديسمبر 2026، لذا خطّط من الآن للانتقال إلى 8.3 أو 8.4.
الخطوة 1: تحقّق من إصدار PHP
في WordPress: Tools > Site Health > Info > Server > PHP version.
طرق أخرى:
- لوحة تحكم الاستضافة (في cPanel: "Select PHP Version" أو "MultiPHP Manager"، وفي Plesk: "PHP Settings").
- على خادمك:
php -v(هذا إصدار PHP الخاص بسطر الأوامر، وقد يختلف عن إصدار PHP الذي يشغّل الموقع، لذا تحقّق أيضًا من Site Health أو من صفحةphpinfo()تحذفها بعد ذلك).
الإصدارات الآمنة (أو الأحدث منها):
| الفرع | أُصلح في |
|---|---|
| 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 8.1 وما قبله | لا يوجد إصلاح رسمي: قم بالترقية |
الخطوة 2: حدّث PHP ثم أعد التشغيل
الاستضافة المشتركة أو المُدارة
- افتح لوحة الاستضافة واختر إصدارًا مُصلَحًا (مثل 8.4).
- إن لم تجد إصدارًا مُصلَحًا، راسل شركة الاستضافة اليوم: "Is our PHP patched for CVE-2026-109618 and CVE-2026-109619?" كثير من شركات الاستضافة تطبّق الإصلاحات وتضيف قواعد جدار حماية تطبيقات الويب (WAF)، لكن لا تفترض ذلك.
خادمك الخاص (Ubuntu / Debian)
sudo apt update
sudo apt upgrade 'php*'
sudo systemctl restart php8.3-fpm apache2 # use your PHP version and web server
php -v
RHEL وRocky وAlmaLinux:
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd
Windows: نزّل الإصدار الجديد من https://www.php.net/downloads.php?os=windows ثم أعد تشغيل IIS أو خدمة PHP لديك.
ملاحظتان مهمتان:
- أعد تشغيل كل عمّال PHP. فإلى أن تعيد تشغيل PHP-FPM (أو Apache مع mod_php)، يبقى إصدار PHP القديم المعرّض للخطر يعمل في الذاكرة.
- قد تُظهر حزم التوزيعات رقم إصدار أقدم مع أن الإصلاح منقول إليها (مثل حزمة php8.3 الخاصة بـ Ubuntu). تحقّق من النشرة الأمنية لموزّعك وابحث فيها عن أرقام CVE، ولا تعتمد على رقم الإصدار وحده. أما إن كنت تستخدم مستودع PPA الخاص بـ Ondřej Surý، فسترى أرقام الإصدارات الأصلية مثل 8.3.36.
الخطوة 3: لا تستطيع التحديث الليلة؟ استخدم الحل المؤقت
تقلّل هذه الإعدادات من التعرّض لمسارات الهجوم المعروفة. إنها حزام أمان، وليست الإصلاح. ضعها في php.ini أو في إعدادات مجموعة FPM (وليس عبر ini_set() ولا في .user.ini)، ثم أعد تشغيل PHP:
; temporary stopgap for PHP2Shell
session.upload_progress.enabled = 0
post_max_size = 32M ; 8M if the site needs no uploads
upload_max_filesize = 16M ; keep it below post_max_size
; PHP 8.5 only:
fatal_error_backtraces = 0
sudo systemctl restart php8.3-fpm
وحدّد أيضًا الحجم الأقصى لجسم الطلب على مستوى خادم الويب أو الوكيل (Proxy)، مثل client_max_body_size 32m; في Nginx أو LimitRequestBody في Apache.
يذكر فريق PHP كذلك الإعداد memory_limit=-1 (يُضبط عبر php_admin_value حتى لا تستطيع التطبيقات تغييره) وسيلةً لتخفيف خطر CVE-2026-109618. لا تفعل ذلك إلا مع حدود حجم الطلب المذكورة أعلاه، لأن الذاكرة غير المحدودة مع الرفع غير المحدود قد تسمح لطلب واحد باستنزاف موارد الخادم.
وإن لم تستطع التحديث ولا تطبيق الحل المؤقت، فإن المركز الوطني للأمن السيبراني في المملكة المتحدة (UK NCSC) وWordPress يقولان: فكّر في إيقاف الموقع مؤقتًا إلى أن تتمكّن من ذلك.
هل تعرّضت للاختراق بالفعل؟ نظّف موقعك
- المستخدمون: من Users > All Users، رشّح النتائج حسب Administrator، واحذف أي شخص لا تعرفه (مثل
wp-support0). وانقل محتواه إلى حسابك. - مجلد الرفع: لا مكان لملفات PHP في
wp-content/uploads. ابحث عنها واحذفها:find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \)ثم امنع تشغيل PHP هناك (في Apache:
<FilesMatch "\.(php|phtml|phar)$"> Require all denied </FilesMatch>داخلwp-content/uploads/.htaccess، وفي Nginx:location ~* /wp-content/uploads/.*\.(php|phtml|phar)$ { deny all; }). - كلمات المرور: غيّر كل كلمات مرور مديري WordPress، وكلمات مرور الاستضافة وSSH، وكلمة مرور قاعدة البيانات (وحدّثها في
wp-config.php). وأنشئ مفاتيح تشفير جديدة (Salts) من https://api.wordpress.org/secret-key/1.1/salt/ حتى تُنهى جميع الجلسات المفتوحة. - افحص Plugins وmu-plugins بحثًا عن أي شيء لم تثبّته أنت، وراجع الملفات المعدّلة مؤخرًا (
find . -mtime -3 -name "*.php")، واستعد نسخة احتياطية نظيفة إن ساورك الشك. دليل WordPress: https://wordpress.org/documentation/article/faq-my-site-was-hacked/
العودة إلى يوم الاثنين
حدّثت. أعدت التشغيل. نظّفت. عاد موقعك ملكك من جديد.
شاهد الفيديو:
قائمة تحقق سريعة
- تحققت من إصدار PHP في Site Health
- حدّثت إلى 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 أو أحدث (أو إلى نسخة الموزّع التي تتضمن الإصلاح)
- أعدت تشغيل PHP-FPM / Apache
- طبّقت إعدادات الحل المؤقت إن لم تستطع التحديث بعد
- حذفت المديرين المجهولين وملفات PHP من مجلد الرفع
- غيّرت كلمات المرور ومفاتيح التشفير (Salts)
المصادر
- WordPress.org، "Critical PHP Security Release" (21 أكتوبر 2026): https://wordpress.org/news/2026/10/critical-php-security-release/
- إعلان مشروع PHP: https://www.php.net/archive/2026.php#2026-10-21-5
- النشرة الأمنية لـ PHP رقم GHSA-w8hw-w9fx-j79w (CVE-2026-109618): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- النشرة الأمنية لـ PHP رقم GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- المركز الوطني للأمن السيبراني في المملكة المتحدة (UK NCSC): https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
- تنبيه CISA: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
- Help Net Security: https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
- قائمة NCSC-NL بمنتجات الجهات الخارجية المتأثرة: https://github.com/NCSC-NL/php2shell
Take away support: حلول تقنية تصلك في أقل من دقيقتين. اشترك في القناة على YouTube وتابعنا على Facebook حتى لا يفوتك الحل القادم. بقلم Abd Almouhimen Shamout، mouhimen.dev
هذا المقال ترجمة عربية للمقال الأصلي باللغة الإنجليزية للكاتب عبد المهيمن شموط على mouhimen.dev.
