ثغرة PHP التي هزّت المواقع: هل موقعك أو متجرك معرّض، وماذا تفعل الآن

ثغرة PHP التي ملأت الأخبار في أواخر أكتوبر 2026 هي في الحقيقة ثغرتان حرجتان (CVE-2026-109618 وCVE-2026-109619، وعُرفتا إعلامياً باسم PHP2Shell) في محرّك PHP نفسه، وهو البرنامج الذي يعمل على خادم الاستضافة ويشغّل ووردبريس وووكومرس ومعظم أنظمة إدارة المحتوى. بحسب إعلان مشروع PHP الرسمي في 21 أكتوبر 2026، قد تسمح الثغرتان لمهاجم بتنفيذ أوامر على الخادم دون أي تسجيل دخول، والحل الكامل الوحيد هو تحديث PHP إلى الإصدارات المصحّحة: 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35.

إن كان موقعك أو متجرك مبنياً على ووردبريس أو ووكومرس أو أي نظام بلغة PHP، فالأرجح أنه معنيّ بالأمر، حتى لو كانت كل الإضافات والقوالب محدّثة، لأن المشكلة ليست في موقعك بل في البرنامج الذي يعمل تحته. الخبر الجيد أن ما عليك فعله واضح: تعرف إصدار PHP في موقعك، وتطلب من مزوّد الاستضافة تأكيداً مكتوباً بأنه حدّثه، ثم تراجع النسخ الاحتياطية والتحديثات. هذا الدليل يشرح ذلك خطوة بخطوة، بلغة صاحب العمل لا المبرمج.

ما هي ثغرة PHP باختصار، ولماذا كل هذه الضجة؟

PHP لغة برمجة تعمل على الخادم، وتستخدمها نسبة كبيرة جداً من مواقع الإنترنت: وفق إحصاءات W3Techs (بيانات 3 نوفمبر 2026) يستخدم PHP نحو 69.1% من المواقع المعروفة لغة الخادم فيها. لهذا تحدّثت التغطية العربية عن خطر يطال جزءاً كبيراً من مواقع العالم، كما في تقرير الجريدة عمّا تعنيه الثغرة لمشغّلي المواقع، والذي نبّه إلى أن قواعد بيانات المواقع غير المحدّثة قد تنكشف، وإلى أن الهجمات الآلية متوقعة لأسابيع أو أشهر.

ما جعل الأمر استثنائياً هو ردّ فعل الحكومات: بحسب الجزيرة، أوقفت جهات حكومية في ألمانيا وفرنسا وبلجيكا وهولندا وفنلندا والتشيك بعض مواقعها مؤقتاً لتطبيق التحديث، ونصحت وكالة الأمن القومي الأمريكية بإيقاف المواقع التي لا يمكن تحديثها فوراً. كما دعا المركز الكندي للأمن السيبراني المؤسسات إلى حصر كل أنظمة PHP لديها، بدءاً بالمكشوفة على الإنترنت، وتثبيت التحديثات، أو فصلها عن الشبكة العامة إن تعذّر ذلك.

الخلاصة لصاحب العمل: هذه ليست ثغرة في إضافة أو قالب، بل في الأساس الذي يقوم عليه الموقع. لذلك لا يكفي أن تقول لوحة ووردبريس إن "كل شيء محدّث".

هل موقعي أو متجري معرّض لثغرة PHP؟

اسأل نفسك ثلاثة أسئلة:

1. هل موقعك مبني بلغة PHP؟ ووردبريس، ووكومرس، Magento، Drupal، Joomla، OpenCart، Laravel: كلها تعمل بـ PHP. أما المتاجر على منصات مستضافة بالكامل مثل سلة أو زد أو Shopify، فالخادم ليس من مسؤوليتك، والمنصة هي من يدير هذا الجانب.
2. ما إصدار PHP الذي يعمل عليه؟ إن كان أقدم من الإصدارات المصحّحة المذكورة أعلاه في الفرع نفسه، فهو معرّض.
3. هل إصدارك ما زال مدعوماً أصلاً؟ وفق موقع PHP، الفروع 8.1 وما قبلها لم تعد تتلقى تحديثات من المشروع، وبعض الموزّعين يقدّمون إصلاحات منقولة لها، لكن الأسلم الترقية. والفرع 8.2 ينتهي دعمه في 31 ديسمبر 2026.

الفرع	الإصدار المصحّح	حالة الدعم (حسب php.net)
PHP 8.5	8.5.12 أو أحدث	مدعوم
PHP 8.4	8.4.27 أو أحدث	مدعوم
PHP 8.3	8.3.36 أو أحدث	مدعوم
PHP 8.2	8.2.35 أو أحدث	ينتهي دعمه 31 ديسمبر 2026
PHP 8.1 وما قبلها	لا يوجد إصدار رسمي	خارج الدعم: رقِّ الموقع

ملاحظة مهمة: بعض شركات الاستضافة تطبّق الإصلاح على حزم توزيعة لينكس الخاصة بها دون تغيير رقم الإصدار الظاهر. لذلك لا تعتمد على الرقم وحده؛ اطلب من المزوّد تأكيداً صريحاً.

كيف تعرف إصدار PHP في موقعك؟

• من لوحة ووردبريس: الأدوات ← صحة الموقع ← معلومات ← قسم "الخادم"، كما يشرح دليل ووردبريس الرسمي لشاشة صحة الموقع. ستجد هناك إصدار PHP، وقد تظهر لك أيضاً رسالة "موقعك يعمل على إصدار قديم من PHP".
• من لوحة الاستضافة: في cPanel ابحث عن "Select PHP Version" أو "MultiPHP Manager"، وفي Plesk تجده في إعدادات PHP للنطاق. أسماء القوائم تختلف بين المزوّدين.
• اسأل المزوّد مباشرة: إن لم تجد الخيار، افتح تذكرة دعم واطلب رقم الإصدار وتاريخ آخر تحديث أمني.

ماذا تفعل هذا الأسبوع: قائمة عملية

1. خذ نسخة احتياطية كاملة الآن (الملفات وقاعدة البيانات)، واحفظ نسخة خارج الخادم نفسه. أي تحديث قد يكسر شيئاً، والنسخة تتيح لك التراجع.
2. اطلب من الاستضافة تحديث PHP إلى الإصدار المصحّح في فرعك أو أحدث، وتأكيداً مكتوباً بتاريخ التطبيق.
3. إن كنت على 8.1 أو أقدم، خطّط للترقية إلى فرع مدعوم. جرّبها أولاً على نسخة تجريبية من الموقع لأن الإضافات القديمة قد لا تعمل على PHP الأحدث.
4. حدّث ووردبريس والإضافات والقوالب واحذف ما لا تستخدمه. الثغرة الحالية في PHP، لكن الإضافات تبقى أكبر مصدر للثغرات في ووردبريس: وفق تقرير Patchstack لحالة أمان ووردبريس، اكتُشفت 11,334 ثغرة جديدة في منظومة ووردبريس خلال 2025، نحو 91% منها في الإضافات.
5. راجع حسابات المدراء في الموقع ولوحة الاستضافة: احذف الحسابات غير المستخدمة، وغيّر كلمات المرور، وفعّل التحقق بخطوتين حيث يتوفر.
6. تحقّق من آثار اختراق سابق: التحديث يغلق الباب لكنه لا يُخرج من دخل قبل إغلاقه. اطلب من المطوّر أو الاستضافة فحص الملفات الغريبة (خاصة ملفات PHP في مجلد الرفع uploads) ومراجعة السجلات.
7. اختبر الموقع بعد التحديث: صفحة الطلب، الدفع، نماذج التواصل، رسائل البريد. في المتجر جرّب طلباً كاملاً.

الأسئلة التي تسألها لمن يدير موقعك

انسخ هذه الأسئلة وأرسلها لمزوّد الاستضافة أو المطوّر أو الشركة التي بنت موقعك:

• ما إصدار PHP الذي يعمل عليه موقعي الآن؟ وهل يتضمّن إصلاح CVE-2026-109618 وCVE-2026-109619؟ ومتى طُبّق؟
• إن كان الإصدار خارج الدعم، ما خطة الترقية، ومن يختبر توافق الإضافات؟
• متى أُخذت آخر نسخة احتياطية؟ وأين تُحفظ؟ وهل جرّبتم استرجاعها؟
• هل فحصتم الخادم بحثاً عن أي ملفات أو حسابات غريبة بعد الإعلان عن الثغرة؟
• من المسؤول عن تحديث ووردبريس والإضافات بانتظام، وكم مرة؟

إن لم تحصل على إجابة واضحة خلال أيام، فهذه بحد ذاتها معلومة مهمة عن مستوى الرعاية التي يحصل عليها موقعك.

من المسؤول عن ماذا؟ الاستضافة أم المطوّر أم أنت

المهمة	الاستضافة المشتركة أو المُدارة	خادم خاص (VPS) تديره أنت أو مطوّرك	أنت صاحب الموقع
تحديث PHP على الخادم	المزوّد عادةً	أنت أو مطوّرك	تتأكد أنه حدث
اختيار فرع PHP المدعوم	غالباً أنت من لوحة التحكم	أنت أو مطوّرك	تقرّر الترقية
تحديث ووردبريس والإضافات والقوالب	ليس عادةً	المطوّر إن كان ضمن الاتفاق	مسؤوليتك ما لم يتولّها أحد كتابةً
النسخ الاحتياطية	أحياناً، راجع شروط الخدمة	أنت أو مطوّرك	تتأكد من وجودها وإمكانية استرجاعها
فحص آثار الاختراق	محدود عادةً	المطوّر	تطلبه وتتابعه

المشكلة الشائعة ليست أن أحداً أهمل، بل أن كل طرف يظن أن الآخر هو المسؤول. اكتب المسؤوليات صراحة في الاتفاق مع من يدير موقعك.

الدرس الأبقى: الموقع لا "ينتهي" عند الإطلاق

ثغرة PHP هذه ستُنسى بعد أشهر، لكن الدرس سيبقى: الموقع برنامج يعمل على برامج أخرى (نظام الخادم، PHP، قاعدة البيانات، ووردبريس، الإضافات)، وكلها تحتاج تحديثاً مستمراً. وتقرير Patchstack نفسه يذكر أن 46% من ثغرات منظومة ووردبريس لم يكن لها إصلاح جاهز وقت الإعلان عنها، ما يعني أن المتابعة المنتظمة وتقليل عدد الإضافات ليسا ترفاً.

عند تقدير ميزانية موقعك، احسب الصيانة السنوية مع تكلفة البناء، كما شرحنا في تكلفة انشاء موقع الكتروني في السعودية. وعند اختيار من يبني موقعك، اسأل عن الصيانة بعد الإطلاق قبل أن تسأل عن التصميم؛ وضعنا هذه الأسئلة في كيف تختار شركة تصميم مواقع.

أن يُبنى موقعك ويُستضاف ويُصان في مكان واحد

أحد الخيارات لتفادي سؤال "من المسؤول؟" أن تكون الجهة التي بنت الموقع هي نفسها التي تستضيفه وتصونه. هكذا يعمل Buildly: يصمّم موقعك أو متجرك ويبنيه ثم يستضيفه ويصونه ضمن اشتراك شهري، فالاستضافة والصيانة جزء من الاشتراك لا خدمة منفصلة تبحث عنها. تفاصيل ما تشمله الصيانة في صفحة الصيانة، وخيارات الخوادم في صفحة الاستضافة.

للمواقع التعريفية الصغيرة، باقة Essential بسعر إطلاق 35 دولاراً شهرياً (السعر المعتاد 60 دولاراً، ومن يشترك الآن يحتفظ بسعر 35 دولاراً طوال مدة اشتراكه)، مع رسوم تأسيس 100 دولار، والبناء الأول دون تكلفة إضافية، وطلبَي تعديل في السنة، وتصبح ملكية الكود وقاعدة البيانات لك بعد 12 شهراً. أما المتاجر والمواقع الأوسع فلها باقات أكبر، تجد أسعارها في صفحة الأسعار. التقدير مجاني: ترسل وصفاً لما تحتاجه عبر صفحة البدء، وتحصل على نطاق عمل مكتوب وسعر، وتوافق على كل مرحلة قبل الانتقال لما بعدها. ويُوصى بالتقنية المناسبة في نطاق العمل المكتوب، سواء كانت WordPress أو WooCommerce أو كوداً مخصّصاً.

وإن كنت تخطط لموقع جديد من الأساس، فابدأ بـخطوات إنشاء موقع إلكتروني تجاري لشركتك، ولا تنسَ أن موقعاً آمناً ومحدّثاً أساس لأي عمل على تحسين محركات البحث للمواقع العربية.

هذا المقال للتوعية العامة لأصحاب الأعمال. تفاصيل الإصدارات المصحّحة مأخوذة من إعلان PHP الرسمي حتى 3 نوفمبر 2026؛ راجع مزوّد الاستضافة لما ينطبق على خادمك تحديداً.