PHP2Shell: ثغرتان خطيرتان في PHP وكيف تتصرف
أصلح PHP الثغرتين CVE-2026-109618 وCVE-2026-109619 في21أكتوبر. تحقق من الحزم والاستضافة والعمليات التي تخدم موقعك فعليا.

ما الذي نشر ولماذا يلزم التحرك
المعلومات محدثة في22أكتوبر2026. أصدر PHP في21أكتوبر تحديثات للثغرتين CVE-2026-109618 وCVE-2026-109619، المعروفتين باسم PHP2Shell. المشكلة في محرك معالجة طلبات الويب، لا مجرد إضافة لنظام محتوى. قد يسمح الاستغلال بتنفيذ كود دون مصادقة على خادم متأثر. يستلزم ذلك سرعة التصرف، لكنه لا يثبت أن موقعا بعينه اخترق بالفعل.
يشمل التنبيه PHP-FPM وApache معmod_php وphp-cgi وFrankenPHP وLiteSpeed. يعتبر PHP خطرmod_php الأعلى ويوثق استغلالا مثبتا قبل كود التطبيق. صغر الموقع أو غياب الدخول أو تحديث الإضافات لا يكفي. حدد PHP الذي يخدم الطلبات فعليا وتصحيحه المناسب. يعتمد التعرض على الإصدار والمزود والإعداد؛ لا يشخص هذا المقال حالة خادم محدد ولا يمنحه شهادة أمان.
الثغرتان والإصدارات المصححة
تتصل CVE-2026-109618 بفساد الذاكرة عند معالجة نفادها. وتتصل CVE-2026-109619 ببقاء حالة داخلية بعد تحرير ذاكرتها ثم استخدامها بطلب لاحق في العامل نفسه. تشرح PHP Foundation السببين والتصحيح. يمنع التمييز اختزال الحادثة إلى إعداد سحري واحد. لا تحتاج إعادة هجوم لتقرر التحديث؛ لا نقدم اختبارات استغلال لخدمات عامة أو أوامر تتعمد إسقاطها.
إصدارات21أكتوبر المصححة هي8.5.12 و8.4.27 و8.3.36 و8.2.35. راجع التنبيه الحالي قبل العمل لاحتمال مراجعات لاحقة. قد تعيد التوزيعة نقل التصحيح إلى رقم أساسي مختلف؛ تسرد Ubuntu الحزم فيUSN-8948-1. تحقق من الحزمة وتنبيه المزود، لا سلسلة المفسر وحدها. انتهى دعم مشروع PHP للإصدار8.1 وما قبله، ولا يعيد إصلاح الموزع الدعم الرسمي إليه تلقائيا.
CVE-2026-109618 / CVE-2026-109619
PHP 8.2.35 | 8.3.36 | 8.4.27 | 8.5.12ما الذي تطلبه من الاستضافة ويتحقق منه المسؤول
للاستضافة المدارة اطلب تأكيد الثغرتين والحزمة المثبتة والخدمة المعنية واستخدام العمليات النشطة للتصحيح. شمل النطاقات والمجمعات والحاويات والمنتجات المضمنةPHP، لا الطرفية الرئيسية وحدها. إصدار سطر الأوامر ليس بالضرورة إصدار الموقع. إن تدير النظام، استخدم قناة المزود أو التوزيعة الموثقة مع وصول استرداد ونسخة مناسبة قبل التغيير. تجنب التصحيحات المزعومة في رسائل ومستودعات غير موثوقة.
جدد العمليات وفق المزود وتحقق من الحزمة أو الإصدار الجاري. اختبر الوظائف الأساسية وسجل وقت التصحيح. تحديثCMS أو مسح الذاكرة المخبأة لا يستبدل إصلاح وقت التشغيل. عند دلائل اختراق احفظ الأدلة وابدأ الاستجابة للحوادث: لا يلغي التصحيح تغييرات مهاجم سابقة. هذه فحوص إغلاق تشغيلية وليست تشخيصا عن بعد. عودة الصفحة الرئيسية لا تغني عن التأكيد التقني والتحقق الوظيفي.
إن تعذر التحديث الفوري وحدود WikiURL
يؤكد PHP أن التحديث وحده الحل الكامل. تقلل إجراءات مؤقتة مسارات معينة لكنها لا تجعل التثبيت آمنا. لا تنسخ إعدادات ذاكرة أو جلسات دون فهم الآثار. توصي ENISA بأولوية الأنظمة المكشوفة والنظر في عزلها عن الشبكات العامة عند تعذر الإصلاح. نسق إدارة آمنة وإبلاغ الانقطاع مع المسؤول. قاعدةWAF أو تطبيق يعمل ليست بديلا أو ضمان حماية شاملة.
يساعد WikiURL في استجابةHTTP والوجهة العامة بعد الصيانة، لا كشف إصدارPHP الحقيقي أو إثبات تصحيح الثغرتين.200 وقفلHTTPS ليسا تقييما للثغرات. لا ترسل أسرارا ولا تنشرphpinfo للإثبات. احتفظ بتأكيد المزود وفحص العمليات واختبارات الخدمة منفصلة. المطلوب تحديث عاجل ونتيجة متحققة، لا ادعاء اختراق بلا دليل أو اطمئنان لصفحة تفتح فقط. ولا يقرر المقال أن WikiURL أو أي تثبيت محدد أصبح مصححا.