حذرت تقارير أمنية حديثة من أن مسؤولي الأنظمة الذين يعتمدون على إعدادات مؤقتة لمواجهة ثغرتي PHP2Shell قد يمنحون أنفسهم شعوراً زائفاً بالأمان، إذ تؤكد المعلومات المتاحة أن التحديث الرسمي لـ PHP هو الإجراء الوحيد الذي يمكن اعتباره معالجة فعلية للثغرتين، بينما تقتصر بقية الإجراءات على تقليل المخاطر مؤقتاً فقط.
لا يوجد بديل كامل عن التحديث
وفقاً للتقرير، كانت مؤسسة PHP تستعد لإصدار التصحيح الأمني عند الساعة 14:00 بتوقيت UTC يوم 21 أكتوبر 2026 لمعالجة ثغرتين حرجتين حصلتا على درجة خطورة 9.2 من 10. وحتى لحظة صدور الإصلاح، لم تعلن PHP عن أي وسيلة تخفيف رسمية يمكن اعتبارها بديلاً للتحديث. لذلك فإن أفضل خطوة دفاعية كانت تتمثل في تقليل تعرض خوادم PHP للإنترنت وتجهيز خطط التحديث الفوري بمجرد إتاحة الإصلاح الأمني.
كما أفادت Cloudflare بأنها رصدت محاولات استغلال مبكرة للثغرتين وقامت بنشر قواعد طوارئ في جدار الحماية WAF، لكنها شددت على أن هذه القواعد ليست حلاً نهائياً وإنما إجراء مؤقت لحين تثبيت التحديث الرسمي.
الجدل حول إعداد Session Upload Progress
انتشرت خلال الساعات الأولى بعد الكشف عن الثغرتين توصية تقضي بتعطيل الخاصية:
ويؤدي هذا الإعداد إلى إيقاف ميزة متابعة تقدم رفع الملفات في PHP. وقد اقترحت شركة GMO Flatt Security اليابانية هذا الإجراء في البداية باعتباره قد يساعد على تقليل فرص الاستغلال. إلا أنها عادت لاحقاً وأوضحت أن الإعداد لا يمثل حلاً كاملاً، وأن من المتوقع وجود وسائل لتجاوز تأثيره.
بل إن مطورين مشاركين في مشروع PHP أكدوا أن الاعتماد على إعدادات php.ini ليس كافياً. ونقلت المقالة عن مطوري PHP تأكيدهم أن الترقية والتحديث هما الوسيلة الحقيقية الوحيدة للمعالجة.
لماذا لا يمكن الوثوق بهذا الإعداد؟
توضح المقالة سببين رئيسيين:
- لم تؤكد PHP رسمياً أن أصل المشكلة مرتبط بميزة Session Upload Progress.
- حتى الجهات التي اقترحت الإعداد أقرت بإمكانية تجاوزه وعدم فعاليته ضد جميع سيناريوهات الاستغلال.
كما أشار تحليل مستقل إلى أن بعض الفرضيات المتداولة حول مكان وجود الخلل داخل الشفرة المصدرية لم يتم إثباتها بشكل قاطع بعد. لذلك فإن أي إجراء مبني على هذه الفرضيات يجب اعتباره إجراءً احترازياً وليس دفاعاً مضموناً.
ماذا تفعل إذا لم تتمكن من التحديث فوراً؟
قدمت جهات أمنية متعددة مجموعة من التدابير التي تساعد على تقليل المخاطر إلى حين تثبيت الإصلاح الرسمي، ومنها:
- عزل التطبيقات المكشوفة للإنترنت قدر الإمكان.
- وضع المواقع خلف VPN أو قوائم سماح (Allow Lists).
- تقييد الوصول إلى الخوادم من خلال طبقات مصادقة إضافية.
- تقليل الصلاحيات الممنوحة للخادم.
- إزالة بيانات الاعتماد المخزنة غير الضرورية.
- الاحتفاظ بالسجلات الأمنية في موقع منفصل وآمن لتسهيل التحقيقات لاحقاً.
كما أوصت CERT-EU بدراسة إمكانية عزل التطبيقات المواجهة للإنترنت مؤقتاً حتى يتم تثبيت الإصلاحات الأمنية اللازمة.
الحماية عبر حظر multipart/form-data
أشار بعض الباحثين إلى وسيلة أقوى نسبياً من إعداد Session Upload Progress، وهي منع الطلبات التي تستخدم:
على مستوى خادم الويب قبل وصولها إلى PHP. وتستند هذه الفكرة إلى اعتقاد بأن مسار الاستغلال يرتبط بطريقة معالجة PHP لهذا النوع من الطلبات. ومع ذلك تؤكد المقالة أن هذا الحل أيضاً غير مضمون لأنه يستهدف مساراً مفترضاً للاستغلال وليس المسار المؤكد رسمياً. كما أن تطبيقه قد يؤدي إلى تعطل عمليات رفع الملفات وبعض النماذج الإلكترونية.
أصحاب الإصدارات غير المدعومة في موقف أكثر خطورة
أكد التقرير أن فروع PHP الأقدم من 8.2، مثل 8.1 و7.x و5.x، وصلت إلى نهاية دورة حياتها ولن تتلقى إصلاحات مباشرة من المشروع. ولذلك فإن المؤسسات التي ما زالت تعتمد هذه الإصدارات مطالبة إما بالترقية إلى إصدار مدعوم، أو بعزل الأنظمة المتأثرة، أو بإيقافها مؤقتاً إذا تعذر تأمينها بشكل كافٍ.
الدرس الأهم للمؤسسات
تكشف أزمة PHP2Shell عن حقيقة متكررة في إدارة الثغرات الحرجة: الإجراءات المؤقتة مثل تغيير الإعدادات أو الاعتماد على قواعد WAF قد تقلل فرص النجاح للمهاجم، لكنها لا توفر ضماناً حقيقياً للحماية. وفي مثل هذه الحالات يبقى التصحيح الرسمي من الجهة المطورة هو خط الدفاع الأساسي، بينما تُستخدم الإجراءات الأخرى فقط لشراء الوقت حتى يصبح التحديث ممكناً.
