يكتمل تحديث PHP على DigitalOcean عندما تعمل البيئة المصحّحة في التطبيق المقصود وتُختبر وظائفه المهمة. ابدأ بحصر مواضع PHP، وحدّد من يتحكم في كل حزمة أو صورة حاوية، ثم وثّق نتيجة النشر الفعلي. نجاح بناء صورة جديدة أو ظهور إصدار في لوحة واحدة لا يكفي لإغلاق العمل على بقية الأنظمة.
يساعدك هذا الدليل على تحويل تنبيه الاستضافة إلى سجل حصر وقبول يمكن تسليمه للفريق. الأمثلة فحوص مقترحة يكيّفها المشغّل مع تركيبك، وليست نتائج عن حسابك أو ادعاء باختراقه. احتفظ هنا بأدلة البنية والنشر، واستخدم أدلة المنصات المرتبطة لاختبارات التطبيق نفسه، مع مسؤول واضح لكل جزء.
حتى 23 أكتوبر 2026، يخص الحادث الأصلي الثغرتين CVE-2026-109618 وCVE-2026-109619. يضم مرجع حادث PHP وإصدارات التصحيح جدول الإصدارات الأولى المصحّحة وتوضيحات تصحيحات المورّدين. اختر المعالجة المتوافقة وفق نشرة PHP والدليل الحالي لمصدر الحزمة المستخدمة، ولا تفترض أن رقمًا ظاهرًا وحده يحسم حالة كل تركيب.
يحدّد تنبيه DigitalOcean العام للحادث أحمالًا تستحق المراجعة، منها PHP المثبّت على Droplets والحاويات التي تتضمنه، ويميّز مسار App Platform عن الصور الخاصة. التنبيه سبب لفحص النشر؛ لا يثبت أن حسابًا بعينه تعرّض للاستغلال، ولا أن جهة ما أتمّت معالجته بالفعل.
راجع مع المطوّر تنبيه PHP الإضافي في 23 أكتوبر، المرتبط بـCVE-2026-115560. يتطلب انطباقه اجتماع إعداد غير معتاد مع سلوك في التطبيق. وثّق هذا التقييم مستقلًا عن التصحيح الأول، دون افتراض انطباقه على جميع التطبيقات أو اعتبار تحديث سابق إغلاقًا تلقائيًا لكل تنبيه لاحق.
احصر المشاريع والبيئات والشخص القادر على تغيير كل نشر. ابدأ بالموقع العام، ثم أضف أدوات الإدارة والنطاقات القديمة والبيئات التجريبية المتاحة من الإنترنت وخدمات الاستيراد والمهام المجدولة. اسأل الفريق عما يستقبل طلبات أو يعالج بيانات فعلًا، حتى لو لم يظهر ضمن مسار نشر الموقع الرئيسي أو لم يعد يستخدمه الموظفون بصورة يومية.
خصّص صفًا لكل تطبيق يُنشر بصورة مستقلة. قد يستضيف خادم واحد مواقع بترتيبات PHP مختلفة، وقد يعتمد تطبيق واحد على عدة عمليات أو حاويات. سجّل هذه العلاقات دون نسخ كلمات المرور أو سجلات العملاء إلى جدول الحصر، واربط كل صف بجهة يمكنها تقديم الدليل المطلوب ومراجعة النتيجة.
| ما الذي تفحصه؟ | دليل تخطّط لجمعه | المسؤول المطلوب |
|---|---|---|
| PHP مثبّت على Droplet | مراجعة حزمة المورّد والخدمة الفعلية | مشغّل الخادم |
| حاوية خاصة | البناء المصحّح ومرجع الصورة المنشورة | مسؤول الصورة والنشر |
| تطبيق على DOKS | اكتمال النشر وصور الأحمال العاملة | مشغّل تطبيق العنقود |
| مكوّن App Platform | طريقة البناء والنشر المكتمل | مشغّل التطبيق |
| تركيب سابق من Marketplace | بيئة التشغيل المثبّتة حاليًا | مسؤول صيانة التركيب |
| صورة أو نسخة للتعافي | فحص PHP قبل استخدام المستعاد | مسؤول الاستعادة |
ضع حالة «غير معروف» عند غياب الوصول أو الدليل، ولا تستنتجها من خادم مجاور. اتفق على من سيزيل هذا الغموض وما الصلاحيات التي يحتاجها، وراجع مع المشغّل ضرورة بقاء المكوّن متاحًا للجمهور أثناء التقييم. يجب أن يظهر العمل المعلّق بوضوح في السجل بدل اختفائه تحت حالة الموقع الرئيسي.
يفصل نموذج مسؤوليات Droplets بين ما يديره المزوّد وما يقع على العميل. سمّ الشخص أو الفريق المتعاقد المسؤول عن نظام التشغيل الضيف والبرامج المثبّتة. شراء مورد سحابي وتعيين جهة لصيانة التطبيق قراران تشغيليان يحتاجان وضوحًا، خصوصًا عندما تتوزع الصلاحيات بين شركة الاستضافة والمطوّر وصاحب الموقع.
اطلب تحديد إصدار التوزيعة ومصدر الحزم ورقم مراجعة الحزمة ونشرة الأمان المناسبة. مثلًا، تعرض نشرة Ubuntu رقم USN-8948-1 حزمًا مصحّحة بحسب الإصدار. استخدمها دليلًا للحزم المدرجة فيها، دون نقل أرقامها إلى توزيعة أخرى أو تركيب بُني من المصدر، ودون تنفيذ أمر عام قبل فهم طريقة تثبيت PHP لديك.
اتفق على خطوات التحديث وتفعيل الخدمة وفق الإعداد الحقيقي. دوّن خدمة الويب ومجموعات عمليات PHP والمهام الخلفية التي تستخدم البيئة المصحّحة. إذا وجدت عدة تثبيتات، ميّز بين برنامج الطرفية والبيئة التي تخدم الطلبات؛ اطلب شرح العلاقة بين سجل الحزمة والخدمة الفعلية، بدل الاكتفاء بلقطة منفصلة لا تحدد التطبيق المقصود.
احفظ الدليل في قناة خاصة وبالقدر اللازم للتسليم. لا تنشر صفحة معلومات خادم لإثبات الإصدار. ينبغي أن يوضح السجل التطبيق ومصدر التصحيح ووقت التفعيل والمراجع، مع إزالة الأسرار والتفاصيل غير الضرورية من الصور والسجلات قبل مشاركتها بين الأطراف المعنية.
افصل بين بناء الصورة وحفظها ونشرها. حدّد كيف دخل PHP إلى الصورة: من صورتها الأساسية، أو خطوة تثبيت، أو مكوّن مضمّن. يختار مسؤول الصورة المصدر المصحّح المناسب ويعيد البناء عبر المسار المتفق عليه، ثم يسجّل مرجع الناتج حتى يستطيع مشغّل النشر معرفة ما اعتمده الفريق تحديدًا ومقارنته بما يعمل لاحقًا.
يوضح دليل نقل الصورة إلى عنقود DigitalOcean العلاقة بين البناء والسجل وتطبيق Kubernetes. استخدم إعدادات النشر وصلاحيات بيئتك الفعلية عند تنفيذ التغيير. رفع الصورة إلى السجل مرحلة في الطريق، لذلك اطلب أيضًا دليل المكوّن الذي استهلكها، ولا تعتبر وجود الملف الجديد في السجل إثباتًا لاستبدال التطبيق.
يشرح توثيق Kubernetes حالة النشر عبر Deployments. يراجع المشغّل الصورة المطلوبة واكتمال الاستبدال والأحمال التي لا تزال تستقبل الطلبات. احصر المهام والعمال وأنواع المتحكمات الأخرى بصورة مستقلة عندما يستخدمها التطبيق؛ فحص Deployment واحد لا يغطي العنقود كله ولا يثبت حالة كل عملية خلفية فيه.
اتفق قبل الاستبدال على التعامل مع النسخ القديمة والعمل الجاري: هل تنهي المهمة دورها، أم يمكن إعادة المحاولة، أم تحتاج تسوية يدوية؟ سجّل النتيجة التي شاهدها التطبيق وعيّن مسؤولًا للمهام غير المكتملة. لا تستنتج وعدًا باستمرار الخدمة من اسم طريقة النشر وحده؛ يعتمد القرار على التركيب والاختبارات وحدود الصيانة المتفق عليها.
حدّد إن كان المكوّن يُبنى من المصدر باستخدام buildpack، أو يعتمد Dockerfile، أو يسحب صورة جاهزة. يذكر تنبيه DigitalOcean تصحيح buildpack الخاص بـPHP ويطلب إعادة نشر التطبيقات؛ أما الصور الخاصة فتحتاج تصحيح PHP داخلها وإعادة نشرها. راجع المسار المستخدم في مكوّنك قبل تعميم حالة أحد المنتجات على إعداد آخر.
في البناء من المصدر، راجع توثيق إعادة التشغيل وإعادة البناء. إعادة تشغيل حاوية قائمة وإنتاج بناء جديد عمليتان مختلفتان. يختار المشغّل الإجراء الذي يتضمن تغيير البيئة المطلوب، ثم يراجع ناتج البناء ويسجل النشر الناتج، بدل الاعتماد على أن التطبيق عاد للعمل بعد إجراء لا يغيّر صورته أصلًا.
وللصور الجاهزة، يوضح توثيق نشر الحاويات المراجع والوسوم وملخصات الصور وسلوك النشر. احتفظ بمرجع الصورة الذي اختاره النشر وقارنه بالبناء المعتمد. لا تفترض أن دفع صورة إلى أي سجل يستبدل التطبيق تلقائيًا؛ افحص إعداد التشغيل الفعلي وما يتطلبه من إجراء حتى تصل الصورة إلى الخدمة.
استعن بـعرض إدارة عمليات النشر لربط التغيير بعملية محددة وسجلاتها. دوّن مكوّنات الخدمة والعمال المعنية، ومن راجع بدءها، والاختبار الذي تلا ذلك. تحتاج حالة النشر الناجحة إلى قبول وظائف التطبيق المتفق عليها أيضًا، حتى تكون الأدلة مرتبطة بما ينتظره فريق العمل من النظام.
قبل تغيير الإنتاج، اتفق على نافذة الصيانة والمشغّل ومراجع الأعمال وطريقة التواصل عند حدوث مشكلة. حدّد الطلبات والعمليات المجدولة التي قد تكون نشطة خلالها. تفيد بيئة تجريبية محمية حيث تتوفر، بشرط إعداد بياناتها واتصالاتها الخارجية للاختبار حتى لا ترسل رسائل أو تنفذ معاملات غير مقصودة أثناء التجربة.
حدّد مواد التعافي وعلاقتها ببعضها: الكود أو الصور، وقاعدة البيانات، والملفات المرفوعة، والإعدادات. اسأل من يستطيع استعادتها وكيف ستُسوّى الكتابات التي حدثت بعد أخذ النسخة. دوّن حالة PHP المطلوبة بعد الاستعادة حتى لا تتحول صورة أقدم إلى قرار غير مراجع يعيد بيئة تشغيل لم يوافق عليها المسؤول عن الأمان.
اتفق على أسباب إيقاف الاعتماد. تعطل الدخول، أو ظهور ملف خاص لمن لا يحق له، أو تكرار إجراء تجاري يحتاج صاحب قرار معروفًا. راجع الأمان وتوافر الخدمة معًا عند اختيار الاستعادة أو الاحتواء أو الإصلاح اللاحق. احتفظ بسبب القرار ودليله والقيود المؤقتة في التذكرة ليتمكن فريق آخر من متابعة العمل دون تخمين.
اختر الوظائف التي يعتمد عليها العمل، بحسابات وبيانات اختبار مسموحة تمثل الأدوار الفعلية. الجدول التالي مقترح للقبول، ولا يعني أن كل تطبيق PHP خاص يدعم جميع هذه الوظائف. يحدد مالك التطبيق النتيجة الصحيحة قبل التغيير، ثم يقارن الفريق ما حدث بها ويترك ما لم يُختبر معلّقًا بوضوح.
| فحص مقترح | دليل قبول تتفق عليه مسبقًا |
|---|---|
| الدخول واستعادة الحساب | وصول النتيجة المسموحة إلى الحساب الصحيح |
| رفع ملف واسترجاعه | نجاح الرفع الصحيح ورفض التنزيل غير المخوّل |
| إرسال استفسار أو طلب | سجل واحد مقصود وإشعار يصل إلى وجهته |
| تشغيل مهمة خلفية أو مجدولة | نتيجة نهائية واضحة ومعالجة إعادة المحاولة |
| استدعاء تكامل أساسي | صحة سلوك الطلبات المقبولة والمرفوضة |
سجّل الرفض والفشل إلى جانب النجاح. تتبّع إرسال النموذج حتى وجهته، ولا تتوقف عند صفحة الشكر. قبل تكرار مهمة خلفية، افحص ما إذا كانت المحاولة الأولى قد غيّرت بيانات العمل بالفعل. استخدم سجل التطبيق المعتاد حيث يتوفر، مع تجنب نسخ حمولات حساسة إلى تقرير الصيانة أو مشاركة تفاصيل تتجاوز ما يحتاجه المراجع.
لموقع ووردبريس أو متجره، راجع دليل قبول النماذج والدفع في ووردبريس. وللارافيل استخدم قائمة نشر لارافيل ومهامه الخلفية، وللنشر التحريري راجع فحوص نشر دروبال والوصول للمستندات. اربط نتيجة كل منصة بصف البنية الذي يشغّلها، دون استبدال اختباراتها بإثبات تحديث الخادم وحده.
اطلب فصل القرار الأمني المباشر عن مشروع التوافق الأوسع. يوضح تنبيه PHP وجود تصحيحات مورّدين ونقل محدود لتصحيحات المصدر لبعض الفروع القديمة. تمثل نشرة Ubuntu للإصدارات الأقدم مثالًا لتغطية مرتبطة بمورّد؛ يجب مطابقة أهلية الحصول عليها ودليل الحزمة مع النظام الفعلي قبل اعتمادها في خطة المعالجة.
لا تكرر حكمًا مطلقًا بعدم وجود أي تصحيح قديم، ولا تصف إصلاحًا استثنائيًا بأنه عودة للصيانة الأصلية المعتادة. دوّن الحل القصير الأجل ومورّده ومسار الانتقال إلى بيئة مدعومة. راجع إطار العمل والحزم والامتدادات والكود الخاص قبل تحديد الوجهة، ثم استخدم دليل تخطيط ترحيل التطبيقات القديمة لترتيب التغيير الأوسع.
واصل الاستجابة أثناء تقييم التوافق، بالاستناد إلى الإرشادات الرسمية الحالية وتقدير المشغّل للقيود المؤقتة اللازمة. وجود تقدير لمشروع ترحيل لا يحسم وحده حالة تطبيق معرض للخطر، لذلك يحتاج كل صف في الحصر إلى قرار مباشر ومسؤول واضح حتى تكتمل خطوات الانتقال المتفق عليها.
أغلق كل صف بنشرة الإصلاح المناسبة ودليل الحزمة أو الصورة والنشر الفعلي ونتائج التطبيق والاستثناءات. أضف تقييم التنبيه الإضافي واسم المراجع ومسؤول الصيانة التالية. اترك المكوّن غير المختبر معلّقًا حتى عندما يعمل الموقع الرئيسي، وحدّد ما الذي يحتاجه المراجع التالي لاتخاذ قرار دون إعادة التحقيق في كل التفاصيل السابقة.
نجاح التصحيح واختبارات الوظائف لا يثبت غياب اختراق سابق. عند الاشتباه، اتفق على التحقيق والاستعادة مع الفريق المسؤول؛ يقدم إرشاد NCSC لاستجابة PHP سياقًا للحادث. احتفظ بمسار التحقيق منفصلًا عن قبول النشر هنا، مع تحديد من يتولى المتابعة وما الأدلة التي يجب حمايتها وفق إجراءات الفريق.
الخلاصة سلسلة يمكن تتبعها من الإصلاح المناسب إلى التطبيق العامل ثم نتيجة العمل المختبرة. استخدمها لمراجعة الحصر كله بدل منح الحساب حالة مكتملة بسبب مؤشر أخضر واحد. كل استثناء يحتاج وصفًا ومسؤولًا وخطوة تالية، حتى يصبح التسليم مفيدًا لمن يتولى التشغيل بعد انتهاء نافذة الصيانة.
نفحص التركيب ونتفق على التصحيح المتوافق أو مسار الترقية، ونتحقق من البيئة المنشورة ونختبر الوظائف المشمولة. ناقش تحديث PHP على DigitalOcean ضمن نطاق البنية والتعافي. تُقيّم أعمال الحاويات المعقدة وKubernetes وتعديلات التطبيق والتحقيق والرعاية المستمرة بصورة منفصلة حيث يلزم، ولا تُضاف تلقائيًا إلى ساعات إدارة الاستضافة دون اتفاق.
اطلب فحص أمان موقعك. أرسل الرابط والمنصة وترتيب الاستضافة وإصدار PHP إن عرفته، والوظائف الأساسية وأي اشتباه باختراق. وضّح قيود الصيانة والشخص الذي يعتمد التغيير، واترك كلمات المرور ومفاتيح API وسجلات العملاء خارج الرسالة الأولى. نؤكد النطاق والمدة والسعر بعد المراجعة، ونوثق الاختبارات والمسؤوليات المتبقية عند التسليم.
