وصلتك رسالة من الاستضافة تطلب تحديث PHP بسبب PHP2Shell؟ قبل أن تغيّر أي إعداد، تأكد أولًا مما إذا كانت الشركة قد طبّقت الإصلاح بالفعل. بعض شركات الاستضافة أضافت التصحيحات إلى حزم PHP الموجودة لديها مع الإبقاء على رقم الإصدار نفسه، ولذلك قد لا يخبرك الرقم الظاهر في لوحة الموقع بالقصة كاملة.
بدأ الأمر في 21 أكتوبر 2026، عندما أصدر فريق PHP تحديثات لمعالجة ثغرتين حرجتين قد تسمحان بتنفيذ تعليمات برمجية على الخادم دون تسجيل الدخول. حصلت كل منهما على تقييم خطورة يبلغ 9.2 من 10 وفق CVSS v4.0. وإذا كان موقعك يعمل بووردبريس أو متجرك يعتمد على WooCommerce، فهذه تحديثات تحتاج إلى مراجعتها مع مسؤول الاستضافة.
المطلوب الآن أن تعرف حالة PHP التي يعمل عليها موقعك، وتثبت التصحيح إن لم يكن موجودًا، ثم تختبر الموقع بعد التحديث. إليك التفاصيل التي تساعدك على فعل ذلك دون تغيير إعدادات لا تحتاج إلى تغييرها.
ما الذي حدث في PHP بالضبط؟
PHP هي لغة البرمجة التي يعتمد عليها ووردبريس في تشغيل صفحات الموقع ومعالجة الطلبات. لذلك قد يكون ووردبريس محدثًا، بينما تحتاج نسخة PHP الموجودة على الخادم إلى تحديث أمني مستقل.
الثغرتان المعروفتان باسم PHP2Shell تتعلقان بكيفية تعامل PHP مع الذاكرة أثناء معالجة الطلبات:
- CVE-2026-109618: عند نفاد الذاكرة، قد يتوقف الطلب قبل اكتمال تجهيز بعض البيانات الداخلية. ثم تحاول PHP استخدام هذه البيانات أثناء تنظيف الطلب، بما قد يفتح بابًا لتنفيذ كود غير مصرح به.
- CVE-2026-109619: قد تبقى مراجع إلى ذاكرة جرى تحريرها مع طلب سابق. وعندما تصل معالجة طلب جديد إلى هذه المراجع، يمكن أن يؤدي الخلل إلى كشف بيانات أو تنفيذ تعليمات برمجية.
تشمل تحذيرات PHP بيئات الويب مثل PHP-FPM وApache مع mod_php وphp-cgi وFrankenPHP وLiteSpeed. تختلف طريقة الاستغلال وشروطه بينها؛ وقد وصف فريق PHP الخطر بأنه الأعلى مع mod_php، حيث ثبت إمكان بدء الهجوم قبل تشغيل كود الموقع نفسه. استخدام طريقة تشغيل أخرى لا يُغني عن مراجعة التحديث.
للتفاصيل التقنية، راجع التنبيه الرسمي للثغرة الأولى والتنبيه الرسمي للثغرة الثانية.
ما إصدارات PHP التي تحتاج إلى التحديث؟
أصدر مشروع PHP الإصلاحات التالية في 21 أكتوبر. ابحث عن الفرع الذي يستخدمه موقعك في الجدول، ثم قارن رقم الإصدار:
| فرع PHP | الإصدارات المتأثرة | أول إصدار مصحح |
|---|---|---|
| 8.5 | 8.5.11 وما قبله في الفرع | 8.5.12 |
| 8.4 | 8.4.26 وما قبله في الفرع | 8.4.27 |
| 8.3 | 8.3.35 وما قبله في الفرع | 8.3.36 |
| 8.2 | 8.2.34 وما قبله في الفرع | 8.2.35 |
إذا وجدت رقمًا أقدم، اسأل الاستضافة عن التصحيح قبل أن تحكم بأن الموقع ما زال معرضًا للخطر. قد تكون الشركة نقلت الإصلاح إلى نسختها الحالية، وهي طريقة تسمى Backporting. المطلوب منها تأكيد واضح يشمل رقمي الثغرتين أو رقم الحزمة المصححة.
أما إذا كان الموقع يعمل بـPHP 8.1 أو أقدم، فابدأ أيضًا في ترتيب الانتقال إلى فرع مدعوم. هذه الإصدارات خرجت من دعم مشروع PHP، حتى لو كانت الاستضافة توفر لها تصحيحات خاصة.
من أين تبدأ فحص موقعك؟
افتح لوحة ووردبريس، ثم انتقل إلى الأدوات ← صحة الموقع ← المعلومات ← الخادم. ستجد هناك إصدار PHP المستخدم في الموقع. سجّله، ثم راجع إشعارات الاستضافة أو اسأل دعمها عن حالة التحديث.
ولو كنت تدير أكثر من موقع أو نطاق فرعي، افحص كل واحد منها. قد تختلف نسخة PHP بين موقع وآخر، كما أن النسخة المستخدمة في سطر الأوامر ليست بالضرورة النسخة التي تعالج طلبات الزوار.
بدل إرسال سؤال عام مثل «هل موقعي آمن؟»، يمكنك أن تسأل الدعم بهذه الصيغة:
هل نسخة PHP التي يعمل عليها موقعي مصححة ضد CVE-2026-109618 وCVE-2026-109619؟ وهل أُعيد تشغيل خدمات PHP بعد التحديث؟ أرجو توضيح رقم الحزمة أو طريقة التحقق من تطبيق الإصلاح.
هذه الإجابة تمنحك شيئًا يمكن الرجوع إليه، بدل الاعتماد على أن الموقع يفتح بصورة طبيعية.
لو موقعك على Hostinger
أعلنت Hostinger اكتمال نشر إصلاح الثغرتين على خطط استضافتها باستثناء VPS الذي يديره العميل. وأوضحت أن بعض المواقع قد يظل يعرض PHP 8.5.11 رغم وجود التصحيح داخل الحزمة.
للتحقق، افتح Websites → Dashboard → PHP Info وراجع Build Date. بحسب تعليمات Hostinger، يعني تاريخ 21 أكتوبر 2026 أو بعده أن حزمها تتضمن إصلاح الثغرتين. هذا معيار يخص Hostinger؛ إذا كانت استضافتك لدى شركة أخرى، اطلب منها طريقة التحقق الخاصة بها.
أما على VPS، فتابع التحديث مع الشخص الذي يدير الخادم. التفاصيل والتحديثات منشورة في إعلان Hostinger عن PHP2Shell.
كيف تحدّث PHP دون إرباك الموقع؟
إذا أكدت الاستضافة أن الإصلاح لم يُثبت بعد، اتفق معها على تطبيقه. الحل هو تثبيت إصدار مصحح أو حزمة يؤكد المزود أنها تحتوي على التصحيحات، ثم إعادة تشغيل عمليات PHP المعنية. ويمكن ترتيب العمل بهذه الخطوات:
جهز نسخة احتياطية تستطيع استعادتها
احتفظ بنسخة من ملفات الموقع وقاعدة البيانات، واعرف أين توجد وكيف ستستعيدها عند الحاجة. وإذا كنت ستنتقل إلى فرع PHP مختلف، راجع توافق القالب والإضافات معه وجربه على نسخة اختبار، خصوصًا في المتاجر التي تستخدم بوابات دفع أو إضافات مخصصة.
تأكد من أن التحديث أصبح هو المستخدم فعليًا
قد تُثبت الحزمة الجديدة بينما تظل عمليات قديمة تعمل في الذاكرة. لذلك اسأل عن إعادة تشغيل جميع عمال PHP الذين يخدمون الموقع، ثم راجع نسخة بيئة الويب مرة أخرى. هذه خطوة يتولاها مزود الاستضافة أو مسؤول الخادم حسب نوع خدمتك.
جرّب رحلة العميل، وليس الصفحة الرئيسية فقط
في متجر WooCommerce، افتح منتجًا وأضفه إلى السلة، ثم اختبر إتمام الطلب ووسيلة الدفع ورسائل الطلب باستخدام وضع الاختبار المناسب. وفي موقع شركة، أرسل نموذج تواصل تجريبيًا وتأكد من وصوله، وراجع تسجيل الدخول وأي وظيفة أساسية يعتمد عليها العمل.
راجع سجل الأخطاء أيضًا. إذا ظهرت مشكلة توافق، سيكون لديك مسار واضح لتحديدها ومعالجتها، بدل اكتشافها من عميل تعذر عليه إتمام طلبه.
ماذا لو تعذر التحديث اليوم؟
قد يحتاج قالب قديم أو تكامل مخصص إلى معالجة قبل الانتقال إلى فرع أحدث. اسأل مزودك أولًا إن كان يستطيع تثبيت التصحيح داخل الفرع الحالي، ثم حدد موعدًا لمعالجة سبب التأخير.
تتضمن التنبيهات الرسمية إجراءات مؤقتة لتقليل بعض مسارات الاستغلال، مثل تقييد الطلبات ورفع الملفات وتعطيل session.upload_progress.enabled عند الحاجة. لكن هذه الإعدادات لا تعوض تثبيت التصحيح، وينبغي أن يراجعها مسؤول الخادم وفق طريقة تشغيل PHP ومتطلبات موقعك.
وإذا تقرر تعطيل تتبع تقدم الرفع، فيجب ضبط session.upload_progress.enabled=0 في إعدادات تُطبق قبل تحليل الطلب، مع إعادة تشغيل جميع العمال. وضع الإعداد داخل كود ووردبريس عبر ini_set() لا يحقق هذا الغرض. تجنب كذلك نسخ إعدادات الذاكرة أو حدود الرفع من شرح عام؛ فقد تتسبب في تعطيل رفع الملفات أو الاستيراد أو بعض وظائف المتجر.
هناك أيضًا تنبيه صدر في 23 أكتوبر
أضاف فريق PHP تنبيهًا عن مشكلة أخرى تحمل الرقم CVE-2026-115560 وترتبط بتتبع تقدم رفع الملفات في حالة غير معتادة: يبدأ التطبيق باستخدام php_binary أو php_serialize، ثم يغيّر معالج تسلسل الجلسة إلى php وقت التشغيل قبل استدعاء session_start()، مع بقاء ميزة تتبع الرفع مفعلة.
أوصى الفريق بتعطيل session.upload_progress.enabled حتى الإصدار الدوري التالي للحماية من هذا المسار. ووفق التنبيه، يمكن للتطبيقات التي لا تغير معالج التسلسل أثناء التشغيل إبقاء الميزة مفعلة.
لهذا، عندما تسأل الاستضافة عن الثغرتين، أضف سؤالًا عن هذا التنبيه أيضًا. الإصدارات الموجودة في الجدول تعالج ثغرتي 21 أكتوبر، ولا تعني وحدها أن مشكلة 23 أكتوبر عولجت. التفاصيل في أرشيف تنبيهات PHP الرسمي.
أسئلة قد تكون في بالك
هل يكفي تحديث ووردبريس والإضافات؟
تحتاج هذه الثغرات إلى تصحيح PHP نفسها على الخادم. استمر في تحديث ووردبريس والقالب والإضافات أيضًا، لكن لا تعتبر ظهور «كل التحديثات مثبتة» داخل لوحة ووردبريس تأكيدًا لحالة PHP.
هل هذا يعني أن موقعي تعرض للاختراق؟
وجود إصدار متأثر لا يثبت حدوث اختراق. وبالمثل، لا يثبت التحديث أن شيئًا لم يحدث قبله. إذا ظهرت ملفات غير معروفة أو حسابات إدارة لم تنشئها أو تنبيهات من الاستضافة، فاطلب مراجعة السجلات والملفات قبل الحكم على ما حدث.
هل أحتاج إلى نقل الموقع لاستضافة أخرى؟
ابدأ بالتواصل مع مزودك الحالي. إذا أكد تطبيق التصحيحات وقدم طريقة للتحقق منها، فقد حُسمت خطوة مهمة دون الحاجة إلى نقل الموقع. أما إذا تعذر الحصول على بيئة مدعومة أو إجابة واضحة عن التحديث، فحينها يستحق الأمر تقييم البدائل.
المصادر ومتابعة التحديثات
رُوجعت المعلومات في 24 أكتوبر 2026 بالرجوع إلى المصادر التالية. ولأن التنبيهات الأمنية قد تتغير مع ظهور تفاصيل جديدة، ارجع إلى أحدث توضيح من PHP ومزود استضافتك عند تنفيذ المعالجة.
- إصدارات PHP وتنبيهات أكتوبر 2026.
- التنبيه الرسمي: CVE-2026-109618.
- التنبيه الرسمي: CVE-2026-109619.
- Hostinger: حالة نشر التصحيحات.
- Hostinger: التحقق من إصدار PHP وتاريخ البناء.
مش متأكد من حالة PHP على موقعك؟
ابعت لنا تفاصيل موقعك ورسالة الاستضافة إن وجدت. نراجع معك حالة التحديث، ونوضح ما يحتاج إلى معالجة، ثم نختبر الوظائف المتأثرة بعد التنفيذ.
