ما هي ثغرة PHP2Shell ولماذا تهدد مواقع الويب

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

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

ما هي ثغرة PHP2Shell؟

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

تكمن خطورة الثغرتين في إمكانية الوصول إلى تنفيذ برمجي عن بُعد (Remote Code Execution أو RCE) من خلال طلب ويب ضار. وفي حال نجاح الاستغلال، قد يتمكن المهاجم من تنفيذ أوامر بصلاحيات عملية PHP، أو الوصول إلى بيانات يستطيع الخادم الوصول إليها. لكن حجم الضرر الفعلي يعتمد على إعدادات الخادم وصلاحياته ومدى عزله.

كيف تعمل ثغرة PHP2Shell بصورة مبسطة؟

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

تزداد خطورة المشكلة لأن الخلل يقع داخل محرك PHP نفسه، وقد يحدث قبل أن يبدأ كود الموقع أو إضافاته في معالجة الطلب. ولهذا لا يكفي افتراض أن الموقع آمن لمجرد تحديث قالب ووردبريس أو تفعيل إضافة حماية. وقد أكّد فريق CERT-EU أن إعداد Apache مع mod_php من الحالات الأعلى خطورة، مع شمول نطاق التأثر طرق تشغيل أخرى.

ما المواقع والخوادم التي قد تتأثر؟

يمكن أن تتأثر مواقع تعتمد على PHP لتشغيل صفحاتها أو خدماتها، ومنها مواقع ووردبريس ومتاجر إلكترونية وتطبيقات ويب مخصصة. كذلك تشمل بيئات التشغيل المعنية PHP-FPM وApache مع mod_php وphp-cgi وLiteSpeed وFrankenPHP. لكن وجود أحد هذه الأنظمة لا يثبت اختراقه؛ بل يستدعي التحقق من إصدار PHP وتصحيحات مزود الاستضافة.

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

ما إصدارات PHP التي أصلحت ثغرة PHP2Shell؟

أصدر فريق PHP التحديثات الأمنية التالية في 21 أكتوبر 2026. وتمثل الأرقام الحد الأدنى للإصدارات التي تتضمن إصلاح الثغرتين في الفروع المذكورة:

فرع PHP	الإصدار المصحح لهذه الثغرات
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 والإصدارات الأقدم، فقد انتهى دعمها الأمني المباشر من مشروع PHP. ومع ذلك، قد توفر بعض توزيعات لينكس أو شركات الدعم الممتد تصحيحات داخل الحزم الخاصة بها، حتى إن ظل رقم الإصدار الأساسي ثابتًا. لذلك لا يصح الحكم على حالة خادم مُدار بالاعتماد على الرقم الظاهر وحده دون مراجعة إشعار المورّد. وبالنسبة إلى PHP 8.2، ينتهي دعمه من المشروع في 31 ديسمبر 2026، لذا ينبغي التخطيط للانتقال إلى فرع مدعوم.

كيفية معرفة ما إذا كان موقعك معرضًا لثغرة PHP2Shell

1. اعرف الإصدار الفعلي: إذا كنت تستخدم ووردبريس، افتح لوحة التحكم ثم أدوات ← صحة الموقع ← معلومات ← الخادم وابحث عن نسخة PHP. وقد تظهر المعلومة أيضًا في لوحة استضافة موقعك.
2. قارن الإصدار بالإصدارات المصححة: استخدم الجدول السابق، مع الانتباه إلى أن بعض الحزم المدعومة من شركات الاستضافة تتضمن إصلاحًا أمنيًا دون تغيير رقم الإصدار الرئيسي.
3. اسأل مزود الاستضافة عند الشك: اطلب تأكيدًا واضحًا بأن بيئة الموقع تلقت تصحيحات CVE-2026-109618 وCVE-2026-109619، ولا تعتمد على رد عام يقول إن «السيرفر محمي».
4. جهز نسخة احتياطية قابلة للاستعادة: احتفظ بنسخة من ملفات الموقع وقاعدة البيانات قبل الانتقال إلى إصدار جديد، وتأكد من إمكان استعادتها عند الحاجة.
5. اختبر التوافق ثم حدّث: افحص توافق القالب والإضافات مع إصدار PHP مدعوم، ويفضل اختبار التغيير في بيئة تجريبية إن كانت متاحة. بعد ذلك نفّذ التحديث عبر لوحة الاستضافة أو اطلب من المسؤول عن الخادم تنفيذه.
6. تحقق بعد التحديث: راجع الإصدار الجديد وسجلات الأخطاء والصفحات الأساسية ونماذج التواصل وعمليات الدفع إن وجدت. وإذا ظهرت مؤشرات اختراق، اطلب فحصًا أمنيًا متخصصًا؛ فالتحديث لا يمحو آثار هجوم سابق.

هذه الخطوات موجهة لمالك الموقع أو مسؤول الاستضافة. أما زائر الموقع العادي فلا يستطيع تحديث PHP على خادم لا يديره. ويمكنه، عند ظهور تحذير موثوق حول موقع معيّن، تجنب إدخال بيانات حساسة فيه إلى أن تتضح حالته الأمنية.

هل يكفي جدار الحماية أو تحديث ووردبريس؟

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

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

هل ظهرت ثغرة ثالثة بعد PHP2Shell؟

نعم، نشر فريق PHP في 23 أكتوبر 2026 تنبيهًا منفصلًا حول مسار نادر لتنفيذ البرمجيات عن بُعد، سُجل بالرقم CVE-2026-115560. ويحتاج هذا المسار إلى مجموعة غير معتادة من إعدادات الجلسات وتغييرها أثناء التشغيل. ولذلك لم يصدر الفريق تحديثًا طارئًا جديدًا له، بل أوصى المسؤولين المعنيين بتعطيل session.upload_progress.enabled مؤقتًا على مستوى الخادم وإعادة تشغيل عمليات PHP حتى التحديث الدوري التالي. ولا ينبغي الخلط بين هذه الحالة المحدودة والثغرتين الحرجتين الأصليتين.

هل اخترقت PHP2Shell معظم مواقع الإنترنت؟

تداولت بعض المنشورات أرقامًا ضخمة عن نسبة المواقع التي تعطلت أو تعرضت للاختراق. لكن البلاغات الرسمية المتاحة لا تثبت أن 70% من مواقع العالم قد اختُرقت بسبب PHP2Shell. وأكدت جهات أمنية وجود استغلال ومحاولات هجوم، بينما أوضح المركز الأمني التابع لـ NHS England أنه لم يرصد دليلًا على استغلال جماعي واسع النطاق وقت تقريره.

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

ما الدرس الأهم من ثغرة PHP2Shell؟

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

آخر تحقق للمعلومات: 30 أكتوبر 2026. تتطور التحذيرات الأمنية مع ظهور تفاصيل وتحليلات جديدة؛ لذلك يظل الموقع الرسمي لـ PHP وإشعارات فرق الاستجابة الأمنية ومزود الاستضافة مراجع أساسية قبل اتخاذ إجراء على خادم فعلي.