ثغرتان حرجتان في PHP: كيف تحمي موقعك؟

تحدد نشرات PHP الأمنية الثغرة CVE-2026-109618، المرتبطة بمعالجة نقص الذاكرة، والثغرة CVE-2026-109619، المرتبطة بحالة داخلية تُحتفظ بها بين الطلبات. صُنفت كلتاهما ضمن الثغرات الحرجة، بدرجة 9.2 من 10 وفق CVSS v4. وقد يتيح استغلالهما بنجاح تنفيذ شيفرة على خادم معرض للخطر دون مصادقة.

يشمل الخطر تثبيتات PHP التي تعالج طلبات الويب، ومنها PHP-FPM وApache مع mod_php وCGI وFrankenPHP وLiteSpeed. وتختلف شروط الاستغلال باختلاف البيئة. أشار CERT-FR في 22 أكتوبر إلى وجود نماذج إثبات مفهوم لبعض إعدادات النشر؛ ولا تتيح هذه المعلومة إحصاء المواقع التي تعرضت للاختراق فعليًا.

في 23 أكتوبر 2026، قدّر W3Techs أن PHP تُستخدم في 69.3% من المواقع التي تُعرف لغة البرمجة المستخدمة على خوادمها. لهذا النطاق أهمية: فالنسبة لا تشمل جميع مواقع الويب، ولا تمثل جردًا للتثبيتات التي لا تزال معرضة للخطر.

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

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

قد تنقل توزيعات Linux تصحيحًا إلى إصدار أقدم دون اعتماد رقم الإصدار نفسه. على سبيل المثال، أصلحت Ubuntu الثغرتين في الحزمة 8.3.6-0ubuntu0.24.04.13 لنظام Ubuntu 24.04. اطلب الرقم الكامل للحزمة والنشرة المقابلة من المزود قبل الاستنتاج اعتمادًا على رقم PHP وحده.

لم تعد إصدارات PHP 8.1 والفروع الأقدم تحظى بالدعم العام من مشروع PHP. توجد تصحيحات محددة منقولة إلى إصدارات أقدم، لكنها لا تعيد هذا الدعم: تحقق مما يغطيه مزودك وخطط للانتقال إلى إصدار متوافق. ينتهي دعم PHP 8.2 في 31 ديسمبر 2026.

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

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

يوضح PHP أنه لا توجد إجراءات تخفيف توفر حماية كاملة بديلًا عن التحديث. ويصف CERT-FR حلولًا التفافية مؤقتة لم تُعتمد فعاليتها: بعضها لا يقلّص سوى جزء من سطح الهجوم وقد يعطّل وظائف في الموقع. وقد يسهم جدار حماية تطبيقات الويب في توفير حماية مؤقتة، لكنه لا يحل محل التصحيح.

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

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

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

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

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

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