الإجابة المختصرة: أظهرت ثغرات PHP2Shell (CVE-2026-109618 وCVE-2026-109619) مرة أخرى حجم المخاطر التي تحملها إصدارات PHP القديمة. لم يصدر مشروع PHP إصلاحًا رسميًا للأنظمة التي تعمل على PHP 7.x و8.0 و8.1، وأصبح أمنها معتمدًا على تحديث مزوّد الاستضافة. في 360 Soft ننقل تطبيقات PHP القديمة لديكم إلى الإصدار 8.3 أو 8.4 في بيئة اختبار، ونعالج مشكلات التوافق، ونطلقها على الخادم الحي دون انقطاع.
لماذا الترقية الآن؟
- الإصدارات غير المدعومة لا تتلقى تحديثات: PHP 8.1 وما قبله خارج الدعم النشط، وقد صدرت تحديثات PHP2Shell الرسمية لفروع 8.2 و8.3 و8.4 و8.5 فقط.
- دعم 8.2 يقترب من نهايته: ينتهي الدعم الأمني لـ PHP 8.2 في 31 ديسمبر 2026، والانتقال إليه اليوم يعني تكرار العمل بعد أشهر قليلة.
- التدقيق والامتثال: في عمليات التدقيق المؤسسي واختبارات الاختراق ومراجعات حماية البيانات يُسجَّل استخدام برمجيات غير مدعومة كملاحظة.
- الأداء: يعمل PHP 8.3 و8.4 أسرع بشكل ملحوظ من إصدارات 7.x، مما قد يخفض تكلفة الخوادم.
مراحل الترقية
- الجرد والتحليل المسبق: حصر إصدار PHP وإطار العمل والإضافات والمكتبات، ورصد أسطر الشيفرة غير المتوافقة بأدوات التحليل الثابت (PHPCompatibility وRector).
- بيئة الاختبار: إنشاء نسخة مطابقة للنظام الحي على إصدار PHP المستهدف دون المساس بالموقع الحي.
- الإصلاحات: تحديث الدوال المحذوفة وأخطاء الأنواع والإضافات والمكتبات القديمة، وترقية إطار العمل عند الحاجة.
- الاختبار: تجربة مسارات العمل الحرجة (الدخول والدفع والنماذج والتقارير والتكاملات) من البداية إلى النهاية، ومقارنة السجلات والأداء.
- الإطلاق: يتم الانتقال في وقت انخفاض الحركة مع نسخة احتياطية وخطة تراجع جاهزة، ثم مراقبة النظام 7 أيام بعد الإطلاق.
المنصات التي نعمل عليها
| المنصة | العمل المعتاد | المدة التقديرية |
|---|---|---|
| WordPress / WooCommerce | توافق القوالب والإضافات، استبدال الإضافات المهجورة، الانتقال إلى PHP 8.3/8.4 | 1 إلى 3 أيام عمل |
| Laravel | من Laravel 5.x إلى 9.x نحو إصدار حديث، تحديث الحزم، الاختبارات | 1 إلى 4 أسابيع |
| CodeIgniter وYii وSymfony | ترقية إصدار إطار العمل أو النقل إلى بنية حديثة | 2 إلى 6 أسابيع |
| Magento وOpenCart وPrestaShop | تحديث المنصة والوحدات، اختبار تكاملات الدفع | 1 إلى 4 أسابيع |
| PHP مكتوب خصيصًا (دون إطار عمل) | تحليل الشيفرة، إعادة كتابة الوحدات الحرجة أو تغيير المنصة | حسب التحليل |
إذا كانت الشيفرة قديمة جدًا أو اقتربت تكلفة الترقية من تكلفة إعادة الكتابة، نوضح ذلك صراحة في التحليل المسبق، ونعرض حينها خيار التحويل من PHP إلى.NET وخيار إعادة البناء على Laravel حديث للمقارنة.
مشكلات التوافق الشائعة التي نعالجها
- الدوال والامتدادات المحذوفة (مثل دوال mysql_* القديمة وeach() وcreate_function())
- تشدد فحص الأنواع: تمرير null إلى معاملات داخلية لا تقبله، ومقارنات النصوص بالأرقام
- الخصائص الديناميكية التي أصبحت مهملة منذ 8.2 ومصدرًا لتحذيرات كثيرة في الأصناف القديمة
- حزم Composer والإضافات القديمة التي تشترط إصدارات PHP قديمة
- تغيّر معالجة الأخطاء بحيث تتحول تحذيرات سابقة إلى استثناءات
PHP2Shell: الحماية أثناء الترقية
لا ينبغي أن يبقى نظامكم مكشوفًا أثناء التخطيط للترقية. قبل الترقية نطبّق إجراءات مؤقتة (إعداد session.upload_progress وقواعد WAF وتقييد الوصول الخارجي) ونتأكد من تثبيت تحديث المزوّد. للتفاصيل راجعوا إصلاح ثغرات PHP الأمنية، وإذا كانت لديكم تطبيقات PHP كثيرة عبر علامات أو دول متعددة فإن التدقيق الأمني لـ PHP للشركات يبدأ بجرد شامل.
سيناريو توضيحي: متجر إلكتروني على PHP 7.4
سيناريو توضيحي، وليس مرجعًا لعميل. شركة تجزئة تدير متجر WooCommerce على PHP 7.4 مع نحو 40 إضافة، اثنتان منها متوقفتان عن التطوير منذ سنوات، إلى جانب تكامل خاص مع نظام المخزون. في حالة كهذه نتحقق أولًا من تحديث المزوّد والإجراءات المؤقتة، ثم ننشئ نسخة من المتجر على PHP 8.3، ونستبدل الإضافات المهجورة ببدائل مدعومة، ونعدّل التكامل ليتوافق مع فحص الأنواع الأكثر صرامة. تُختبر عملية الطلب وطرق الدفع والقسائم والتصدير إلى نظام المخزون بالكامل قبل الانتقال ليلًا مع خطة تراجع، ثم تُراجع سجلات الأخطاء وأزمنة الاستجابة يوميًا خلال الأيام السبعة التالية.
العمل مع فرق الخليج
نعمل داخل نظام التذاكر والمستودعات لديكم، وننسّق نوافذ الإطلاق مع أوقات الصيانة المعتمدة عندكم، بما في ذلك مراعاة عطلة نهاية الأسبوع ومواسم الذروة مثل رمضان والعروض الموسمية. فارق التوقيت بين إسطنبول والرياض صفر، ومع الدوحة صفر، ومع دبي ساعة واحدة، مما يسهّل الاجتماعات المشتركة خلال يوم العمل. وعند الحاجة يمكن تقديم دعم ميداني في مرحلة الإطلاق، مع إمكانية ترتيب مناوبات على مدار الساعة للأنظمة الحرجة.
نماذج التعاقد
| النموذج | النطاق | الأنسب لـ |
|---|---|---|
| مشروع ترقية واحد | ترقية تطبيق واحد إلى 8.3 أو 8.4 مع الاختبارات والإطلاق | أنظمة WordPress أو Laravel أو المتاجر على إصدارات قديمة |
| برنامج ترقية | ترقية عدة تطبيقات على دفعات حسب الأولوية | الوكالات والمجموعات والشركات ذات المواقع الكثيرة |
| ترقية مع صيانة | بعد الترقية صيانة شهرية وتحديثات أمنية ومراقبة | الفرق التي لا تملك خبرة PHP داخلية |
| مطورو PHP مخصصون | مطورون ينضمون إلى فريقكم عن بُعد أو في الموقع أو بنظام هجين | خطط التحديث طويلة المدى |
إذا كنتم تفضلون تعزيز فريقكم، يمكنكم أيضًا استئجار مطوري Laravel وPHP من خلالنا. تبدأ الفرق بمطور واحد وتنمو حسب الحاجة، وتبدأ المهام الأطول عادة خلال أسبوع إلى أسبوعين، ولدينا آلية استبدال منظمة إذا لزم تغيير أحد أعضاء الفريق.
مؤشرات الأداء ومعايير القبول
| المؤشر | المعنى المستهدف |
|---|---|
| نجاح المسارات الحرجة | جميع مسارات العمل المتفق عليها تعمل على الإصدار المستهدف قبل الإطلاق |
| حجم سجل الأخطاء | لا أخطاء أو تحذيرات إهمال جديدة خلال 7 أيام من المراقبة مقارنة بخط الأساس |
| زمن الاستجابة | زمن استجابة مماثل أو أفضل بعد الترقية |
| جاهزية التراجع | نسخة احتياطية وخطة تراجع مختبرة قبل الانتقال |
ما الذي يحدد حجم العمل (دون أسعار ثابتة)
- إصدار PHP وإطار العمل الحاليان
- عدد الإضافات والوحدات وحزم الطرف الثالث
- حجم الشيفرة الخاصة ومدى تغطيتها بالاختبارات
- عدد التكاملات (الدفع وERP وCRM وواجهات API)
- بيئة الاستضافة: مشتركة أو خادم افتراضي أو حاويات أو سحابة
- نافذة الإطلاق المطلوبة ومدة المراقبة
العقد وحماية البيانات
نعمل بموجب عقد خدمات بين شركات (B2B)، وتنتقل ملكية جميع تعديلات الشيفرة إليكم، ونوقّع اتفاقية عدم إفصاح قبل أول اجتماع عند الطلب. وإذا احتوت بيئات الاختبار على بيانات شخصية نلتزم بأنظمة حماية البيانات المعمول بها لديكم مثل أنظمة PDPL في السعودية والإمارات، وتخضع معالجتنا في تركيا لقانون KVKK. ونعمل ببيانات اختبار مُجهّلة كلما أمكن.
الأسئلة الشائعة
هل سيتعطل موقعي عند ترقية PHP؟
إذا غُيّر الإصدار مباشرة على الخادم الحي فقد تسبب الإضافات القديمة والدوال المحذوفة وتغيّرات الأنواع أخطاء. لذلك نجري الترقية أولًا على نسخة مطابقة في بيئة اختبار، ونصلح الأخطاء، ولا ننتقل إلى الخادم الحي إلا بعد نجاح الاختبارات، مع خطة تراجع جاهزة دائمًا.
أستخدم PHP 8.1، فهل الأمر عاجل؟
نعم. لم يصدر مشروع PHP إصدارًا رسميًا لـ 8.1 ضد ثغرات PHP2Shell، فالحماية تعتمد على تحديث المزوّد. ولأن 8.1 خارج الدعم النشط فسيتكرر الأمر مع الثغرة التالية. ينبغي أن يكون الهدف 8.3 أو 8.4.
إلى أي إصدار ننتقل؟
لمعظم تطبيقات الشركات يُعد PHP 8.3 خيارًا متوازنًا بمدة دعم طويلة وتوافق واسع مع المكتبات، ونوصي بـ 8.4 للتطوير الجديد. لا ينبغي اختيار 8.2 هدفًا لأن دعمه ينتهي في 31 ديسمبر 2026.
لدي Laravel أو CodeIgniter أو شيفرة خاصة قديمة، فهل يمكن ترقيتها؟
نعم. في مشاريع Laravel 5.x و6.x وCodeIgniter 3 ومشاريع PHP الخاصة القديمة نرسم خريطة الاعتماديات أولًا ثم نحدّث إطار العمل والحزم خطوة بخطوة. وإذا كانت الشيفرة قديمة جدًا وحرجة للأعمال فقد تكون إعادة الكتابة أو تغيير المنصة أوفر، ونوضح ذلك في التحليل.
كم تستغرق الترقية؟
يُختبر موقع WordPress منفرد ويُرقّى غالبًا خلال يوم عمل واحد. وتستغرق تطبيقات Laravel أو التطبيقات الخاصة متوسطة الحجم من أسبوع إلى 3 أسابيع، أما الأنظمة المؤسسية متعددة الوحدات فتُخطط بعد تحليل النطاق.
هل تحتاجون إلى الوصول إلى خادمنا الحي؟
للتحليل وبيئة الاختبار نحتاج إلى الشيفرة ونسخة من قاعدة البيانات، ويُفضّل أن تكون مُجهّلة. أما الوصول إلى الخادم الحي فيلزم للإطلاق فقط، ويكون مؤقتًا ومسجلًا.
هل يمكن الترقية دون انقطاع؟
نعم في معظم الحالات. يتم الانتقال في وقت انخفاض الحركة لديكم مع نسخة احتياطية وخطة تراجع، وفي الأنظمة الأكبر نستخدم النشر المتوازي إذا سمحت الاستضافة بذلك.
هل تتولون الصيانة بعد الترقية؟
نعم. يمكننا تولي الصيانة الشهرية والتحديثات الأمنية والمراقبة، أو تسليم النظام إلى فريقكم مع التوثيق.
اطلبوا ترقية الإصدار
أرسلوا إلينا عنوان موقعكم والمنصة المستخدمة ونوع الاستضافة. اتصلوا على +90 850 335 10 87 أو راسلونا عبر واتساب أو البريد info@360-soft.com أو من خلال صفحة التواصل. جميع الخدمات: خدمات التعهيد.
المصادر: إعلان أمن PHP وقائمة الإصدارات المدعومة، ملاحظات تقنية من Tenable وInMotion Hosting. آخر تحديث: 22 أكتوبر 2026.
