ثغرة PHP2Shell وانتهاء دعم PHP 8.2: خطة ترقيع وترقية لمواقع وأنظمة الشركات المصرية قبل 31 ديسمبر 2026

الخلاصة السريعة: في 21 أكتوبر 2026 أصدر مشروع PHP الإصدارات 8.5.12 و8.4.27 و8.3.36 و8.2.35 لإصلاح ثغرتين حرجتين (CVE-2026-109618 وCVE-2026-109619) بدرجة 9.2 من 10 وفق CVSS v4.0، تسمحان لمهاجم غير مصادَق بتنفيذ أوامر على الخادم، وتُعرفان إعلاميًا باسم PHP2Shell. الحل الكامل الوحيد هو التحديث فورًا. وبعد ذلك يأتي موعد ثانٍ لا يقل أهمية: ينتهي الدعم الأمني لفرع PHP 8.2 في 31 ديسمبر 2026، فلن تصله أي إصلاحات بعدها، حتى للثغرات الحرجة.

تُعد ثغرة PHP2Shell من أخطر ما أصاب لغة PHP منذ سنوات، لأنها تمس إدارة الذاكرة ومعالجة الأخطاء، وهما جزءان يمر بهما كل طلب تقريبًا. وتعتمد على PHP نسبة كبيرة من مواقع الشركات والمتاجر وأنظمة العيادات والمحاسبة في مصر، سواء على استضافة مشتركة أو خوادم VPS أو خوادم داخلية. في هذا الدليل نشرح ما حدث بالمصادر الرسمية، ونحدد من المتأثر، ثم نقدم خطة سمارت ون جروب على ثلاث مراحل: ترقيع خلال 72 ساعة، ثم مراجعة خلال 30 يومًا، ثم ترقية قبل نهاية دعم PHP 8.2.

ما هي ثغرة PHP2Shell ولماذا تهم المواقع المصرية؟

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

• CVE-2026-109618 (تلف الذاكرة عند نفادها): قد يُقاطَع PHP عند بلوغ حد الذاكرة بينما بيانات الطلب الداخلية مهيأة جزئيًا، ثم تتعامل عملية التنظيف مع هذه البيانات غير الصالحة كأنها صالحة.
• CVE-2026-109619 (حالة عامة متبقية): قد تبقى حالة داخلية تخص طلبًا سابقًا بعد تحرير ذاكرتها، فيستخدمها طلب لاحق يعالجه العامل (worker) نفسه قبل إعادة التهيئة.

وتوضح مؤسسة PHP أن تنفيذ التعليمات عن بُعد أُثبت على Apache مع mod_php بالإعدادات الافتراضية بطلب واحد غير مصادَق قبل تشغيل أي كود للتطبيق، كما تأكد على PHP-FPM عبر مسارات داخل التطبيق. ويرى فريق PHP أن mod_php هو الإعداد الأعلى خطورة.

لماذا الأمر عاجل؟ ذكرت نشرة CERT-EU أن نماذج إثبات مفهوم (PoC) بدأت في الانتشار، ونصحت بعزل التطبيقات المكشوفة للإنترنت إذا تعذر الترقيع. كما أشارت وكالة الأمن السيبراني في سنغافورة في 21 أكتوبر 2026 إلى تقارير عن محاولات استغلال واسعة. وقد سُرّبت معرّفات الثغرتين على الإنترنت يوم 20 أكتوبر 2026، فقدّم المشروع موعد الإصدار يومًا كاملًا.

من المتأثر؟ الإصدارات المصححة ومواعيد الدعم

الجدول التالي يجمع الإصدار المصحح لكل فرع مدعوم ومواعيد الدعم كما يعرضها موقع PHP الرسمي:

أي إصدار أقدم من الأرقام المذكورة في العمود الثاني يُعد متأثرًا. أما الفروع 8.1 وما قبلها فلا يصدر لها المشروع تحديثات، وإن كان فريق الأمن قد نشر استثنائيًا ترقيعات مصدرية مختصرة للفروع 7.4 و8.0 و8.1 لمن يبني PHP من المصدر، وقد توفر بعض التوزيعات وموردي الدعم طويل الأمد إصلاحات منقولة.

لماذا يصبح 31 ديسمبر 2026 موعدًا نهائيًا ثانيًا؟

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

وقد جاء إعلان PHP 8.2.35 نفسه بتذكير صريح بأن الفرع يصل إلى نهاية عمره في 31 ديسمبر 2026. معنى ذلك عمليًا: الموقع الذي يُرقَّع اليوم إلى 8.2.35 محمي من PHP2Shell، لكنه سيبقى بلا حماية من أي ثغرة تُكتشف بعد نهاية العام. لذلك نوصي بأن يكون الترقيع العاجل خطوة أولى، وأن تكون الترقية إلى 8.4 (المدعوم أمنيًا حتى 31 ديسمبر 2028) أو 8.3 كحد أدنى هي الخطوة الثانية.

خطة سمارت ون جروب على ثلاث مراحل

هذه خطة عملية وضعها فريقنا لمواقع وأنظمة الشركات والعيادات في مصر، ويمكن تطبيقها على الاستضافة المشتركة والخوادم الخاصة معًا.

المرحلة الأولى: أول 72 ساعة (الترقيع)

1. الحصر: اكتب قائمة بكل موقع ونظام ولوحة تحكم تعمل بـ PHP، بما فيها بيئات الاختبار والأنظمة القديمة المنسية والأجهزة والبرامج الجاهزة التي تتضمن PHP داخليًا.
2. معرفة الإصدار: من لوحة الاستضافة أو بالأمر php -v على الخادم، مع التأكد من إصدار PHP الذي يخدم الويب فعليًا، لأنه قد يختلف عن إصدار سطر الأوامر.
3. الأولوية للمكشوف: ابدأ بالمواقع العامة ونماذج الرفع وبوابات المرضى والعملاء، ثم الأنظمة الداخلية.
4. التحديث من مصدر موثوق: استخدم حزم التوزيعة الرسمية؛ فقد حذر مشروع PHP من أن مستودع rpms.remirepo.net التطوعي لن يحمل التحديث يوم الإصدار.
5. إعادة تشغيل كل العمال: أعد تشغيل PHP-FPM أو Apache حتى يعمل الإصدار الجديد فعلًا، ثم تحقق من الرقم مرة أخرى.

المرحلة الثانية: خلال 30 يومًا (التحقق والتقوية)

• راجع سجلات الخادم بحثًا عن أخطاء قاتلة متكررة أو رسائل Maximum execution time exceeded أو طلبات رفع غير معتادة.
• افحص المواقع المكشوفة بحثًا عن ملفات أو حسابات غريبة إذا ظلت دون ترقيع بعد انتشار نماذج الاستغلال.
• عطّل خاصية session.upload_progress إذا لم يكن موقعك يحتاجها، وهو ما يعدّه فريق PHP إجراءً حكيمًا حتى بعد الترقيع.
• تأكد من وجود نسخة احتياطية حديثة ومختبرة خارج الخادم نفسه.

المرحلة الثالثة: قبل 31 ديسمبر 2026 (الترقية)

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

إجراءات مؤقتة إذا تعذر التحديث فورًا

يؤكد مشروع PHP أن هذه الإجراءات تقلل التعرض لمسارات هجوم محددة لكنها لا تجعل التثبيت آمنًا، والتحديث وحده هو الحل الكامل:

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

ماذا تفعل حسب نوع استضافتك؟

وإذا كانت لديك خوادم Windows قديمة تستضيف تطبيقات PHP، فراجع أيضًا دليلنا عن انتهاء دعم Windows Server 2016، لأن نظام تشغيل غير مدعوم يُضعف أي ترقيع على مستوى التطبيق. وعند اختيار جهة خارجية للفحص الأمني، يفيدك دليلنا عن سجل مقدمي خدمات الأمن السيبراني لدى الجهاز القومي لتنظيم الاتصالات.

الأسئلة الشائعة

هل موقعي على ووردبريس متأثر بثغرة PHP2Shell؟

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

ما الإصدار الآمن من PHP بعد 21 أكتوبر 2026؟

الحد الأدنى هو 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35 حسب الفرع. وللتخطيط الأطول نوصي بفرع 8.4 المدعوم أمنيًا حتى 31 ديسمبر 2028.

ماذا يحدث لـ PHP 8.2 بعد 31 ديسمبر 2026؟

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

أنا على استضافة مشتركة، هل عليّ فعل شيء؟

نعم. تحقق من إصدار PHP في لوحة التحكم، واسأل مزود الاستضافة كتابةً هل طُبق التحديث، واختر فرعًا مدعومًا. قد لا تملك صلاحية تحديث الخادم، لكنك تملك حق السؤال والتوثيق.

هل تكفي الإجراءات المؤقتة بدل التحديث؟

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

كيف أعرف إن كان موقعي قد اختُرق قبل الترقيع؟

راجع سجلات الخادم وملفات الموقع المعدلة حديثًا والحسابات الإدارية الجديدة والمهام المجدولة. إذا ظهرت مؤشرات مريبة، افصل الموقع واستعن بجهة متخصصة في الاستجابة للحوادث قبل إعادته للعمل.

كيف تساعدك سمارت ون جروب؟

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