php2shell: ثغرتان حرجتان في PHP تم إصلاحهما. حدّث PHP موقعك اليوم

في 21 أكتوبر 2026 أصدر مشروع PHP الإصدارات PHP 8.5.12 و8.4.27 و8.3.36 و8.2.35. تصلح هذه الإصدارات ثغرتين حرجتين، CVE-2026-109618 وCVE-2026-109619، قد تتيحان للمهاجم تشغيل تعليمات برمجية على خادم الويب دون تسجيل دخول. ويقول فريق PHP إن على جميع مستخدمي PHP التحديث فورًا (php.net).

إذا كان موقعك يعمل على WordPress أو WooCommerce أو Joomla أو Drupal أو أي برنامج PHP آخر، فهذا الأمر يخصك. الثغرتان في PHP نفسه، وليستا في WordPress أو في إحدى الإضافات، ولذلك لا يصلحهما تحديث WordPress. يجب تحديث PHP، وغالبًا تتولى ذلك شركة الاستضافة.

ما الذي حدث

• 20 أكتوبر 2026: أعلن فريق الأمان في PHP عن إصدار أمني سيصدر في 21 أكتوبر 2026 عند الساعة 14:00 بتوقيت UTC، يصلح ثغرتين حرجتين تقييمهما 9.2 وفق CVSS v4.0 (php.net).
• 21 أكتوبر 2026، الساعة 03:02 بتوقيت UTC: فعّلت Cloudflare قواعد جدار حماية ضد الهجوم لعملائها، بمن فيهم عملاء الخطة المجانية. وتقول Cloudflare إن التفاصيل تسرّبت قبل الإصدار الرسمي، وإنها رصدت حركة هجوم ضد عملائها (مدونة Cloudflare).
• 21 أكتوبر 2026: نشر PHP الإصدارات المصححة ونشرتين أمنيتين، GHSA-w8hw-w9fx-j79w وGHSA-6wmf-4rv5-p3rp، وكلتاهما بدرجة حرجة، 9.2.

تُعرف الثغرتان باسم "php2shell" (مدونة Cloudflare، BleepingComputer). ويطلب المركز الوطني للأمن السيبراني في المملكة المتحدة (NCSC) من المؤسسات التحديث، والنظر في فصل النظام عن الشبكة إذا تعذّر تحديثه أو تخفيف المخاطر بسرعة (NCSC).

من المتأثر

بحسب PHP، كل تثبيت لـ PHP يخدم طلبات الويب معرّض للخطر، ويشمل ذلك PHP-FPM وApache مع mod_php وphp-cgi وFrankenPHP وLiteSpeed. ويرى PHP أن الخطر أعلى ما يكون مع mod_php، حيث ثبت أن الاستغلال ينجح بطلب واحد غير موثّق قبل تشغيل أي شيفرة من التطبيق (php.net).

تعدّ النشرتان كل إصدار أقدم من 8.2.35 و8.3.36 و8.4.27 و8.5.12 متأثرًا (GHSA-w8hw-w9fx-j79w، GHSA-6wmf-4rv5-p3rp). والفروع الأقدم متأثرة أيضًا: يقول NCSC من PHP 5 فما فوق (NCSC)، وتقول Cloudflare PHP 5.4 أو أحدث (مدونة Cloudflare).

إذا كان موقعك يستخدم PHP ولم يحدّث أحد PHP منذ ظهر 21 أكتوبر، فافترض أنه متأثر.

كيف تعرف إصدار PHP الذي يستخدمه موقعك

في WordPress: افتح أدوات (Tools) > صحة الموقع (Site Health) > معلومات (Info) ثم قسم الخادم (Server). يعرض لك إصدار PHP الذي يعمل عليه موقعك (توثيق WordPress.org). وإذا ذكرت صفحة صحة الموقع أيضًا أن موقعك يعمل بإصدار قديم من PHP، فاعتبر الأمر عاجلًا.

في لوحة الاستضافة: معظم اللوحات (cPanel وPlesk وDirectAdmin ولوحات الشركات الخاصة) فيها صفحة لعرض إصدار PHP أو اختياره، وتسمى غالبًا "PHP version" أو "PHP selector" أو "PHP settings". وإن لم تجدها فاسأل شركة الاستضافة.

قارن ما تراه بالإصدارات المصححة أدناه. هناك تنبيه واحد: توزيعات Linux والجهات التي تقدم دعمًا طويل الأمد (LTS) حصلت على التصحيحات مسبقًا وتوزّع حزمها الخاصة (php.net). وقد لا يطابق رقم الإصدار لديها أرقام مشروع PHP حتى لو كان الإصلاح مضمّنًا. وإذا كانت استضافتك تستخدم حزم التوزيعة، فالجواب الموثوق يأتي من الاستضافة، لا من الرقم وحده.

ماذا تفعل الآن

1. انتقل إلى إصدار مصحح

الإصدارات المصححة: php.net. تواريخ الدعم: إصدارات PHP المدعومة.

إذا كنت على PHP 8.2 فحدّث إلى 8.2.35 الآن وخطط للانتقال إلى 8.3 أو أحدث. لن يحصل PHP 8.2 على إصلاحات أمنية بعد 31 ديسمبر 2026 (php.net).

2. إذا كنت على PHP 8.1 أو 8.0 أو 7.4 أو أقدم

لم يعد مشروع PHP يصدر تحديثات لـ PHP 8.1 وما قبله. بعض التوزيعات وجهات LTS تقدم إصلاحات منقولة إلى الإصدارات القديمة. ونظرًا لخطورة الثغرتين، نشر فريق الأمان في PHP أيضًا نسخًا مصغّرة من الإصلاح لـ PHP 7.4 و8.0 و8.1، موجهة لمن يبني PHP من المصدر أو ليس لديه جهة LTS (php.net).

أما موقع الشركة المعتاد على استضافة مشتركة أو مُدارة فالحل أبسط: انتقل إلى إصدار مدعوم (8.3 أو أحدث) من لوحة الاستضافة، أو اطلب من الاستضافة أن تفعل ذلك. واختبر الموقع بعد ذلك، لأن الإضافات والقوالب القديمة تتعطل أحيانًا على إصدارات PHP الأحدث.

3. اسأل شركة الاستضافة

أرسل إلى الاستضافة رسالة قصيرة:

مرحبًا، هل PHP على حسابي (النطاق: example.com) مصحَّح بالفعل ضد CVE-2026-109618 وCVE-2026-109619؟ ما الإصدار أو الحزمة الدقيقة التي أستخدمها، ومتى سيُطبَّق التحديث إن لم يتم بعد؟

وإذا كنت تدير خادمك بنفسك وتستخدم مستودع rpms.remirepo.net الذي يصونه متطوعون، فيقول PHP إنه لن تتوفر فيه تحديثات في 21 أكتوبر، ويحث على التحول إلى حزم التوزيعة أو البناء من المصدر (php.net).

4. جدار الحماية يمنحك بضعة أيام، وليس هو الإصلاح

نشرت Cloudflare قواعد لطرق الهجوم المعروفة على جميع الخطط التي فيها WAF، بما فيها المجانية (مدونة Cloudflare). ووصف المدير التقني لـ Cloudflare هذه القواعد بأنها حل مؤقت، وطلب من المسؤولين التحديث (Tenable). ويقول PHP نفسه إنه لا توجد إجراءات تخفيف كاملة، وإن التحديث هو الخيار الآمن الوحيد (php.net).

هناك قيدان. القواعد تغطي أنماط الهجوم المعروفة، وقد بدأ المهاجمون فعلًا بتغيير حمولاتهم لتجاوزها (مدونة Cloudflare). كما أن القواعد لا تحمي شيئًا إذا استطاع المهاجمون الوصول إلى خادمك مباشرة عبر عنوان IP، ولذلك ينبغي أن يقبل الخادم الأصلي حركة الويب من Cloudflare فقط (Sansec).

5. إذا لم تستطع التحديث اليوم

يذكر PHP تغييرات في الإعدادات تقلل التعرض لمسارات الهجوم المعروفة لكنها لا تجعل الخادم آمنًا (php.net). هذه إعدادات خادم، ولذلك على الاستضافة المشتركة يجب أن تطبقها الاستضافة. سلّم هذه القائمة لمطورك أو لشركة الاستضافة:

• بالنسبة إلى CVE-2026-109618: اضبط memory_limit=-1 بطريقة لا تستطيع التطبيقات تجاوزها (مثلًا php_admin_value في مجمّع FPM أو في إعدادات Apache)، واضبط post_max_size منخفضًا (8M بدون رفع ملفات، و32M مع رفع الملفات) مع جعل upload_max_filesize أقل منه، وحدّد حجم الطلب وعدد الحقول وأجزاء multipart والرؤوس على مستوى خادم الويب أو الوكيل. لا تستخدم RLIMIT_AS ولا RLIMIT_DATA.
• بالنسبة إلى CVE-2026-109619: اضبط session.upload_progress.enabled=0 في php.ini أو مجمّع FPM أو إعدادات الخادم، وأعد تشغيل كل العمّال (workers). ولا يجدي ini_set() ولا .user.ini هنا. وعلى PHP 8.5 اضبط أيضًا fatal_error_backtraces=0 وأعد تشغيل كل العمّال. وأزل الإعدادات غير الصالحة أو المهجورة الخاصة بكل طلب والتي تُنتج تحذيرات.

التفاصيل التقنية

تنبع الثغرتان من نوع واحد من المشاكل: عندما ينتهي الطلب بشكل غير طبيعي، قد يترك PHP الذاكرة في حالة تالفة تثق بها خطوة لاحقة (BleepingComputer، مدونة Cloudflare).

CVE-2026-109618، تنفيذ تعليمات عن بُعد (RCE) عبر إتلاف الذاكرة عند نفادها (OOM) (GHSA-w8hw-w9fx-j79w). يستخدم PHP الدالة longjmp() لإنهاء الطلب عندما تنفد الذاكرة. في بعض المواضع تكون ذاكرة الطلب قابلة للوصول قبل أن تكتمل تهيئتها. وإذا فشل أي تخصيص للذاكرة في تلك اللحظة، فقد تقرأ مرحلة إنهاء الطلب بيانات لم يكتمل بناؤها. يستطيع المهاجمون فرض حالة نفاد الذاكرة بطلبات multipart: جسم طلب بلا طول محتوى صالح، أو جزء فيه عدد هائل من الرؤوس، أو حقول ملفات فارغة كثيرة بأسماء متداخلة. ومع Apache وmod_php يحدث هذا أثناء التحليل التلقائي لجسم الطلب، قبل تشغيل أي شيفرة من التطبيق. وتأكد تنفيذ التعليمات عن بُعد بحساب عامل الويب على mod_php مع الحدود الافتراضية للمدخلات والذاكرة. ويُقدَّر أن FPM عرضة للثغرة بناءً على تحليل الشيفرة المصدرية، لكن لم يُعرض استغلال كامل على FPM. يستبدل الإصلاح longjmp() عند نفاد الذاكرة بإيقاف ناعم مؤجل عند نقطة آمنة، وبـ _exit() قسري عند عتبة أعلى.

CVE-2026-109619، تنفيذ تعليمات عن بُعد (RCE) عبر حالة عامة قديمة (GHSA-6wmf-4rv5-p3rp). يحتفظ عامل PHP ببعض الحالة العامة (حالة الأخطاء والجلسات والكائنات والامتدادات) التي تشير إلى ذاكرة يملكها طلب واحد. وقد يتخطى خطأ فادح، بما في ذلك نفاد الذاكرة أو Maximum execution time exceeded، إعادة ضبط هذه الحالة. عندئذ يستطيع الطلب التالي الذي يعالجه العامل نفسه استخدام الذاكرة المحررة قبل التهيئة العادية، وهذا استخدام بعد التحرير (use after free). تأكد وجود مستهلكَين مبكرَين: التحذيرات الناتجة عن إعدادات INI الخاصة بكل طلب والمطبقة قبل التهيئة، وتقدم رفع الجلسة (session upload progress)، وهو مفعّل افتراضيًا ولا يحتاج إلى أن يستدعي التطبيق session_start(). ومسار fatal_error_backtraces في PHP 8.5 هو أساس الاستغلال المؤكد على mod_php. وتم التحقق من مسار الجلسة على mod_php وFPM معًا. وإخفاء الأخطاء عبر error_reporting أو display_errors أو @ لا يحمي.

تحصل النشرتان على التقييم 9.2 بالمتجه CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N: هجوم عبر الشبكة، بلا صلاحيات، بلا تفاعل من المستخدم، وتعقيد هجوم مرتفع، وأثر كامل على سرية الخادم وسلامته وتوفره.

ما الذي يفحصه ShieldWave

من الخارج لا يستطيع أحد معرفة هل طُبّق التصحيح على الخادم. ما يراه الفحص هو إصدار PHP الذي يعلنه الخادم عن نفسه.

• الفحص المجاني على shieldwave.io يقرأ ترويسة الاستجابة X-Powered-By. إذا أبلغ الخادم عن إصدار PHP أقدم من الإصدار المصحح لفرعه، أو عن فرع لا يحصل على أي إصلاح، يُدرج التقرير نتيجة php2shell تتضمن رقمَي CVE والإصدار الذي تحتاجه. تخفي استضافات كثيرة هذه الترويسة، والتوزيعات تُصحح دون تغيير الرقم، ولذلك فوجود نتيجة يعني "اسأل الاستضافة"، وغيابها لا يثبت أن الخادم مصحَّح.
• إضافة Ensomedia Security لـ WordPress تعرض إصدار PHP الذي يعمل عليه الموقع وهل هذا الفرع ما زال مدعومًا (صفحة الإضافة). وهذا يلتقط أسوأ حالة في هذه الحادثة: موقع على PHP 8.1 أو 8.0 أو 7.4 أو أقدم، لا يحصل على أي إصلاح رسمي. الإضافة مجانية ولا تحتاج إلى حساب، وهي في دليل WordPress.org. في لوحة التحكم اذهب إلى الإضافات (Plugins) > أضف جديد (Add New) وابحث عن "Ensomedia Security".

لمعرفة مستوى التصحيح بدقة، استخدم صفحة صحة الموقع والجدول أعلاه، وتأكد من الاستضافة.

المصادر

رسمية:

• مشروع PHP، إعلانات الإصدار والنشرة الأمنية، 20 و21 أكتوبر 2026: https://www.php.net/
• نشرة 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
• إصدارات PHP المدعومة: https://www.php.net/supported-versions.php
• سجل CVE لـ CVE-2026-109618 (جهة الترقيم CNA: PHP Group): https://www.cve.org/CVERecord?id=CVE-2026-109618
• NCSC في المملكة المتحدة، مشكلة أمنية حرجة تؤثر في PHP: https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
• توثيق WordPress.org، شاشة صحة الموقع: https://wordpress.org/documentation/article/site-health-screen/

أخرى:

• مدونة Cloudflare، Cloudflare تنشر حمايات ضد ثغرة php2shell: https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
• BleepingComputer، PHP تصدر تصحيحات طارئة لثغرات PHP2Shell الحرجة: https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/
• Tenable، أسئلة شائعة عن php2shell: https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote
• Sansec، PHP2Shell: https://sansec.io/research/php2shell