تبدأ حماية مواقع PHP بمعرفة بيئة التشغيل التي تخدم موقعك، ثم تطبيق التصحيح المناسب والتحقق من الوظائف التي يستخدمها العملاء. اطلب من شركة الاستضافة دليلًا على الحزمة المثبتة والخدمة التي تعمل بها. وحدّد مسؤولًا عن الأنظمة التي تنتظر الإصلاح، بدل الاكتفاء برسالة عامة تقول إن الموقع أصبح محدّثًا دون تفاصيل يمكن مراجعتها.
حتى أكتوبر 2026، وبحسب مراجعتنا في 23 أكتوبر، تتعلق الثغرتان CVE-2026-109618 وCVE-2026-109619 ببيئة PHP نفسها. قد تسمحان بتنفيذ تعليمات برمجية دون تسجيل دخول عند توافر الظروف المناسبة. ترتبط الأولى بالتعامل مع الذاكرة عند نفادها، والثانية ببقاء حالة داخلية تشير إلى ذاكرة انتهى استخدامها. يشرح بيان مؤسسة PHP عن الحادث الآليتين ومسارات الهجوم التي تحقق منها الباحثون.
وجود إصدار متأثر يستدعي المعالجة، لكنه لا يثبت وحده أن شخصًا دخل إلى بياناتك. اطلب من المشغّل تقييم التركيب الفعلي ومدى انكشافه والأدلة المتاحة. افصل قرار التصحيح عن نتيجة التحقيق؛ قد يحتاج الفريق تنفيذ تحديث عاجل بينما يراجع مختص آخر ما حدث قبل التحديث.
ما الإصدارات التي تصلح الثغرتين الأصليتين؟
حدّد تنبيه مشروع PHP الرسمي الإصدارات التالية بوصفها أول إصدارات المشروع التي تتضمن الإصلاح:
| فرع PHP | أول إصدار يتضمن التصحيح | ما يراجعه المسؤول |
|---|---|---|
| 8.5 | 8.5.12 | تثبيت إصدار مصحح يناسب التطبيق |
| 8.4 | 8.4.27 | تثبيت إصدار مصحح يناسب التطبيق |
| 8.3 | 8.3.36 | تثبيت إصدار مصحح يناسب التطبيق |
| 8.2 | 8.2.35 | تطبيق التصحيح ومراجعة خطة الترقية |
هذه أرقام مرجعية للإصلاح، ولا تعني العودة من إصدار أحدث يتضمنه. عند استخدام حزم موزّع نظام التشغيل، اطلب مرجع نشرته ورقم مراجعة الحزمة. خرج PHP 8.1 وما قبله من الصيانة الاعتيادية للمشروع، لكن بعض المورّدين يوفّرون تصحيحات منقولة، كما أتاح فريق PHP تصحيحات مصدرية محدودة للفروع 7.4 و8.0 و8.1. يراجع المختص صلاحية هذا المسار مع وضع خطة انتقال إلى إصدار مدعوم.
ماذا أضاف تنبيه 23 أكتوبر؟
نشر مشروع PHP تنبيهًا إضافيًا عن تتبّع تقدّم رفع الملفات، مرتبطًا بالمعرّف CVE-2026-115560 وتركيب غير شائع يجمع إعدادًا معينًا وسلوكًا داخل التطبيق. يوصي التنبيه بتعطيل هذه الميزة إلى إصدار إصلاح الأخطاء التالي؛ ويمكن للتطبيقات التي لا تغيّر معالج تسلسل الجلسة أثناء التشغيل إبقاؤها مفعّلة. اطلب من المسؤول مراجعة هذا التنبيه المستقل بعد التحديث الأصلي، والإبقاء على الإجراء السابق حيث توصي النشرة بذلك.
ابدأ بقائمة المواقع الفعلية مع مسؤول الاستضافة. اكتب لكل نطاق اسم التطبيق وحساب الاستضافة ومصدر بيئة التشغيل والشخص المسؤول عنها. أضف النطاقات الفرعية ومواقع التجربة المتاحة للإنترنت والتطبيقات القديمة الموجودة في الحساب نفسه. ضع علامة «بانتظار التحقق» أمام أي معلومة ناقصة حتى لا تتحول الافتراضات إلى تقرير إنجاز.
خصّص صفًا لكل تطبيق منشور أو مهمة مستقلة. قد يحتاج موقع الشركة وبوابة الموظفين ومهمة استيراد الطلبات إلى فحوص مختلفة، حتى لو أدارتها جهة واحدة. اسأل هل يعتمد التشغيل على حزم نظام التشغيل، أم إعدادات لوحة الاستضافة، أم صورة حاوية. بعد ذلك اطلب دليلًا يناسب طريقة التثبيت الفعلية، مع تحديد البيئة التي ينطبق عليها.
الإصدار الظاهر في الطرفية معلومة مفيدة ضمن الحصر. اطلب من المسؤول إثبات الإصدار الذي يستقبل طلب الموقع، ومراجعة أي عمليات منفصلة تستخدم تثبيتًا آخر. في الحاويات، دوّن مرجع الصورة المنشورة؛ وفي الخوادم التي تستخدم الحزم، دوّن مراجعة الحزمة. احصل على هذه المعلومات عبر إجراء الصيانة المتفق عليه، وتجنّب نشر صفحة تشخيص تكشف إعدادات الخادم للزوار.
يساعدك دليل اختيار استضافة المواقع السعودية على فصل مسؤولية الخادم عن صيانة التطبيق. استخدم القائمة لتسمية الطرفين وصاحب الصلاحية في الموافقة على توقف الخدمة إذا احتاجت المعالجة ذلك.
اطلب ردًا مكتوبًا يحدد الأنظمة المشمولة والتصحيح ووقت تشغيله. عبارة «حدّثنا الموقع» لا توضّح مصدر الحزمة ولا حالة العمليات العاملة. احتفظ بإجابة المورّد مع سجل النشر حتى يستطيع مسؤول آخر مراجعة العمل دون بدء البحث من جديد أو الاعتماد على ذاكرة من نفّذ المهمة.
يمكنك تكييف الطلب التالي مع موقعك:
نحتاج تأكيد حزمة PHP أو صورة الحاوية التي تخدم كل موقع في القائمة، ومرجع المورّد الذي يثبت الإصلاح، ووقت بدء العمليات الفعلية باستخدامه. أدرجوا المهام الخلفية ونتائج الاختبار والأنظمة المعلّقة. نحتاج أيضًا مراجعة تنبيه PHP الصادر في 23 أكتوبر، مع تحديد الإجراء التالي والمسؤول عن كل استثناء.
أرسل رابط الموقع ورقم حساب الاستضافة عبر قناة الدعم المعتادة. رتّب الوصول الإداري لاحقًا بطريقة آمنة متفق عليها. لا تضع كلمات مرور أو مفاتيح API أو سجلات العملاء في رسالة طلب التقييم الأولى؛ يكفي وصف التركيب والمشكلة والجهات التي تديره.
إذا وزّعت العمل بين شركة استضافة ومطوّر، فاطلب منهما تحديد نقطة التسليم. يقدّم المشغّل دليل بيئة التشغيل، ويختبر المطوّر سلوك التطبيق. يحدد صاحب العمل الوظائف التي يحتاجها العملاء، ويوافق على نافذة الصيانة وطريقة متابعة الحالة. سجّل من يملك القرار إذا اختلف الطرفان حول جاهزية الموقع للعودة.
تحتاج بيئة PHP والتطبيق إلى مسارين منفصلين للتحديث. حتى أكتوبر 2026، توضح نشرة ووردبريس عن ثغرات PHP أن ووردبريس لا يحتاج تحديثًا مخصصًا لهاتين الثغرتين ولا يخطط له. تساعد معلومات صحة الموقع في معرفة إصدار PHP، ثم تؤكد شركة الاستضافة الحزمة التي تعالج المشكلة وبدء استخدامها.
وتطلب نشرة دروبال الخاصة ببيئة PHP من صاحب الموقع تحديث البيئة أو التنسيق مع مضيفه. تابع توافق التطبيق بالتوازي مع تغيير الخادم. اجعل سجل العمل واضحًا بما يكفي للتمييز بين تصحيح PHP وصيانة إضافة أو قالب أو مكتبة بسبب مشكلة أخرى.
في التطبيق القديم المكتوب حسب طلب الشركة، اطلب قرارين: التصحيح المتوافق المتاح الآن، وخطة الانتقال إلى بيئة مدعومة. سجّل أي عائق واسم صاحبه وموعد مراجعته. يشرح دليل استبدال الأنظمة القديمة على مراحل خيارات التحديث طويل الأجل؛ أما الإصلاح العاجل فيحتاج نطاقًا محددًا وشروط قبول يمكن اختبارها قبل إغلاقه.
اتفق على مسار التحديث والاستعادة واختبارات العملاء قبل تغيير الإنتاج. الخطوات التالية خطة عمل مقترحة، ولا تفترض أن باقة استضافة بعينها تشمل جميع بنودها. ناقش ما يمكن تنفيذه الآن وما يحتاج موافقة أو تجهيزًا، ودوّن أثر أي فحص لم يستطع الفريق إكماله.
- حدّد النطاق. اكتب أسماء الخوادم والتطبيقات المعنية، ومصدر الحزمة أو الصورة، والشخص الذي سينفّذ التغيير. اجعل المواقع التي لم يتحقق منها الفريق ظاهرة في القائمة.
- جهّز الاستعادة. حدّد مكان النسخة الاحتياطية وتحقق من صلاحية الوصول إليها. اكتب خطوات الاستعادة، وعيّن مسؤول مراجعة الطلبات أو الرسائل الجديدة التي قد تتأثر بالرجوع إلى نسخة سابقة.
- راجع التوافق. اختبر الوظائف المهمة مع بيئة التشغيل المقترحة في بيئة محمية مناسبة حيثما أمكن. سجّل الاختبارات التي تعذّرت وسبب تعذّرها بدل إدراجها ضمن الفحوص الناجحة.
- اتفق على قرار التوقف. سمّ صاحب الصلاحية في تعليق استقبال الزوار، وحدّد ما سيراه العميل وكيف يتلقى فريق العمل تحديثات الحالة أثناء المعالجة.
- انشر وتحقق. اجمع دليل البيئة العاملة ونتائج الفحوص المتفق عليها، ثم سجّل قرار الاستمرار أو الاحتواء والعمل المتبقي.
راجع التراجع من الناحية الأمنية أيضًا. قد تعيد بيئة قديمة الوظائف إلى العمل مع إعادة التعرض للثغرة. ناقش مع المسؤول هل يناسب الوضع احتواء مؤقت، أم نشر مصحح، أم استعادة داخل بيئة عولجت. وجود ملف نسخة احتياطية لا يغني عن معرفة طريقة استعادته والتحقق من إمكانية استخدامه.
إذا لم يتضح من يتولى الصيانة، فاستعن بأسئلة تحديد نطاق الموقع وتكاليف تشغيله عند كتابة أمر العمل التالي. أبقِ قرار التصحيح العاجل واضحًا، ثم ناقش إعادة التصميم أو توسعة الوظائف في نطاق لاحق حتى لا يتأخر الإصلاح بسبب قرارات لا يحتاجها الآن.
ارفع الحالة إلى المشغّل وصاحب القرار مع وصف ما بقي مكشوفًا. حتى أكتوبر 2026، توصي إرشادات المعالجة من CERT-EU بالتحديث العاجل والنظر في عزل الأنظمة المتاحة للإنترنت إذا تعذّر تطبيق التصحيح فورًا. تعالج الإجراءات المؤقتة مسارات هجوم محددة، ولا تحل محل التحديث.
يقيّم المسؤول الإرشادات الحالية وفق تركيب الموقع. قد تستدعي صفحة الصيانة داخل نظام إدارة المحتوى التطبيق نفسه، لذلك اسأل كيف يمنع الاحتواء المقترح الوصول إلى بيئة التشغيل المتأثرة. دوّن الإجراء المطبق وما بقي من تعرض، ثم اكتب شروط إزالته واسم من يوافق على إعادة فتح الخدمة.
تجنّب نقل قيم إعداد منفردة من منشور اجتماعي. اطلب مراجعة النشرة كاملة وتأثير الإجراء على التوافق وتوافر الخدمة. حدّد موعد التحديث التالي للحالة ووسيلة التصعيد إذا لم ينفّذ الطرف المسؤول ما اتفقتم عليه. يحتاج صاحب الموقع إلى معرفة ما سيحدث لاحقًا ومن سيتابعه، حتى عندما يتعذر تأكيد وقت الإغلاق النهائي.
أغلق التغيير عندما يقدّم الفريق إثبات معالجة البيئة ونتائج اختبار التطبيق، مع إسناد العمل المتبقي إلى أشخاص محددين. الجدول التالي نموذج تسليم مقترح؛ لا يصف نتائج فحص موقع عميل ولا يقرر ما تشمله أي باقة دون اتفاق.
| بند المراجعة | الدليل الذي تحتفظ به | المسؤول |
|---|---|---|
| تصحيح البيئة | مرجع المورّد والحزمة أو الصورة وتأكيد التشغيل الفعلي | مشغّل الاستضافة |
| التنبيه اللاحق | نتيجة مراجعة إرشادات 23 أكتوبر والإجراء المناسب | مسؤول PHP |
| تجهيز الاستعادة | مكان النسخة وصلاحية الوصول وخطوات الاسترجاع | مسؤول البيانات |
| وظائف الموقع | النتيجة المتوقعة والفعلية لكل اختبار | مطوّر التطبيق |
| قرار العودة | وقت التغيير والبنود المعلّقة والموافقة على التشغيل | صاحب القرار |
اختر اختبارات تشبه استخدام العملاء. أرسل نموذجًا بالعربية وتأكد من وصوله إلى البريد المتفق عليه، ثم راجع المسار الإنجليزي المناسب. في المتجر، نفّذ شراءً تجريبيًا مصرحًا به وراجع تسجيل الطلب وتأكيد الدفع والتعامل مع المخزون. استخدم حسابًا عاديًا وحساب مدير عند اختبار وظيفة تعتمد على الصلاحيات.
دوّن وقت الاختبار والدور المستخدم والنتيجة المنتظرة وما حدث. فتح الصفحة الرئيسية لا يثبت نجاح الدفع. اتفق أيضًا على من سيراجع أخطاء التطبيق والمهام الفاشلة بعد النشر وموعد إرسال النتيجة. اترك الوظيفة التي لم تختبرها بحالة معلّقة واضحة حتى يعرف المسؤول التالي أين يبدأ عمله.
احفظ الأدلة وأشرك المختص المسؤول قبل التعامل مع الحالة كصيانة روتينية. تتضمن إرشادات NCSC للاستجابة تقييم مؤشرات الاختراق إذا تعذّر تحديث النظام المتأثر أو إيقافه سريعًا. تثبيت التصحيح وحده لا يثبت سلامة نظام تعرّض لاختراق سابق.
اطلب تقييم الحسابات الإدارية غير المتوقعة والملفات المتغيرة والاتصالات غير المفسرة في سياقها. هذه أمور تستدعي الفحص، ولا تثبت استغلال الثغرتين تحديدًا. احتفظ بالسجلات وسجل التغييرات، ونظّم الوصول إليها، وتجنّب حذف الأدلة فقط لإزالة تنبيه أو إعادة لوحة التحكم إلى مظهرها المعتاد.
اتفق مع مسؤول الحادث على التحقيق وتغيير بيانات الوصول والاستعادة وشروط إعادة التشغيل. افصل هذه القرارات عن تذكرة التحديث المعتادة. تمر أي مراسلات للعملاء أو الجهات المعنية بمراجعة الجهة المخوّلة داخل عملك وفق النتائج الفعلية؛ لا يقدم هذا الدليل استنتاجًا عن حالة موقعك أو بياناته.
ابدأ بمسؤول معروف وسجل تغيير يمكن مراجعته. جهّز رابط موقعك والمنصة وشركة الاستضافة وإصدار PHP إن عرفته، وحدّد الوظائف التجارية التي تحتاج اختبارًا. أخبرنا بوجود اشتباه في اختراق حتى نميّز منذ البداية بين تحديث البيئة والعمل الذي قد يحتاج تحقيقًا مستقلًا.
نساعدك في تكنوستاك على تقييم التركيب والاتفاق على العمل، ثم تطبيق تصحيح متوافق أو التخطيط للترقية اللازمة، والتحقق من بيئة التشغيل واختبار الوظائف المهمة. وتوضح مناقشة استضافة المواقع وصيانتها مسؤوليات الصيانة المرتبطة بباقة الاستضافة. نوثّق التغييرات ونتفق على التقوية والمتابعة التي يحتاجها الموقع بعد المعالجة.
اطلب فحص أمان موقعك وأرسل هذه المعلومات الأولية. نؤكد النطاق والموعد والسعر بعد المراجعة؛ ونحدد التحقيق وتنظيف الشيفرة الضارة والتعديلات الكبيرة والصيانة المستمرة في اتفاق منفصل حيث يلزم.
