تبدأ حماية لارافيل بعد تحديث PHP بالتحقق من بيئة الويب والعمليات الخلفية والمهام المجدولة، ثم اختبار صلاحيات التطبيق ووظائفه المهمة. اطلب من مسؤول التشغيل تحديد العمليات الفعلية والتصحيح المناسب لها، واتفق مع المطوّر على دليل قبول كل مسار. تحديث حزم Composer وحده لا يغلق هذه المهمة.
استخدم هذا الدليل لإعداد سجل نشر يستطيع فريق آخر مراجعته: ما الذي تغيّر، وأين بدأ استخدامه، وما الاختبارات التي نفذتموها، وما البنود التي بقيت مفتوحة. الأمثلة والجداول التالية اختبارات قبول مقترحة، وليست نتائج فحص لعميل. طابق الإجراءات مع إصدار تطبيقك وطريقة استضافته، وسمّ مسؤولًا يملك قرار إكمال النشر أو إيقافه.
حتى 23 أكتوبر 2026، يعالج تنبيه PHP الأصلي الثغرتين CVE-2026-109618 وCVE-2026-109619. أكّد الحزمة المصححة أو بيئة التشغيل المناسبة مع المشغّل، وراجع مرجع حادث PHP وجدول الإصدارات المصححة لتفاصيل الإصدارات والتنبيهات الخاصة بالبيئات القديمة. يحتاج تحديث حزم إطار العمل وتصحيح PHP إلى دليلين منفصلين ضمن سجل المعالجة.
ويعرض تنبيه PHP الصادر في 23 أكتوبر متابعة مرتبطة بالمعرّف CVE-2026-115560 وتركيب غير معتاد لمعالج الجلسات وتقدم رفع الملفات. اطلب من المطوّر تقييم انطباق الحالة وإرشادات التخفيف الحالية بصورة مستقلة. لا تفترض أن تثبيت التصحيح الأصلي يغطي هذه المتابعة، أو أن جميع تطبيقات لارافيل تستخدم الإعداد المعني.
سجّل إصدار إطار العمل ومصدر PHP وطريقة النشر والقيود التي يعرفها الفريق. افصل المعالجة العاجلة عن مشروع ترقية التطبيق الكامل، مع تسمية مسؤول لكل عائق. وللتخطيط الأوسع يمكنك الرجوع إلى خطة تحديث النظام القديم على مراحل دون تأجيل تحديد التعرض الحالي ومسار معالجته.
تختلف الإجراءات بحسب المنتج. بحسب نشرة Laravel الرسمية للحادث، المحدّثة في 23 أكتوبر عند 08:31 بالتوقيت العالمي، عولجت التطبيقات العاملة على Cloud؛ وتتطلب Forge إجراءً لكل خادم؛ وتحتاج بيئات Vapor الأصلية مع PHP 8.2 فأحدث إلى إعادة نشر، والصور المخصصة أو Docker إلى نشر جديد. راجع قيود الأنظمة والإصدارات القديمة في النشرة نفسها قبل التنفيذ.
اكتب اسم المنتج والبيئة في أول تذكرة العمل. تأكيد يخص تطبيقًا على Cloud لا يثبت حالة خادم Forge أو صورة مخصصة تستخدمها منشأتك. اطلب من المسؤول توثيق الإجراء المكتمل أو تأكيد المزوّد للتطبيق المقصود، ثم سمّ الشخص الذي سيتحقق من النتيجة. احتفظ بتاريخ قراءة النشرة لأن الإرشادات تغيرت أثناء الحادث.
إذا كنت تستخدم استضافة أخرى، فارجع إلى مورّد الحزمة أو البيئة الفعلية. لا تحوّل خطوات لوحة تحكم معينة إلى أوامر لخادم مختلف اعتمادًا على التشابه في الاسم. يساعدك دليل توزيع مسؤوليات تشغيل الاستضافة على تحديد حدود عمل المشغّل والمطوّر وممثل المنشأة، خصوصًا عندما يتولى أكثر من مورّد تشغيل الموقع.
خصّص صفًا لكل مسار تشغيل مستقل. توضح نتيجة فحص الإصدار في الطرفية الاستدعاء الذي نفذته، لكنك تحتاج من المشغّل بيان علاقته بخدمة الويب وعمّال الطوابير. أضف الخوادم الإضافية وبيئات الإنتاج ومجموعات العمال قبل اعتبار الحصر مكتملًا. ضع عبارة «بانتظار التحقق» أمام التفاصيل الناقصة حتى لا يعتمد عليها شخص آخر باعتبارها مؤكدة.
| مسار التشغيل | الدليل المطلوب | اختبار قبول مقترح |
|---|---|---|
| طلبات الويب | بيئة الخدمة الفعلية أو الصورة المستخدمة | اكتمال طلب مهم بحساب مصرح له |
| عمّال الطوابير | المجموعة والبيئة وسجل إعادة التشغيل أو الاستبدال | وصول مهمة مسموحة إلى نتيجتها |
| المهام المجدولة | مسؤول الاستدعاء وبيئته وموعد المهمة | اكتمال مهمة مختارة في وقتها المتوقع |
| خدمة تطبيق طويلة التشغيل | هوية الخدمة وطريقة نشرها | استقبال الطلبات بالإصدار المقصود |
اكتب مرجع إصدار التطبيق بجانب دليل PHP. وفي الحاويات، اطلب مرجع الصورة التي وصلت إلى كل بيئة وتأكيد وضع النسخ القديمة التي كانت تستقبل الطلبات. إنشاء صورة جديدة في مستودع الصور خطوة تحتاج بعدها إثبات استخدامها في التشغيل.
قد يستطيع المطوّر نشر الكود دون تعديل حزم الخادم، وقد يحدّث المشغّل PHP دون معرفة نتيجة مهمة التقارير. اتفق على نقطة التسليم بينهما، ومن يقبل الدليل، قبل بدء نافذة الصيانة. أضف قناة التواصل المعتمدة إذا احتاج أحدهما قرارًا أثناء التنفيذ.
تشرح وثائق Composer الأساسية تثبيت الاعتماديات وملف الإصدارات المقفلة. احتفظ بسجل هذه الحزم إلى جانب سجل حزمة PHP أو صورة التشغيل. اطلب وصفًا واضحًا للطبقة التي تغيرت وسبب تغييرها؛ نجاح تثبيت الاعتماديات لا يقدّم وحده دليل تصحيح بيئة التشغيل.
جهّز تجربة محمية تستخدم بيئة PHP المقترحة وإصدار التطبيق الذي تنوون نشره. دوّن الإضافات والتكاملات التي يحتاج المطوّر إلى فحص توافقها. استخدم حسابات اختبار ووجهات خارجية متفقًا عليها، وتحقق من إعدادات البريد والاتصالات قبل بدء التجربة حتى لا تُرسل رسائل فعلية للعملاء أو تُنشأ معاملات إنتاجية بالخطأ.
ناقش ما إذا كان تغيير الحزم ضروريًا للتوافق. وأبقِ الميزات الجديدة خارج تذكرة الحادث ما لم يقبل مسؤول النشر اختباراتها وخطة استعادتها. إذا تعذّر اختبار تكامل، اذكر القيد وصاحبه وموعد المراجعة بدل تسجيل نجاح عام للتطبيق.
ولقرار التقنية على المدى الأطول، راجع المقارنة المعمارية بين Laravel وNode.js. هنا تختبر تطبيقًا قائمًا بعمليات وبيانات محددة؛ لذلك اكتب شروط قبول تصف عمله الحالي، واترك قرار استبدال إطار العمل لمساره ونطاقه المناسبين.
توضح وثائق طوابير Laravel أن العمال يحتفظون بحالة التطبيق ويحتاجون معالجة إعادة التشغيل ضمن النشر. اتبع إجراء إصدارك ومدير العمليات المستخدم، وسجّل كيف تبدأ العملية البديلة. تحقق من عودة العامل إلى العمل بعد التغيير، مع تحديد مجموعة العمال التي يشملها الدليل.
اختر مثالًا مأمونًا ومصرحًا به، مثل تصدير تقرير ببيانات اختبار. تتبع الطلب من قبوله إلى معالجته في الطابور وإنشاء الملف وتنزيله بالحساب المسموح. احتفظ بمعرّفات تربط هذه الأحداث دون نسخ بيانات سرية إلى تذكرة مشتركة. رسالة قبول الطلب في الواجهة لا تثبت أن المهمة الخلفية أكملت عملها.
اتفق على التعامل مع مهمة فشلت في منتصف التنفيذ. قبل إعادة المحاولة، افحص هل أنشأت ملفًا أو أرسلت رسالة أو عدّلت سجلًا بالفعل، ثم اطلب من صاحب التطبيق تحديد الإجراء المقبول. دوّن النتيجة الفعلية، بما فيها الفشل الذي بقي بلا حل والشخص المسؤول عن متابعته.
وللمهام المجدولة، راجع وثائق الجدولة المناسبة لإصدار Laravel. حدّد المنطقة الزمنية والبيئة وموعد التشغيل التالي لمهمة مختارة. افحص مخرجاتها بعد التنفيذ؛ قراءة تعريف الموعد لا تكفي لإثبات وصول العمل إلى النتيجة التي تنتظرها المنشأة.
يوجه دليل نشر Laravel الطلبات إلى نقطة الدخول العامة، وينبّه إلى تعطيل وضع التصحيح في الإنتاج وإعادة تحميل الخدمات طويلة التشغيل. راجع الإعدادات الفعلية مع المطوّر، واستخدم وثائق الإصدار المثبت قبل نقل أمر أو إعداد خادم من مثال عام إلى بيئتك.
ضمن النطاق المتفق عليه، اطلب فحص الوصول العام إلى ملفات البيئة والمستودع والسجلات وأرشيفات النسخ الاحتياطية. احتفظ بالتفاصيل التشخيصية في سجلات مقيدة الوصول. ومن الاختبارات المقترحة على بيئة التجربة إحداث فشل متوقع في رفع ملف، ثم مراجعة رسالة الزائر وسجل المشغّل، مع استبعاد الأسرار وبيانات العملاء غير اللازمة من الأدلة المتداولة.
خطّط لتدوير مفتاح التشفير عندما توجد حاجة محددة له. تشرح وثائق تشفير Laravel أثر تغيير المفتاح على الجلسات والبيانات المشفرة سابقًا. راجع الاعتماديات وطريقة الاستعادة قبل التغيير، ولا تضع قيمة المفتاح في التذكرة أو نموذج التواصل الأولي.
وإذا كانت المنشأة تدير موقع ووردبريس أيضًا، فاستخدم له قائمة تحديث ووردبريس والتحقق من الاستضافة. احتفظ بتأكيد بيئة التشغيل ونتائج الاختبار لكل تطبيق على حدة، حتى إن كان المورّد أو حساب الاستضافة مشتركًا بينهما.
جهّز حسابات وسجلات اختبار تمثل أدوار المستخدمين. توفر وثائق التفويض في Laravel آليات لبناء قواعد الوصول، بينما يحدد فريقك قواعد العمل التي يحتاجها التطبيق. اختبر الطلب عند الخادم إلى جانب الواجهة؛ إخفاء زر إداري لا يثبت أن العملية ترفض مستخدمًا غير مخول.
الجدول التالي نقطة بداية مقترحة. عدّل النتائج المتوقعة بحسب سياسة التطبيق، ثم سجّل المشاهدة الفعلية بعد التحديث، مع اسم الحساب التجريبي ودور المراجع دون كشف بيانات حساسة.
| الطلب ببيانات اختبار | النتيجة المطلوب الاتفاق عليها | الدليل الذي تحتفظ به |
|---|---|---|
| عميل يقرأ سجله | السماح | الحساب والسجل الصحيحان |
| عميل يطلب سجل عميل آخر | الرفض دون كشف البيانات | الاستجابة وغياب البيانات المحمية |
| مستخدم عادي يطلب عملية إدارية | الرفض دون تنفيذ التغيير | الاستجابة وحالة العمل دون تعديل |
| زائر غير مسجّل يغير بيانات الحساب | الرفض | الاستجابة وبقاء الحساب دون تغيير |
| مهمة خلفية تصدّر بيانات محمية | الالتزام بنطاق التفويض | محتوى الملف ومن يستطيع تنزيله |
في التطبيق الذي يخدم عدة منشآت، أضف حالة وصول بين منشأتين تجريبيتين. اشمل واجهات API وتنزيل الملفات المرتبطة بالوظيفة، وافحص حالة السجل المحفوظ إلى جانب الرسالة الظاهرة. اكتب الفحوص التي لم تنفذوها بوضوح؛ نجاح طلب قريب منها لا يثبت نجاحها، ولا يحدد وحده صلاحية إغلاق بند المراجعة.
اتفق على مسار النسخ والاستعادة قبل تغيير الإنتاج. حدّد من يستطيع استرجاع البيانات والإعدادات، وأين يوجد دليل الاستعادة، وكيف ستتعاملون مع السجلات الجديدة التي ينشئها المستخدمون بعد التغيير. إذا احتجتم ترحيل قاعدة البيانات، فأدرجوا قرار التعافي الخاص به ضمن خطة النشر بدل افتراض أن إعادة ملفات التطبيق تكفي.
ضع شروطًا واضحة للتوقف، مثل تعذر إثبات بيئة الويب، أو عدم عودة عامل للطابور، أو نتيجة صلاحيات غير متوقعة، أو فشل وظيفة مهمة. يقرر مسؤول النشر الإجراء التالي وطريقة إبلاغ المتأثرين. دوّن الاعتماديات التي تحتاج تنسيقًا بين الفرق، ومن يملك الموافقة على العودة إلى المسار المعتاد.
أغلق العمل بسجل يجمع التصحيح وتقييم التنبيه اللاحق ومرجع التطبيق ونتائج العمال والجدولة والصلاحيات والاستثناءات. سمّ مسؤول مراجعة الأخطاء بعد النشر وحدّد وقت المراجعة. تثبيت التحديث ونجاح الوظائف لا يثبتان غياب اختراق سابق؛ تحتاج الشبهة إلى تقييم مستقل، مع الرجوع إلى إرشادات NCSC للحادث.
نفحص تركيب التطبيق ونتفق على معالجة PHP أو خطة ترقية متوافقة، ثم نتحقق من البيئة الفعلية ونختبر الوظائف المهمة. ناقش متطلبات حماية لارافيل مع نطاق البنية التحتية المُدارة. تبقى التقوية والنسخ الاحتياطية والمراقبة ووقت الإدارة مرتبطة بالباقة والاتفاق، وتحتاج تعديلات الكود والترقيات والتحقيق الإضافي إلى نطاق مستقل حيث يلزم.
جهّز عنوان الموقع ومنتج الاستضافة وإصدار Laravel ونسخة PHP إن عرفتها، مع وصف العمال والمهام المجدولة ومسارات العمل المهمة. اذكر الاشتباه في اختراق أو القيود على وقت الصيانة. لا ترسل كلمات المرور أو مفاتيح التطبيق أو سجلات العملاء في الرسالة الأولى؛ نتفق على طريقة الوصول المناسبة بعد تحديد العمل.
اطلب فحص أمان موقعك. نؤكد النطاق والموعد والسعر بعد المراجعة، ونوضح أي تحقيق أو تنظيف للشيفرة الضارة أو تعديل كبير أو صيانة مستمرة يحتاج اتفاقًا منفصلًا. يتضمن التسليم ما نفذناه، والاختبارات التي أجريناها، وحدود التحقق، ومسؤول كل بند بقي مفتوحًا.
