ثغرتا PHP2Shell تتطلبان تحديث الخادم لا الموقع فقط

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

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

تحمل الثغرتان المعرّفين CVE-2026-109618 وCVE-2026-109619. والسؤال الذي يهم المؤسس ليس ما إذا كان فريقه يكتب الشيفرة بلغة PHP، بل ما إذا كانت الشركة تعتمد على أي خدمة تعمل بإصدار متأثر منها.

الثغرة في بيئة التشغيل وليست في شيفرة الموقع

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

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

احصر جميع الخدمات التي تستخدم PHP

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

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

أما إذا كنت تشتري خدمة مدارة بالكامل ولا تتحكم في خوادمها، فاسأل المورد مباشرة: هل تأثرت البنية التحتية لديكم، وهل اكتمل التصحيح؟ المطلوب إثبات واضح من الجهة المسؤولة، لا أن تحاول أنت تحديث خوادم لا تملك صلاحية إدارتها.

حدّث PHP وتأكد من أن الإصدار المصحح يعمل فعلاً

الإصدارات التي أصلحت الثغرتين في مشروع PHP هي 8.5.12 و8.4.27 و8.3.36 و8.2.35. أما 8.1 والإصدارات الأقدم فلا تحصل على التحديثات الاعتيادية من مشروع PHP. مع ذلك، قد توفر توزيعات Linux وشركات الدعم الممتد تصحيحات مدمجة في حزم تحمل أرقاماً أقدم. لهذا راجع نشرة مزود النظام أو الاستضافة قبل الحكم على الإصدار من رقمه فقط.

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

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

ماذا يعني ذلك عند بناء منتج أو شراء خدمة؟

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

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

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

ما الذي ينبغي فعله هذا الأسبوع؟

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

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