يجب التعامل مع هذين الرقمين لثغرة PHP2Shell (CVE‑2026‑109618، CVE‑2026‑109619) كحدث طارئ: لا يحتاج المهاجم إلى أي اسم مستخدم أو كلمة مرور، وبمجرد تمكنه من الوصول إلى خدمة مكشوفة على الإنترنت، قد يتمكن من تنفيذ أوامر مباشرة على خادمك. التسلسل الموصى به للمعالجة هو — أولاً تأكد مما إذا كنت ضمن النطاق المتأثر، ثم قرر ما إذا كنت ستطبق التصحيح أم ستستخدم التخفيف المؤقت أولاً، وأخيراً تأكد من التحقق ومراجعة السجلات. فيما يلي تفصيل بالترتيب القابل للتنفيذ.
الخطوة الأولى: تحديد ما إذا كنت متأثرًا فعلاً خلال 30 دقيقة
لا توقف الموقع بالكامل من البداية، بل قم أولاً بثلاثة أشياء لتحديد سطح التعرض.
1. تأكد من الإصدار. سجّل الدخول إلى الخادم ونفّذ `php -v`، وتحقق من علامة صورة الحاوية (container image tag)، و`composer.lock`، وإصدار PHP المحدد في لوحة التحكم. العديد من مواقع الشركات تعمل على إصدارات 7.x القديمة، ويعتقد فريق العمليات أنه تم الترقية، لكن في الواقع هناك بيئة أخرى تعمل.
2. تأكد من سطح التعرض. امسح من منظور خارجي: أي النطاقات/عناوين IP لديها المنافذ 80 و443 و8080 مفتوحة مباشرة على الإنترنت، وما إذا كانت هناك بيئات اختبار أو لوحات تحكم قديمة أو واجهات تم رفعها مؤقتًا ونسي إغلاقها. الوصول من الشبكة الداخلية لا يعني الأمان، فالتحرك الجانبي غالبًا ما يبدأ من هنا.
3. تأكد من مسار التفعيل. راجع المكونات ونقاط الدخول المتأثرة المذكورة في الإعلان الرسمي، وتحقق مما إذا كانت مساراتك وواجهات الرفع ونقاط إدخال إلغاء التسلسل ونقاط عرض القوالب مشمولة. إذا لم تتمكن من التحديد، تعامل معها على أنها "متأثرة"، فالتكلفة أقل.
سجّل النتائج في جدول: النطاق، إصدار PHP، هل هو مكشوف على الإنترنت، هل يحتوي على مكونات متأثرة، المسؤول. سيُستخدم هذا الجدول لاحقًا في التحقق والمراجعة.
الخطوة الثانية: إذا أمكن تطبيق التصحيح فافعله، لا تستبدل الترقية بـ"تعديل الإعدادات"
التصحيح هو وسيلة العلاج الجذري الوحيدة، والتخفيف المؤقت هو فقط لكسب الوقت.
- تحقق أولاً في بيئة ما قبل الإنتاج. الترقية المباشرة في الإنتاج عالية المخاطر، خاصة لمواقع الشركات التي تعمل منذ سنوات، حيث تتشابك الإضافات وإصدارات الأطر. شغّل المسارات الأساسية في بيئة ما قبل الإنتاج: تسجيل الدخول، الطلب/إرسال النماذج، ردود الدفع، رفع الملفات.
- الترقية بترتيب التبعيات. قم بترقية بيئة التشغيل أولاً، ثم الإطار والمكتبات الخارجية، وأخيراً معالجة الاستدعاءات المهملة في كود الأعمال. بعد الترقية نفّذ `composer update` ثم أعد إنشاء ملف القفل وارفعه.
- احتفظ بمسار التراجع. خذ لقطة أو احتفظ بعلامة الصورة القديمة قبل الترقية، واكتب أوامر التراجع بوضوح. الترقية بدون خطة تراجع هي في جوهرها مقامرة.
- تجنب الأخطاء: لا تعلن الانتهاء بعد ترقية جهاز واحد فقط. غالبًا ما توجد خوادم أخرى خلف موازن التحميل لم يتم تحريكها، والمهاجم يستهدف الخادم المنسي.
إذا كانت الأعمال منفذة من قبل جهة خارجية ولم تتمكن من الحصول على الكود المصدري، فاتصل أولاً بالمطور الأصلي لطلب معلومات الإصدار وخطة التصحيح؛ وإذا لم تتمكن، استخدم الحل المؤقت في القسم التالي للصمود أولاً.
الخطوة الثالثة: التخفيف المؤقت عند تعذر التصحيح، حسب الأولوية
إجراءات التخفيف هي "تقليل احتمالية الاستغلال" وليست "تم الإصلاح"، ويجب تدوينها في جدول زمني مع موعد نهائي للترقية.
1. تقليص سطح التعرض: أزل لوحات الإدارة وواجهات التصحيح وبيئات الاختبار من الإنترنت، وحوّلها إلى وصول داخلي أو أضف قائمة IP بيضاء. هذا البند هو الأعلى عائدًا والأقل تكلفة.
2. الاعتراض المسبق: طبّق قواعد اعتراض على مستوى WAF أو Nginx بناءً على الخصائص المذكورة في الإعلان، وقيّد في الوقت نفسه صلاحيات التنفيذ في مجلد الرفع (`php_flag engine off` أو الإعداد المكافئ).
3. التشغيل بصلاحيات منخفضة: لا تستخدم عملية الويب حساب root، وأزل الأجزاء غير الضرورية من صلاحيات الكتابة في مجلدات الملفات، وأغلق الدوال الخطرة الممكنة في `disable_functions`.
4. إضافة المراقبة: أضف تنبيهات للعمليات الفرعية غير الطبيعية والاتصالات الخارجية والملفات القابلة للتنفيذ الجديدة في مجلد الرفع.
تجنب الأخطاء: إضافة قواعد WAF فقط دون تعديل الكود تعني تسليم مصيرك لمكتبة القواعد. قد يتجاوز المهاجم ببساطة بتغيير طريقة الترميز، لذا يجب مراجعة سجلات الاعتراض يوميًا خلال فترة التخفيف.
الخطوة الرابعة: يجب التحقق بعد الإصلاح، وإلا فهو كعدم الإصلاح
كثير من الفرق تنتهي بعد تطبيق التصحيح، لكن العملية القديمة لا تزال تعمل.
- أعد تشغيل PHP-FPM وخدمة الويب، وتأكد من أن `php -v` أصبح الإصدار الجديد على جميع العقد.
- أعد اختبار مسار التفعيل الأصلي بأداة مسح خارجية، وتأكد من أن الاستجابة لم تعد قابلة للاستغلال.
- راجع السجلات: خلال النافذة الزمنية بين الإعلان عن الثغرة والإصلاح، هل كانت هناك طلبات POST غير طبيعية أو عمليات رفع مشبوهة أو اتصالات خارجية غير طبيعية. إذا وجدت، تعامل معها كحدث اختراق وليس مجرد تصحيح.
- تحقق من المهام المجدولة ومفاتيح SSH العامة والحسابات الجديدة، وتأكد من عدم وجود أبواب خلفية.
مثال على سيناريو محدد (مثال): شركة فتحت مؤقتًا واجهة رفع ملفات للمصممين أثناء إعادة تصميم موقعها، ونسيت إغلاقها، فصادف أنها على الإصدار المتأثر. هذه "الواجهات المؤقتة" هي الأكثر عرضة للخطر، ويجب أن تكون هناك "قائمة تنظيف المداخل المؤقتة" عند إنهاء إعادة التصميم.
متى يكون من المناسب اللجوء إلى MIC Studio
إذا كنت في إحدى الحالات التالية، فالتعامل بنفسك ليس مجديًا:
- الكود المصدري لدى جهة خارجية، ومعلومات الإصدار غير واضحة، وخطة التصحيح لا يمكن جدولتها؛
- المواقع كثيرة والبيئات متنوعة، ولا يمكن التمييز بين ما هو على الإنترنت وما هو ضمن النطاق المتأثر؛
- بعد تطبيق التصحيح تريد إجراء جولة أخرى من اختبارات الأمان والاختبار العكسي للتأكد من عدم وجود مداخل متبقية وأبواب خلفية؛
- وتريد في الوقت نفسه إعادة هيكلة النظام القديم، وتوحيد مجموعة تقنيات تطوير المواقع وتطوير البرامج المصغرة أو تطوير التطبيقات على إصدار قابل للصيانة.
تقوم MIC Studio بتطوير مواقع الشركات والبرامج المصغرة والتطبيقات والسكريبتات، كما تقوم باختبارات أمان المواقع والاختبار العكسي، ويمكنها التعاون بترتيب "إيقاف النزيف أولاً، ثم التحقق، ثم إعادة الهيكلة". ليست كل المشاكل تحتاج إلى الاستعانة بجهة خارجية، فإذا كان بإمكانك تطبيق التصحيح بنفسك، فإتمام التصحيح أولاً أكثر أهمية.
الخاتمة: ثلاثة أشياء يمكن القيام بها اليوم
1. أعدّ القائمة اليوم: اكتب جميع بيئات PHP المكشوفة على الإنترنت، مع تحديد الإصدار والمسؤول، ولا تعتمد على الذاكرة.
2. أكمل الترقية أو التخفيف خلال 48 ساعة: إذا أمكن الترقية فافعل، وإذا لم تتمكن فأزل سطح التعرض وأضف الاعتراض، وحدد موعدًا نهائيًا.
3. احتفظ بالأدلة: خذ نسخة احتياطية من السجلات قبل وبعد الترقية، وراجع الطلبات غير الطبيعية خلال النافذة الزمنية بعد الإصلاح، وتأكد من عدم حدوث اختراق.
الأسئلة الشائعة
هل ما زلت بحاجة إلى الإصلاح إذا كنت أستخدمه فقط في الشبكة الداخلية؟
نعم. الشبكة الداخلية ليست حاجزًا عازلًا، فأجهزة الموظفين وأجهزة الاختبار ووصول الجهات الخارجية قد تكون جميعها نقطة انطلاق. أصلح المكشوف على الإنترنت أولاً، وعالج الداخلي في نفس نافذة الصيانة.
هل يمكنني تأجيل الترقية بعد تطبيق قواعد WAF؟
فقط كحل انتقالي. تعتمد القواعد على مطابقة الخصائص، وتكلفة التجاوز ليست عالية، كما أن صيانة القواعد نفسها تحتاج إلى متابعة بشرية. اعتبر WAF كضمادة لإيقاف النزيف، والترقية هي العملية الجراحية، ولا يمكن أن يحل أحدهما محل الآخر.