PHP2Shell: ثغرة «نهاية العالم» في PHP وكيف تحركت كبرى الشركات لاحتواء الكارثة

ما هي ثغرة PHP2Shell؟

في 21 أكتوبر 2026، أعلن مشروع PHP عن تحديثات أمنية طارئة لثغرتين حرجتين في نواة اللغة نفسها، أطلق عليهما مجتمعياً اسم PHP2Shell. الثغرتان، المعروفتان رسمياً بـ CVE-2026-109618 و CVE-2026-109619، تحملان تقييماً خطيراً بلغ 9.2 على مقياس CVSS v4.0 .

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

الإصدارات المتأثرة تشمل كل شيء من PHP 5.4 فصاعداً، أي ما يقارب 20 عاماً من الإصدارات. الإصدارات المُصلحة هي 8.5.12، 8.4.27، 8.3.36، و 8.2.35 . إصدارات PHP 5.x و 7.x انتهى دعمها ولا تتلقى إصلاحات رسمية، مما يجبر المسؤولين على الترقية إلى فرع مدعوم .

لماذا هي خطيرة إلى هذا الحد؟

السبب في خطورتها هو مزيج من ثلاثة عوامل:

الانتشار الواسع: PHP يشغل حوالي 70% من مواقع الإنترنت، من المدونات الصغيرة إلى منصات التجارة الإلكترونية الكبرى .
سهولة الاستغلال النسبية: على الرغم من أن السلسلة معقدة تقنياً (تتطلب تجاوز ASLR، والتحكم في توقيت الذاكرة، وإصابة نفس “العامل” (Worker) في Apache)، إلا أن باحثي الأمن تمكنوا من تقليص عدد الطلبات المطلوبة للاستغلال من عشرات الآلاف إلى حوالي 20 طلباً فقط في بعض السيناريوهات .
الاستغلال المبكر: بدأت محاولات الاستغلال قبل الإعلان الرسمي. شبكة Honeypot التابعة لأمازون رصدت أول محاولة في 17 أكتوبر، أي قبل أربعة أيام من نشر التحديثات. وبعد الإعلان، سجلت Cloudflare ملايين محاولات الاستغلال .

تداعيات الاستغلال: ماذا يحدث إذا نجح الهجوم؟

إذا تمكن المهاجم من استغلال الثغرة بنجاح، فإنه يحصل على تنفيذ أوامر على الخادم بصلاحيات مستخدم خدمة الويب (مثل www-data أو apache). هذا يفتح الباب لـ:

سرقة البيانات: قراءة ملفات الإعدادات، قواعد البيانات، ومفاتيح API.
تثبيت برمجيات خبيثة: رصد باحثو الأمن محاولات لتنزيل شبكات بوتنت (Botnet) على غرار Mirai .
التجسس والتحكم: استخدام الخادم كنقطة انطلاق لهجمات أخرى داخل الشبكة.

كيف استجابت كبرى الشركات العالمية؟

بمجرد انتشار الخبر، تحركت الشركات الكبرى بسرعة، كل في مجالها:

عمالقة السحابة

Amazon (AWS): رصدت الهجمات مبكراً، وعملت على تحديث خدماتها مثل Elastic Beanstalk و WorkMail و Amazon Linux و Lightsail. كما أكدت أن أنظمتها الداخلية تقيد تلقائياً المسح الضار .
Google Cloud: أكدت أن بنيتها التحتية الأساسية غير متأثرة، لكنها قامت بتحديث بيئات PHP في App Engine تلقائياً، وطالبت العملاء الذين يستخدمون Cloud Run بإعادة بناء صورهم (Images) يدوياً .
Microsoft: (لم تذكر المصادر تفاصيل محددة عن استجابة مايكروسوفت، لكنها كانت ضمن الشركات التي أصدرت توجيهات لعملائها).

شركات الأمن السيبراني

Cloudflare: لعبت دوراً مزدوجاً: كشفت عن ملايين محاولات الاستغلال، وقدمت حلول حماية (WAF) لعملائها لاعتراض الهجمات .
CrowdStrike: أكدت أن استغلال الثغرة ممكن نظرياً (استنسخت هجوماً ناجحاً في المختبر)، لكنها لم ترصد استغلالاً ناجحاً في البرية حتى كتابة هذه السطور. أضافت كشفاً في منصتها Falcon .
Palo Alto Networks: أصدرت توجيهات وحلولاً مؤقتة، وحددت خطورة الثغرة على منتجاتها بـ 8.7 .
Sophos: اكتشفت أن بوابة قديمة لها (MyUTM) كانت تعمل بإصدار PHP متأثر، فقامت بإغلاقها مؤقتاً .

بائعو العتاد والبرمجيات المؤسسية

Cisco: أصدرت تحذيراً يغطي أكثر من 30 منتجاً، لكنها لم تؤكد إصابة أي منها حتى الآن .
Red Hat: قللت من خطورة الثغرة، وقيّمتها بـ 8.1 بدلاً من 9.8، مشيرة إلى أن الاستغلال الموثوق يتطلب “تلاعباً دقيقاً بالذاكرة وتوقيتاً محدداً” .
القطاع الصناعي (Siemens, Schneider Electric, ABB): كانت هذه المرة الأكثر إثارة للقلق. أعلنت Schneider Electric إصابة ثلاثة من منتجاتها (EcoStruxure Security Expert وغيرها). Siemens أكدت إصابة أجهزة Ruggedcom APE1808 التي تعمل بأنظمة Palo Alto. ABB أبلغت عن إصابة أنظمة تحكم صناعي (APROL) وبرامج أخرى .

كيف استجابت مشاريع البرمجيات الحرة والتوزيعات؟

كانت التوزيعات هي خط الدفاع الأول، وكانت استجابتها سريعة وحاسمة:

التوزيعات الرئيسية

Ubuntu: أصدرت تحديثات لجميع إصداراتها المدعومة في يوم الإعلان (21 أكتوبر) .
Debian: عالجت الثغرة في إصداري bookworm و trixie .
Fedora / Red Hat / SUSE / Gentoo / Slackware: جميعها أصدرت حزماً محدثة في نفس اليوم أو في اليوم التالي .
توزيعات أخرى: مثل Alpine و Arch Linux، أصدرت تحديثات عبر مستودعاتها المعتادة.

مشاريع البرمجيات الحرة

cPanel, Plesk, DirectAdmin: هذه لوحات التحكم الشهيرة باستضافة المواقع، أصدرت تحديثات طارئة. والأهم أن cPanel و Plesk قدموا تحديثات حتى لإصدارات PHP القديمة (7.4، 8.0، 8.1) رغم انتهاء دعمها رسمياً، نظراً لخطورة الموقف .
WordPress و Drupal و Joomla: هذه الأنظمة الأساسية التي تعتمد على PHP، نصحت مستخدميها بالتحديث الفوري، لكنها لم تحتج لإصدار تحديثات خاصة بها لأن الثغرة في PHP نفسها وليس في كودها.

ماذا يجب أن تفعل إذا كنت تدير خادماً؟

الإجراء الوحيد الكامل هو التحديث الفوري إلى أحد الإصدارات المُصلحة. لكن إذا لم تتمكن من ذلك فوراً، هناك إجراءات تخفيف مؤقتة:

على مستوى جدار الحماية (WAF): امنع الطلبات التي تحمل ترويسة Content-Type: multipart/form-data إذا لم تكن بحاجة لرفع الملفات. هذا يعطل رفع الملفات مؤقتاً لكنه يغلق ناقل الهجوم الرئيسي .
تعطيل session.upload_progress.enabled: هذا يمنع أحد مسارات الهجوم (CVE-2026-109619)، لكنه لا يحمي من مسار استنفاد الذاكرة (CVE-2026-109618) .
ضبط memory_limit: على الرغم من أن تعيينه إلى -1 (غير محدود) قد يبدو خطراً، إلا أنه في هذه الحالة يمنع حالة “استنفاد الذاكرة” التي تستغلها الثغرة. لكن هذا ليس حلاً سحرياً .
إعادة تشغيل الخدمات: بعد التحديث، يجب إعادة تشغيل Apache و PHP-FPM وأي عمليات خلفية تعمل بـ PHP. تحديث الملفات على القرص لا يكفي إذا كانت العمليات القديمة لا تزال تعمل في الذاكرة .
إعادة بناء الحاويات (Docker): إذا كنت تستخدم PHP داخل حاوية، فيجب إعادة بناء الصورة (Image) باستخدام الإصدار المُصلح. تحديث الحزمة على المضيف لا يصل إلى داخل الحاوية .

خلاصة

PHP2Shell هي تذكير قاسٍ بأن البنية التحتية للإنترنت، رغم قدمها وانتشارها، تظل هشة. سرعة استجابة المجتمع (التوزيعات، مشاريع البرمجيات الحرة، وعمالقة السحابة) كانت مبهرة، لكن الثغرة كشفت أيضاً عن مشكلة “الأجهزة المنسية” — الخوادم القديمة، أجهزة NAS، والأنظمة الصناعية التي تعمل بإصدارات PHP لا يتذكرها أحد. إذا كنت تدير أي نظام يعمل بـ PHP، فالتحديث الآن ليس خياراً، بل ضرورة.