PHP2Shell: ما هو وكيفية حماية موقعك الإلكتروني المبني بـ PHP

تمت مراجعة الحقائق في 26/10/2026 بالرجوع إلى ملاحظات إصدارات PHP وتقارير الباحثين وشركات الأمان. سنحدّث هذا المقال عند صدور الإصدار القادم من PHP.

إذا كان موقعك يعمل بـ PHP، حدّث PHP اليوم. هذه خلاصة المقال.

في 21/10/2026 أصدرت PHP تصحيحات لثغرتين بالغتي الخطورة في PHP نفسه، تُعرفان معاً باسم PHP2Shell. تتيحان للمهاجم السيطرة على خادم الويب من الإنترنت دون الحاجة إلى اسم مستخدم أو كلمة مرور. وقد بدأت محاولات الاستغلال قبل صدور التصحيح.

يستخدم PHP في 69.2% من المواقع التي يُعرف نوع لغة الخادم لديها، وفقاً لـ W3Techs. يشمل ذلك WordPress، WooCommerce، Magento، Drupal، Joomla، Laravel ومعظم مواقع PHP المخصصة. لذا فالمشكلة لا تخص قلة من المواقع، بل تمس جزءاً كبيراً من الويب.

لأصحاب المواقع: PHP2Shell بلغة مبسطة

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

PHP2Shell هما ثغرتان في هذا المحرك. يمكن لأي شخص على الإنترنت إرسال طلب خاص إلى موقعك والسيطرة على الخادم الذي يشغّله. لا يحتاج إلى كلمة مرور أو حساب. هذه الثغرة ليست في القالب أو الإضافات، لذا تحديثها لا يحل المشكلة. الحل الوحيد هو تحديث PHP نفسه.

بعد الدخول، يمكن للمهاجم قراءة كلمات المرور والمفاتيح المخزنة على الخادم، والوصول إلى بيانات العملاء، وتغيير الموقع أو إخفاء منفذ خلفي للعودة لاحقًا. بدأ المهاجمون بمحاولة استغلال هذه الثغرة قبل صدور الإصلاح، لذا لا ينبغي تأجيل التعامل معها.

ما الذي يجب فعله اليوم:

1. اطلب من مطوّر الموقع أو شركة الاستضافة سؤالاً واحدًا: "هل تم تحديث PHP إلى إصدار يعالج PHP2Shell، وهل تم إعادة تشغيل PHP بعد ذلك؟" اطلب إجابة واضحة مكتوبة بنعم أو لا.
2. إذا كانت الإجابة لا أو "غير متأكد"، اطلب منهم معالجة الأمر اليوم. إذا كان موقعك يعمل بإصدار PHP قديم (8.1 أو أقدم)، فلا يوجد تحديث جاهز، ويجب وضع خطة ترقية فورًا.
3. إذا تم إصلاح المشكلة بالفعل، اطلب منهم فحص الخادم بحثًا عن أي مؤشرات لهجوم منذ 17 أكتوبر 2026 وتغيير كلمات المرور والمفاتيح المخزنة عليه.
4. إذا لم يكن هناك من يدير خادمك، أو لم تتمكن من الحصول على إجابة، اطلب المساعدة فورًا. كل يوم يبقى فيه الموقع غير محدث يزيد من احتمالية اكتشافه واستغلاله.

إذا كان متجرك يعمل على Shopify أو منصة مستضافة مشابهة، فلا داعي لاتخاذ إجراء: المنصة هي من تدير الخوادم، وليس أنت.

الملخص التنفيذي

• حدّث PHP إلى الإصدار 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35 (أو الأحدث)، ثم أعد تشغيل PHP-FPM أو Apache أو أي عامل PHP يعمل لفترات طويلة. تحديث WordPress أو Magento أو الإضافات لا يحدث PHP نفسه.
• إذا كنت على PHP 8.1 أو أقدم، لا يوجد تحديث رسمي جاهز. انتقل إلى إصدار مدعوم، أو استخدم حزمة استضافة أو Linux أضافت التصحيحات.
• لا يمكنك التحديث اليوم؟ فعّل قواعد جدار الحماية الخاصة بـ PHP2Shell وإعدادات PHP المذكورة في الخطوة 4 أدناه. هذه الإجراءات تقلل المخاطر لكنها لا توفر الحماية الكاملة.
• بعد التحديث، اعتبر أن جميع الأسرار المخزنة على الخادم قد تكون تسرّبت، وابحث عن علامات الهجوم منذ 17/10/2026.

ما هو PHP2Shell؟

PHP2Shell هو الاسم الذي أطلقه الباحثون على ثغرتين في محرك PHP، وكذلك على أداة الاستغلال التي تجمع بينهما. الثغرات ليست في القالب أو الإضافات أو الشيفرة الخاصة بك، بل في PHP نفسه، البرنامج الذي يشغّل موقعك على الخادم.

لهذا السبب تعتبر المشكلة بالغة الخطورة. يشير باحثو Wiz إلى أن حتى تطبيق "Hello World" بسيط على إصدار PHP متأثر يمكن أن يكون عرضة للخطر. أما على الخوادم التي تعمل بـ Apache مع mod_php، فتؤكد PHP نفسها وجود استغلال فعلي يعمل "قبل تنفيذ أي شيفرة تطبيق". قد يكون موقعك معرضاً للخطر حتى لو كانت شيفرتك خالية من الأخطاء.

بعبارة مبسطة: عندما يؤدي طلب ما إلى نفاد ذاكرة PHP (أو حدوث خطأ قاتل آخر في توقيت غير مناسب)، يوقف PHP ذلك الطلب بسرعة، وأحياناً لا ينظف البيانات بشكل صحيح. تبقى بيانات غير مكتملة أو بيانات كان يجب التخلص منها، ويعاملها PHP لاحقاً كأنها صالحة، أحياناً أثناء معالجة طلب زائر آخر على نفس العامل. يمكن للمهاجم استغلال ذلك عمداً عبر إرسال طلبات رفع ملفات مصممة خصيصاً، حتى في صفحات لا تستخدم الرفع، وتحويلها إلى تنفيذ أوامر خاصة به.

RCE تعني تنفيذ التعليمات البرمجية عن بُعد: أي أن شخصاً عبر الإنترنت يمكنه تشغيل تعليماته البرمجية على خادمك. OOM تعني نفاد الذاكرة. صنّفت PHP كلتا الثغرتين 9.2 من 10 (حرجة) وفق مقياس CVSS 4.0 الأحدث. بينما صنّفتهما قاعدة البيانات الوطنية للثغرات الأمنية الأمريكية بدرجتي 9.8 (حرجة) و8.1 (عالية) وفق مقياس CVSS 3.1 الأقدم، لذا قد ترى هذه الأرقام أيضاً. اسم PHP2Shell يصف النتيجة: من موقع PHP عادي إلى "shell"، أي وصول كامل إلى أوامر الخادم.

ما الذي يمكن أن يفعله المهاجم فعليًا؟

• تشغيل أوامر على خادم الويب دون الحاجة إلى اسم مستخدم أو كلمة مرور.
• قراءة أسرار من ذاكرة الخادم. تشير Wiz إلى "كلمات المرور، رموز المصادقة، مفاتيح API والشهادات". ولا يتطلب ذلك حتى أن ينفذ المهاجم تعليمات برمجية على خادمك، مما يجعله هادئاً وصعب الاكتشاف.
• استخدام هذه الأسرار للوصول إلى قاعدة البيانات وبيانات العملاء وحسابات مزودي الدفع.
• زرع باب خلفي مخفي ("web shell") للعودة لاحقًا، أو تغيير وتشويه موقعك.

كيف حدثت ثغرة PHP2Shell

تم الإبلاغ عن الثغرات في أغسطس، وحُفظت سراً أثناء تطوير التصحيح في PHP، ثم تم تسريع إصدار التصحيح بعد تسريب أرقام الثغرات.

وفقاً لـمؤسسة PHP، تسرب رقما CVE في 20 أكتوبر دون تفاصيل تقنية، رغم أن مقطع فيديو نشرته إحدى شركات الأبحاث عن طريق الخطأ كشف بعض التفاصيل المحدودة. كما ذكرت المؤسسة أن أحد مطوري نواة PHP لاحظ أولى مؤشرات مشكلة نفاد الذاكرة أثناء تدقيق في عام 2024، لكنها لم تُعالج حينها.

لماذا تم التعامل مع هذه الثغرة بسرعة

اعتمدت عملية الاكتشاف بشكل كبير على الذكاء الاصطناعي. توضح Wiz أنها استخدمت نماذج ذكاء اصطناعي (Wiz Atlas الخاص بها، Gemini 4 Argon من Google وGPT-5.6 Sol من OpenAI)، وأن "باحثًا واحدًا أنجز في أسبوع ما كان يتطلب من فريق عالمي شهورًا". فريق Codex Security من OpenAI وCalif ذُكروا إلى جانب Wiz على موقع PHP2Shell.

المهاجمون يمتلكون الأدوات نفسها. تحذر وحدة استخبارات التهديدات في Amazon من أن الذكاء الاصطناعي يجعل تحويل التصحيحات إلى استغلال عملي أقل تكلفة، بحيث "يمكن لعدد أكبر من الجهات الفاعلة التحرك خلال ساعات أو حتى دقائق". نصيحتهم للثغرات الحرجة في الأنظمة المتصلة بالإنترنت: "قِس جداول التصحيح والتخفيف بالساعات."

من المتأثر بثغرة PHP2Shell؟

الإصدارات الرسمية من PHP تغطي 8.2 حتى 8.5، بينما حصلت الإصدارات 7.4 و8.0 و8.1 فقط على تصحيحات لمصدر الشيفرة. ويشير الباحثون إلى أن الإصدارات المتأثرة تعود حتى PHP 5.4، وأن معظم إصدارات PHP تأثرت بإحدى الثغرتين على الأقل. إذا كان موقعك أو متجرك أو تطبيقك يعمل على PHP ولم تقم بالتحديث منذ 21/10/2026، فاعتبر نفسك متأثراً.

قائمة ProjectDiscovery تضم نحو 20 نوعاً من البرمجيات الطويلة التشغيل على PHP يجدر التحقق منها. كل ما يعمل على PHP مشمول، بما في ذلك:

• مواقع WordPress وWooCommerce، Magento / Adobe Commerce، Laravel، Drupal وJoomla
• Moodle، Nextcloud وMediaWiki
• أدوات الإدارة مثل phpMyAdmin، بريد الويب Roundcube وWHMCS
• لوحات الاستضافة مثل cPanel وPlesk
• أجهزة الشبكة التي تعتمد على PHP، من الجدران النارية (pfSense، OPNsense) إلى أنظمة الهاتف (FreePBX) وأدوات المراقبة (Zabbix، Nagios XI). ينشر المورّدون نشراتهم الخاصة؛ نشرة HPE لـ ClearPass Policy Manager مثال على ذلك.

الحجم كبير جداً. وفق أرقام نُشرت يوم صدور التصحيح، أحصت VulnCheck وجود PHP على 2,608,039 خادماً متصلاً بالإنترنت خلال 30 يوماً سابقة، وصنّفت 99.998% منها على أنها معرضة للخطر أو يُحتمل تعرضها. أكثر من 1.1 مليون منها، أي نحو 42%، تعمل بإصدارات PHP منتهية الدعم ولا تتوفر لها تصحيحات رسمية، ونحو 27% تعمل على PHP 7.3 أو أقدم. كثير من الخوادم لا يُظهر رقم إصدار PHP، لذا جزء من هذا الإحصاء هو تقدير من VulnCheck.

من غير المتأثرين

• المنصات المستضافة بالكامل مثل Shopify، حيث تدير المنصة الخوادم وليس أنت. يجب فحص أي مدونة WordPress أو أداة PHP تديرها بجانبها بشكل منفصل.
• المواقع التي لا تستخدم PHP على الخادم إطلاقاً: مثل Node.js، Next.js، Python أو صفحات HTML ثابتة فقط.
• الخوادم التي تم تحديثها إلى الإصدارات المصححة أدناه وأعيد تشغيلها منذ ذلك الحين. (يرجى متابعة الخطأ الثالث المذكور لاحقاً.)

إصدارات PHP المصححة

إذا كنت تستخدم PHP 8.2، فإن الدعم الأمني له ينتهي في 31/12/2026، لذا من الأفضل التخطيط للانتقال إلى 8.4 أو 8.5 الآن بدلاً من تصحيح النظام مرتين. نناقش هذا الموضوع بشكل أوسع في هل PHP لا تزال الخيار المناسب للتجارة الإلكترونية.

هل بدأ المهاجمون بالفعل في استغلال PHP2Shell؟

نعم، بدأت محاولات الاستغلال قبل الإعلان عن التصحيح.

• قبل أربعة أيام: سجّلت مصائد MadPot من Amazon (خوادم وهمية لجذب المهاجمين) محاولة استغلال PHP2Shell بتاريخ 17/10/2026، أي قبل أربعة أيام من الإعلان الرسمي.
• قبل ساعة الإصدار: أفادت Amazon بظهور استغلالات إثبات المفهوم بدءاً من حوالي 02:00 بتوقيت UTC في 21/10، أي قبل إصدار الإصدارات المصححة باثنتي عشرة ساعة، وتزايدت المحاولات خلال الساعات التالية. وتفيد الآن بوجود "محاولات استغلال واسعة النطاق في الواقع العملي".
• المسح الآلي: رصدت VulnCheck أدوات مسح تستخدم user-agent php2shell-scan/109618، ومحاولة واحدة من عنوان IP في الصين لزرع web shell عبر ملف جلسة. هذه المحاولة لم تنجح.
• استغلالات وهمية: تنتشر مستودعات إثبات مفهوم مزيفة على GitHub. لا تقم مطلقاً بتشغيل كود استغلال تم تحميله على خادم مهم لديك.

اختارت بعض المؤسسات إيقاف مواقعها مؤقتاً بدلاً من الانتظار. ووفقاً للتقارير الإخبارية التي جمعها صفحة PHP2Shell في ويكيبيديا، أوقفت العديد من المؤسسات الأوروبية مواقعها بناءً على توصية CERT-EU وNCSC البريطانية، كما أوصت وكالة الأمن القومي الأمريكية بإيقاف المواقع إذا تعذر تحديثها فوراً. وأوقفت فنلندا خدماتها الحكومية العامة على الإنترنت، كما أغلق أرشيف الإنترنت مؤقتاً.

ثغرة ثالثة أقل خطورة (23 أكتوبر)

بعد يومين من التصحيح الرئيسي، نشرت PHP تنبيهاً معلوماتياً حول ثغرة ذات صلة، CVE-2026-115560، في ميزة تتبع تقدم رفع الجلسة. ووفقاً لـCloudflare، تؤثر هذه الثغرة أيضاً على الإصدارات المصححة، بما في ذلك 8.5.12. وتصفها PHP بأنها "مسار RCE غير مرجح" يتطلب إعداد جلسة غير معتاد. وحتى صدور الإصدار المنتظم التالي من PHP، توصي PHP بتعيين session.upload_progress.enabled=0.

كيفية حماية موقعك المبني على PHP: خمس خطوات

تحديث PHP هو الحل الكامل الوحيد. بيان الأمان من PHP واضح: «لا توجد حلول تخفيفية كاملة، والتحديث هو الخيار الآمن الوحيد». يُنصح باتباع الخطوات التالية بالترتيب.

الخطوة 1: حدد جميع أماكن تشغيل PHP

أعد قائمة بكل خادم أو موقع أو أداة تملكها وتستخدم PHP. لا تنس:

• نسخ الاستيج أو الاختبار من موقعك
• مواقع الحملات القديمة أو صفحات الهبوط التي أنشأتها وكالة
• أدوات الإدارة مثل phpMyAdmin أو البريد الإلكتروني عبر الويب
• حاويات Docker المبنية على صورة php: قديمة
• لوحات الاستضافة والأجهزة الشبكية

من السهل إغفال المواقع المنسية ونادراً ما يتم تحديثها. أثناء ذلك، تحقق من أن منفذ PHP-FPM رقم 9000 غير متاح من الإنترنت: تشير ProjectDiscovery إلى أن صور Docker الرسمية لـ php-fpm تستمع عليه على جميع واجهات الشبكة. إذا ورثت قاعدة شيفرة أو خادماً لا يفهمه أحد بشكل كامل، فإن إطار العمل الخاص بنا لفحص PHP القديم هو نقطة انطلاق جيدة.

الخطوة 2: تحقق من إصدار PHP لديك

• الاستضافة المشتركة أو cPanel: ابحث في لوحة الاستضافة ضمن "Select PHP Version" أو "MultiPHP Manager".
• الخادم الخاص بك (VPS): نفذ الأمر php -v و php-fpm -v على الخادم. في بعض الأنظمة يحمل أمر FPM رقم الإصدار، مثل php-fpm8.3 -v.
• WordPress: انتقل إلى الأدوات ← صحة الموقع ← المعلومات ← الخادم.

قارن الإصدار بجدول الإصدارات المصححة أعلاه. إذا كان مزود الخدمة أو توزيعة Linux تقوم بإضافة التصحيحات إلى الإصدارات القديمة، تحقق من سجل تغييرات الحزمة لكلا رقمي CVE بدلاً من رقم الإصدار فقط.

الخطوة 3: حدّث PHP ثم أعد تشغيله

قم بتثبيت الإصدار المصحح، ثم أعد تشغيل Apache وPHP-FPM وLiteSpeed وأي عمال PHP يعملون باستمرار. ينصح الباحثون بـ "تثبيت إصدار PHP مصحح على كل بيئة تشغيل ثم إعادة التشغيل". حتى تعيد التشغيل، سيستمر الإصدار القديم من PHP في معالجة الطلبات. إذا كنت تستخدم Apache مع mod_php، ابدأ بهذه الخوادم أولاً: تعتبرها PHP الأعلى خطورة.

تحديث WordPress أو Magento أو الإضافات لا يحدث PHP نفسه. PHP برنامج منفصل على الخادم. بالنسبة لـ Docker، أعد بناء الصورة على قاعدة php: مصححة وأعد النشر.

الخطوة 4: إذا لم تتمكن من التحديث اليوم

هذه الخطوات تقلل المخاطر لفترة قصيرة فقط. بيان الأمان من PHP يوضح أن هذه الإجراءات "تقلل التعرض لمسارات هجوم محددة لكنها لا تجعل التثبيت آمناً". بعضها قد يعطل رفع الملفات، لذا تحقق من موقعك بعد كل تغيير.

• فعّل قواعد PHP2Shell في جدار الحماية الخاص بك. قامت Cloudflare بتفعيل القواعد تلقائياً في جميع الخطط التي تشمل WAF، بما فيها المجانية. وتذكر Fortinet أن الحماية متوفرة في FortiWeb وFortiGate وفق تنبيه التفشي. بالنسبة لثغرة 23 أكتوبر، لا تغطي قاعدة Cloudflare المواقع التي غيّرت اسم session.upload_progress.name.
• عطّل تتبع تقدم الرفع: عيّن session.upload_progress.enabled=0 في php.ini أو إعدادات تجمع PHP-FPM، ثم أعد تشغيل جميع العمال. التعيين عبر ini_set() أو ملف .user.ini لا يعمل هنا.
• قلل حجم جسم الطلب: عيّن post_max_size إلى 8M إذا كان الموقع لا يستقبل ملفات مرفوعة، أو 32M إذا كان يستقبلها. تقترح Amazon أيضاً حظر رفع الملفات متعددة الأجزاء على الخوادم التي لا يمكنك تصحيحها بعد.
• في PHP 8.5، عيّن أيضاً fatal_error_backtraces=0 وأعد تشغيل جميع العمال.
• أوقف الموقع مؤقتاً أو ضع عليه تسجيل دخول إذا كان يحتوي على بيانات حساسة. هذا ما قامت به بعض الجهات الحكومية.

الخطوة 5: بعد التحديث، تحقق مما إذا تم استهدافك

إذا كان الخادم متاحاً عبر الإنترنت قبل التحديث، افترض أن الأسرار في ذاكرته قد تكون تسرّبت. راجع السجلات على الأقل حتى 17/10/2026، وهو أقدم تاريخ محاولة أبلغت عنه Amazon.

• غيّر كلمات مرور قاعدة البيانات، ومفاتيح API، ومفاتيح بوابات الدفع، وكلمات مرور SMTP، ومفاتيح توقيع الجلسات (مثل أملاح WordPress أو مفتاح تشفير Magento مع مطور، حيث يكون ذلك آمناً).
• ابحث عن مستخدمين إداريين جدد أو غير معروفين، أو ملفات PHP جديدة أو معدلة (خاصة في مجلدات الرفع والجلسات)، أو مهام مجدولة جديدة (cron jobs).
• تحقق من سجلات الطلبات بحثاً عن عمليات رفع POST تتضمن PHP_SESSION_UPLOAD_PROGRESS (Amazon)، وعن طلبات multipart متبوعة بأخطاء "Allowed memory size of … bytes exhausted"، أو تكرار أخطاء 500، أو تعطل عمال PHP (Wiz).
• راقب وجود ملفات تعريف ارتباط PHPSESSID كبيرة أو غير معتادة في الردود (Wiz)، أو النص PWNED:: في الردود أو ملفات الجلسات (VulnCheck).
• ابحث عن عمليات غير معروفة واتصالات صادرة غير متوقعة من الخادم.

إذا وجدت أي شيء غير طبيعي، اطلب مساعدة خبير قبل البدء في التنظيف حتى لا تتلف الأدلة.

الخلاصة

تُعد PHP2Shell من أخطر مشكلات الأمان على الويب منذ سنوات. فهي في قلب PHP نفسه، ويمكن الوصول إليها من الإنترنت دون تسجيل دخول، وبدأ المهاجمون بمحاولات الاستغلال قبل صدور التصحيح.

الحل بسيط: حدّث PHP، أعد تشغيله، وتحقق من كل خادم. نفّذ ذلك اليوم وليس الأسبوع القادم. استغل الفرصة لإيقاف أي تطبيق قديم ما زال يعمل على PHP منتهي الدعم. إذا كان تطبيق قديم بالكامل يعيقك، كتبنا عن نقل تطبيق PHP أحادي إلى Laravel دون تجميد الميزات.

تحتاج مساعدة في تصحيح PHP2Shell؟

ندير ونعتني بمواقع WordPress وWooCommerce، Magento، Laravel وPHP المخصص يومياً. يمكننا تحديد جميع مواقع وخوادم PHP لديك، تحديث PHP بأمان وإعادة تشغيله، إعداد جدار حماية ويب، تدوير كلمات المرور والمفاتيح، فحص علامات الاختراق، ونقل المواقع القديمة من PHP 7.x، 8.0 و8.1 منتهية الدعم.

تواصل معنا أو أرسل رسالة إلى info@stathmosgroup.com وسنبدأ بخادمك الأكثر عرضة للمخاطر.