في 21 أكتوبر 2026 أصدر مشروع PHP الإصدارات 8.5.12 و8.4.27 و8.3.36 و8.2.35، وطلب من كل مستخدمي PHP التحديث فورًا. الثغرتان اللتان تعالجهما هذه الإصدارات، CVE-2026-109618 وCVE-2026-109619، والمعروفتان باسم PHP2Shell، قد تسمحان للمهاجم بتشغيل شيفرة على خادم الويب دون تسجيل دخول. وقد أثبت الباحثون الذين كشفوا عنهما ذلك على WordPress وDrupal وJoomla.
ما يربك كثيرين هو مكان الخلل. فهو في PHP نفسه، لا في WordPress ولا في إضافة. الضغط على «تحديث» في لوحة WordPress لا يعالجه، ولا تحديث حزم Composer. وإن كان موقعك يعمل في Docker، فالحاوية العاملة تبقى على نسخة PHP التي بُنيت بها حتى تعيد بناءها. يشرح هذا الدليل كيف تتحقق مما تشغّله فعلًا، وكيف ترقّعه، وما الذي تفحصه بعد ذلك.
ما هي PHP2Shell
بحسب النشرة الأمنية لمشروع PHP، الثغرتان هما:
- CVE-2026-109618، تنفيذ شيفرة عن بُعد عبر تلف نفاد الذاكرة. عندما تنفد ذاكرة PHP في لحظة غير مناسبة، قد تبقى بيانات الطلب نصف مهيّأة، ثم تتعامل شيفرة التنظيف معها كأنها صالحة.
- CVE-2026-109619، تنفيذ شيفرة عن بُعد عبر حالة عامة قديمة. قد تبقى حالة تخص طلبًا ما بعد تحرير ذاكرتها، فيستخدمها طلب لاحق يعالجه العامل نفسه.
يمنح موقع الإفصاح، الصادر عن Wiz Research وOpenAI Codex Security وCalif، الثغرتين تقييم CVSS 9.2. ويذكر أنه نفّذ شيفرة عن بُعد قبل المصادقة على WordPress وDrupal وJoomla، وأن الثغرة الثانية قد تسرّب أيضًا ذاكرة العامل. والنقطة الأهم لأصحاب المواقع: حتى سكربت «Hello World» بسيط على نسخة PHP متأثرة مكشوف، لأن الشيفرة المعيبة تعمل قبل تطبيقك.
يذكر مشروع PHP أن PHP-FPM وApache مع mod_php وphp-cgi وFrankenPHP وLiteSpeed كلها متأثرة، ويعدّ الخطر الأعلى في mod_php، حيث لديه استغلال يعمل قبل تشغيل أي شيفرة للتطبيق. وتضيف نشرة Red Hat أن إعداد PHP-FPM الافتراضي لديها يجعل الاستغلال أصعب عمليًا، وأن mod_php بإعداداته الافتراضية أعلى خطرًا. هذا الفرق مهم لـ WordPress في Docker: صور wordpress:*-apache الرسمية تشغّل PHP داخل Apache بوصفه mod_php.
الخطوة 1: تحقّق من PHP الذي يخدم الطلبات فعلًا
على خادم عادي، يعرض php -v إصدار سطر الأوامر، وليس دائمًا ما يستخدمه خادم الويب. وعلى Debian وUbuntu قد يضللك في الاتجاه المعاكس أيضًا: عالجت Ubuntu الثغرة بنقل الرقعة إلى نسختها، فيكون Ubuntu 24.04 آمنًا على 8.3.6-0ubuntu0.24.04.13 مع أن الإصدار ما زال يظهر 8.3.6. قارن رقم الحزمة الكامل بنشرة توزيعتك، لا برقم الإصدار الأصلي.
أما الحاويات فاسأل كل حاوية عاملة مباشرة. يعرض هذا الأمر كل حاوية على الخادم تحتوي PHP، مع إصدارها وصورتها:
for c in $(docker ps --format '{{.Names}}'); do v=$(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null) && echo "$c $v $(docker inspect -f '{{.Config.Image}}' "$c")"; done
نسخ PHP الرسمية مُصلحة ابتداءً من 8.2.35 و8.3.36 و8.4.27 و8.5.12. أي نسخة أقدم في الفرع نفسه، أو أي نسخة 8.1 أو أقدم، تحتاج إلى إجراء.
الخطوة 2: أعد البناء، لا تكتفِ بإعادة التشغيل
تقول Docker إن صورها الرسمية على Docker Hub تحمل PHP المُصلح بالفعل. لكن هذا لا ينفع إلا بعد سحبها. إعادة التشغيل تستخدم الصورة القديمة، وملف Dockerfile الذي يثبّت وسم رقعة محددًا مثل FROM php:8.2.33-apache لن يحصل على الإصلاح وحده. لمشروع Compose يُبنى من Dockerfile:
docker compose build --pull && docker compose up -d
ولخدمة تستخدم صورة منشورة مباشرة، شغّل docker compose pull قبل up -d. ثم أعد تشغيل الحلقة من الخطوة 1 وتأكد من الإصدار الجديد داخل الحاوية. وإن لم تصدر صورة طرف ثالث (حزمة LAMP جاهزة أو جهاز من مورّد) نسخة مُصلحة بعد، فأنت تنتظر ذلك المورّد، ولا تملك حتى ذلك الحين إلا إجراءات التخفيف أدناه.
الخطوة 3: إن كنت على PHP 8.1 أو أقدم
لم يعد مشروع PHP يصدر نسخًا لـ 8.1 وما قبله. نشر فريق الأمن رقعًا مصدرية مصغّرة لـ 7.4 و8.0 و8.1 لمن يبني من المصدر، وبعض التوزيعات ومورّدي الدعم الطويل يشحنون نسخهم المُصلحة. أما الحاوية المبنية من وسم php:7.4 قديم فلا تحصل على أيٍّ منهما. مواقع WordPress القديمة التي تعتمد على إضافات مشفّرة بـ ionCube تبقى غالبًا على 7.4 لهذا السبب تحديدًا. الحل الحقيقي نقلها إلى فرع مدعوم. وحتى ذلك الحين، اعتبرها مكشوفة.
إجراءات تخفيف ريثما ترقّع
يقول مشروع PHP والباحثون كلاهما إن التحديث هو الإصلاح الكامل الوحيد. إن احتجت ساعات لا دقائق، تذكر نشرة PHP طرقًا لتضييق مسارات هجوم محددة:
- اضبط
memory_limit=-1بطريقة لا يستطيع التطبيق تجاوزها، مثلphp_admin_valueفي مجمّع FPM أو إعدادات Apache. هذا يزيل فشل حد الذاكرة المتوقع الذي يعتمد عليه الاستغلال الأول، لكن ليس كل الطرق إليه. - أبقِ
post_max_sizeمتحفظًا، وقيّد حجم الطلب وعمق المدخلات وأجزاء multipart عند الوكيل العكسي. وإن لم يكن الموقع يقبل بيانات multipart أصلًا، فاحجبها في الواجهة. - اضبط
session.upload_progress.enabled=0. في 23 أكتوبر طلب مشروع PHP من الجميع ذلك حتى الإصدار الدوري القادم، بسبب مسار تنفيذ عن بُعد منفصل وأقل احتمالًا (CVE-2026-115560) ما زال قائمًا في النسخ المُصلحة.
الخطوة 4: تحقّق إن كان أحد قد دخل قبلك
الترقيع يغلق الثغرة لكنه لا يزيل ما قد يكون المهاجم تركه. لمواقع WordPress، هذه هي الفحوص التي نشغّلها على خوادمنا، كلها عبر WP-CLI داخل الحاوية:
wp core verify-checksums --allow-rootيقارن كل ملف أساسي بنسخته على wordpress.org.wp plugin verify-checksums --all --allow-rootيفعل الشيء نفسه للإضافات من دليل wordpress.org. الإضافات المدفوعة والمخصصة تُتخطّى مع تحذير 404، فراجعها وحدها. عدم التطابق ليس دليل اختراق، فبعض المورّدين يعدّلون مكتبات مضمّنة، لكن كل ملف غير مطابق يستحق البحث فيه عنevalأوbase64_decodeأوgzinflateعلى مدخلات الطلب.find wp-content/uploads -name "*.php*"يجد ملفات PHP في مجلد الرفع، حيث لا ينبغي أن توجد شيفرة. بعض إضافات الأمان تحفظ إعداداتها هناك، فافحص كل نتيجة قبل حذفها.- اعرض ملفات PHP التي تغيّرت منذ 20 أكتوبر وطابقها مع التحديثات التي تعرف أنك ثبّتها.
بحسب الباحثين، قد تسرّب الثغرة الثانية ذاكرة العامل. إن بقي موقع دون ترقيع ومتاحًا بعد الإفصاح في 21 أكتوبر، فغيّر ما قد تكون تلك الذاكرة احتوته: مفاتيح WordPress السرية في wp-config.php، وكلمات مرور قاعدة البيانات، وبيانات SMTP، ومفاتيح API للدفع أو البريد.
تحديث 27 أكتوبر 2026، لنظام Windows فقط: نشر مشروع PHP في 26 أكتوبر حزم Windows معادة البناء 8.5.12-1 و8.4.27-1 و8.3.36-1 و8.2.35-1. تتضمن Brotli 1.2.1 الذي يصلح CVE-2026-111497، وهي كتابة خارج الحدود يقول PHP إنه يمكن الوصول إليها عبر امتداد cURL عند تفعيل فك ضغط استجابات HTTP تلقائيًا. رقم إصدار PHP لا يتغير، لذا تحقّق على Windows من حزمة -1 في صفحة تنزيلات Windows، لا من php -v وحده. إصدارات Linux وDocker ليست جزءًا من إعادة البناء هذه.
الأسئلة الشائعة
هل يعالج تحديث WordPress ثغرة PHP2Shell؟
لا. الخلل في بيئة تشغيل PHP. تحتاج إلى PHP 8.2.35 أو 8.3.36 أو 8.4.27 أو 8.5.12 أو نسخة توزيعة فيها الرقعة المنقولة، ثم إعادة تشغيل أو إعادة بناء الحاوية ليستخدمها خادم الويب.
هل PHP-FPM آمن؟
لا. يذكر مشروع PHP أن FPM متأثر، وأكّد الباحثون تنفيذ شيفرة عن بُعد عليه عبر مسارات في شيفرة التطبيق. وتقول Red Hat إن الاستغلال أصعب على إعداد FPM الافتراضي لديها منه على mod_php، ما يخفض الخطر دون أن يزيله.
مزوّد الاستضافة يقول إن PHP 8.3.6 مرقّع. هل هذا صحيح؟
قد يكون صحيحًا. عالجت Ubuntu وتوزيعات أخرى PHP2Shell بنقل الرقعة دون تغيير رقم الإصدار. قارن رقم الحزمة الكامل بنشرة توزيعتك.
ما نسخ PHP التي لا إصلاح لها إطلاقًا؟
لا يصدر مشروع PHP أي نسخة لـ 8.1 وما قبله. لا تغطيها إلا الرقع المصدرية ونسخ التوزيعات ومورّدو الدعم الطويل.
المصادر: النشرة الأمنية لـ PHP (21 و23 أكتوبر 2026)، php2shell.com (Wiz Research وOpenAI Codex Security وCalif)، Red Hat RHSB-2026-013، وUbuntu وDocker.
