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

وشمل العمل تحليل 73,306 ملفات، ومطابقة آلاف ملفات WordPress الأساسية بالقوائم الرسمية لإصداراتها، ومراجعة سجلات الويب وصلاحيات الملفات. وأكد الفحص تطبيق التحديثات الأمنية اللازمة لمعالجة الثغرتين في بيئة التشغيل التي خضعت للمراجعة.

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

ما خطورة ثغرتَي PHP؟

تتعلق التحذيرات بالثغرتين CVE-2026-109618 وCVE-2026-109619، المعروفتين باسم PHP2Shell، واللتين صدرت لمعالجتهما تحديثات أمنية في 21 أكتوبر 2026.

وبحسب البيان الأوروبي المشترك، قد تتيح الثغرتان تنفيذ تعليمات برمجية عن بُعد في البيئات المعرضة للاستغلال. وتبلغ درجة خطورتهما المعلنة 9.2 من 10 وفق معيار CVSS v4.0، بحسب مؤسسة PHP.

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

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

التحقق من التحديث: ما وراء الرقم الظاهر في لوحة الاستضافة

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

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

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

مراجعة الصلاحيات وتصحيح إعدادات 385 ملفًا

كشف جرد الملفات وجود 385 ملفًا تسمح صلاحياتها بالكتابة لفئة «الآخرين». وأزال الفريق صلاحيات الكتابة غير المطلوبة، بعد حفظ بيانات الملكية والصلاحيات وقوائم التحكم بالوصول.

وأظهرت المراجعة النهائية عدم بقاء ملفات عادية بهذه الصلاحية ضمن المسارات المشمولة بالفحص.

وللتأكد من أن تعديل الصلاحيات لم يمس محتوى الملفات، قارن الفريق بصمات SHA-256 للملفات الـ382 التي عولجت في الدفعة الثانية، وتحقق من تطابق محتواها قبل المعالجة وبعدها. أما ملفات الإعدادات الثلاثة التي عولجت في الدفعة الأولى، فتأكد من صلاحياتها واستمرار إمكانية قراءتها باستخدام حسابات تشغيلها.

وهذه الملاحظة تتعلق بإعدادات الملفات، ولا تثبت استغلال ثغرتَي PHP. كما أن صلاحية الكتابة لفئة «الآخرين» لا تعني أن أي زائر يستطيع تعديل الملفات عبر الإنترنت؛ إذ يتوقف الوصول الفعلي أيضًا على صلاحيات المجلدات وعزل الحسابات وآليات الحماية.

تحليل أكثر من 73 ألف ملف بحثًا عن برمجيات خبيثة

استخدم الفريق محرك AI-Bolit لتحليل 73,306 ملفات مختارة من مسارات المواقع الموجودة على الخادم المفحوص. ولم تسجل عدادات الكشف ملفات خبيثة ضمن التحليل المنفذ.

وأُجري الفحص لإعداد تقرير، دون تشغيل التنظيف التلقائي أو تفعيل المساعدة السحابية للمحرك، بما يسمح بتقييم النتائج قبل اتخاذ إجراءات على الملفات.

وسجل التقرير الأول 49 خطأ تحليل مرتبطة بحدود معالجة التعبيرات النمطية داخل الأداة. وتعامل الفريق معها باعتبارها أجزاء لم يكتمل تحليلها، فأعاد فحص الملفات المتأثرة بدل الاكتفاء بنتيجة الكشف الأولية.

إعادة الفحص تحدد الملفات التي تحتاج إلى متابعة

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

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

ولم يسجل المحرك إصابات في هذه الملفات الخمسة، لكن استمرار أخطاء التحليل لا يسمح باعتبار مراجعتها مكتملة أو إصدار حكم نهائي على سلامتها.

مطابقة أكثر من 20 ألف ملف WordPress بالنسخ الرسمية

لدعم نتائج التحليل، أجرى الفريق مقارنة لبصمات 20,197 ملف WordPress أساسيًا، موزعة على ستة تثبيتات، بالقوائم الرسمية للإصدارات المستخدمة.

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

وتخص هذه النتيجة ملفات WordPress الأساسية، ولا تشمل القوالب والإضافات أو قواعد البيانات، التي تتطلب مراجعات منفصلة.

ماذا أظهرت مراجعة سجلات الويب؟

شمل البحث 33 سجل ويب حاليًا و57 سجلًا مؤرشفًا، للتحقق من وجود طلبات إلى ملفات PHP وما يماثلها داخل مجلدات uploads.

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

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

كيف تُقرأ نتائج هذا الفحص؟

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

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

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

كيف تعمل الثغرتان؟

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

أما الثانية، فتتعلق ببقاء مراجع داخلية إلى ذاكرة سبق تحريرها، ثم استخدامها بصورة غير سليمة. وقد تسمح هذه الحالات بتنفيذ شيفرة عن بُعد عند توافر شروط الاستغلال، وفق النشرة الفنية لـAmazon Linux.

ما إصدارات PHP المصححة؟

وفق التنبيه الرسمي لفريق PHP، تشمل الإصدارات المصححة المعلنة:

فرع PHP	الإصدار المصحح
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

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

ويشمل التنبيه بيئات تستقبل طلبات الويب، منها PHP-FPM وApache مع mod_php وphp-cgi وFrankenPHP وLiteSpeed. ويجب أيضًا التحقق من الحاويات بصورة مستقلة؛ فتحديث النظام المضيف لا يحدّث نسخة PHP الموجودة داخلها تلقائيًا.

ما دور الذكاء الاصطناعي في الاكتشاف؟

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

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

كيف يتحقق صاحب الموقع من الحماية؟

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

أما مسؤول الخادم، فعليه التحقق من استخدام العمليات العاملة للنسخة المصححة، وإعادة تشغيل الخدمات عند الحاجة بصورة مخططة، ثم اختبار المواقع. وتُستكمل المراجعة بفحص الملفات والصلاحيات ومقارنتها بمصادر موثوقة، وتحليل السجلات والمهام المجدولة، مع حفظ الأدلة قبل المعالجة.

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

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

كذلك لا يثبت ظهور صفحة صيانة أو استجابة 403 وقوع اختراق؛ فقد يكون السبب إجراءً احترازيًا أو حظرًا من طبقة الحماية، ويتطلب تحديده مراجعة السجلات وترويسات الاستجابة.