PHP2Shell: ما يجب على مواقع WordPress فعله الآن

في 21 أكتوبر 2026، أصدر مشروع PHP إصلاحًا طارئًا لثغرتين حرجتين في PHP نفسها. يسمّيهما باحثو الأمن PHP2Shell. تتيح الثغرتان معًا للمهاجم تشغيل شيفرته الخاصة على خادم الويب دون تسجيل الدخول، وقد بدأت الهجمات قبل صدور الإصلاح بساعات. تشغّل PHP معظم مواقع الويب، وتشغّل كل موقع WordPress.

إن كنت تملك موقع WordPress أو تديره، فأهم حقيقة هي تلك التي يخطئ فيها معظم الناس: تحديث WordPress لا يفيد هنا. الثغرة في طبقة PHP التي تقع تحت WordPress وإضافاته وقالبه. لا يصبح موقعك آمنًا إلا عندما يعمل الخادم الذي يستضيفه بنسخة PHP مُصلَحة. إليك ما حدث، وكيف تفحص موقعك في خمس دقائق، ورأيًا صريحًا في ما إذا كان هذا سببًا لمغادرة WordPress.

كل ما يلي يعكس المعلومات المتاحة حتى 23 أكتوبر 2026. الوضع ما زال يتطور، فتابع الإعلان الرسمي من PHP لمعرفة المستجدات.

ما هي PHP2Shell

PHP2Shell هو الاسم الشائع لثغرتين، CVE-2026-109618 وCVE-2026-109619. يصنّف فريق أمن PHP كلتيهما على أنهما حرجتان، بدرجة 9.2 من 10.

• CVE-2026-109618 تحدث عندما تنفد ذاكرة PHP في منتصف تجهيز الطلب. قد تتعامل خطوة التنظيف بعدها مع بيانات غير مكتملة على أنها صالحة.
• CVE-2026-109619 تسمح لبيانات داخلية من طلب ما بالبقاء بعد تحرير ذاكرتها، فيستخدم الطلب التالي الذي تعالجه العملية نفسها تلك البيانات القديمة.

ببساطة، يستطيع طلب مصمَّم بعناية أن يُفسد ذاكرة PHP ويسيطر على الخادم. لا حاجة إلى كلمة مرور ولا إلى إضافة ولا إلى صلاحيات مدير. تفيد Patchstack بأن باحثي Wiz أثبتوا إمكانية استغلال صفحة PHP من سطر واحد مثل «Hello World»، وأن كل نسخ PHP منذ 5.4 متأثرة بإحدى الثغرتين على الأقل. كل الطرق الشائعة لتشغيل PHP معنية: PHP-FPM وApache mod_php وCGI وLiteSpeed وFrankenPHP.

لماذا هذه الثغرة أخطر من المعتاد

ثلاثة أمور تميّز PHP2Shell عن ثغرات الإضافات التي اعتادها أصحاب مواقع WordPress.

إنها تقع تحت WordPress. لا تستطيع إضافات الأمان ولا جدران الحماية داخل WordPress ولا وضع الصيانة إيقافها، لأن الهجوم يقع قبل تحميل WordPress. أكّد WordPress.org أنه «لا يلزم أي تحديث لـ WordPress ولا يُخطَّط له». يجب أن يأتي الإصلاح ممن يدير خادمك.

كان المهاجمون متقدمين بخطوة. أعلنت PHP في 20 أكتوبر عن الإصدار في اليوم التالي الساعة 14:00 بالتوقيت العالمي. تسرّبت التفاصيل قبل ذلك. أبلغت Cloudflare عن هجمات مبكرة الساعة 07:43 بالتوقيت العالمي يوم 21 أكتوبر، أي قبل صدور الإصلاح بنحو ست ساعات، ثم أفاد رئيسها التنفيذي بمئات الآلاف من محاولات الاستغلال خلال ساعتين من الإعلان وبالملايين في اليوم التالي.

نسخ PHP القديمة لا تحصل على إصلاح رسمي. لا يُصدر مشروع PHP نسخًا جديدة إلا للفروع المدعومة: 8.2 و8.3 و8.4 و8.5. أما ما هو أقدم فيعتمد على مزوّد الاستضافة أو توزيعة Linux أو مزوّد دعم مدفوع ينقل الإصلاح إلى النسخة القديمة.

وهنا يكمن انكشاف WordPress. وفق إحصاءات الاستخدام الخاصة بـ WordPress.org، يعمل 34.7% من مواقع WordPress على PHP 8.1 أو أقدم، وهي نسخ لا تحصل على أي إصدار رسمي. ويعمل 23.5% آخرون على PHP 8.2، المُصلَحة اليوم لكنها تنتهي فترة دعمها في 31 ديسمبر 2026. أي أن قرابة ستة من كل عشرة مواقع WordPress تعمل على نسخة PHP غير مدعومة الآن، أو لن تكون مدعومة خلال عشرة أسابيع.

افحص موقعك في خمس دقائق

لا تحتاج إلى خبرة تقنية. تحتاج فقط إلى معرفة نسخة PHP لديك ومن المسؤول عن تحديثها.

1. اعرف نسخة PHP لديك. في لوحة تحكم WordPress، اذهب إلى أدوات، ثم صحة الموقع، ثم معلومات، وافتح قسم الخادم. ستجد نسخة PHP هناك.
2. قارنها بالنسخ المُصلَحة. موقعك محمي إن كنت تستخدم PHP 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35، أو أي نسخة أحدث.
3. اسأل مزوّد الاستضافة قبل أن تقلق. بعض المزوّدين ينقلون الإصلاح دون تغيير رقم النسخة، لذا قد يظهر رقم أقدم على خادم مُصلَح. راسل مزوّد الاستضافة واطرح سؤالًا واحدًا: «هل PHP على خادمي مُصلَحة من CVE-2026-109618 وCVE-2026-109619؟» واحصل على الإجابة كتابيًا.
4. إن كنت على PHP 8.1 أو أقدم، خطّط للترقية الآن. حتى لو نقل مزوّدك هذا الإصلاح، فإن نسختك لم تعد تحصل على الإصلاحات بشكل منتظم. قد تؤدي الترقية إلى PHP 8.3 أو 8.4 إلى تعطّل إضافات وقوالب قديمة، فاختبرها أولًا على نسخة تجريبية من الموقع.
5. إن كنت تدير خادمك بنفسك ولا تستطيع التحديث اليوم، تذكر PHP وPatchstack إجراءات مؤقتة، مثل ضبط session.upload_progress.enabled=0 ثم إعادة تشغيل PHP. لا يستخدم WordPress هذه الخاصية، لذا لا ينبغي أن يؤثر إيقافها على موقع عادي. وفي 23 أكتوبر، أوصت PHP بالإعداد نفسه لمواجهة مسار هجوم ثالث أقل احتمالًا ستُصلحه في إصدارها المنتظم التالي. هذه الإعدادات تقلّل الخطر. لكنها لا تُغني عن التحديث.

تحذيران. لا تثبّت إضافات تدّعي «إصلاح PHP2Shell» ولا تلصق شيفرات من المنتديات: لا تستطيع أي إضافة تغيير PHP على خادمك، والإصلاحات المزيّفة وسيلة معروفة لزرع البرمجيات الخبيثة وقت الأزمات. وإن كنت تستخدم UpdraftCentral لإدارة عدة مواقع، فإن Patchstack تفيد بشكل منفصل بأن مفاتيح UpdraftCentral مسروقة تُستخدم لزرع أبواب خلفية في مواقع WordPress، فاحذف تلك المفاتيح وأنشئ مفاتيح جديدة.

علامات استهداف موقعك

تذكر Patchstack بعض الإشارات التي تستحق الفحص في سجلات الخادم. لا تُعد أيّ منها دليلًا قاطعًا في أي اتجاه.

• طلبات multipart غير معتادة تليها أخطاء حدّ الذاكرة أو أخطاء 500 متكررة
• ملفات تعريف ارتباط PHPSESSID كبيرة الحجم أو مشوّهة على نحو غير متوقع
• عمليات PHP تُعاد تشغيلها دون تفسير

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

الدرس الحقيقي: من يتولى تحديث منظومتك التقنية؟

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

لهذا أُصلحت بعض المواقع خلال ساعات هذا الأسبوع وما زالت مواقع أخرى مكشوفة. نادرًا ما كان الفرق في البرمجيات. كان الفرق في وجود شخص مسؤول.

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

هل عليك مغادرة WordPress بسبب هذا؟

ليس تلقائيًا. إن أصلح مزوّد الاستضافة خادمك خلال يوم، وكانت نسخة PHP لديك حديثة، وهناك من يتولى التحديثات، فإن PHP2Shell أسبوع سيئ وليست سببًا لإعادة البناء.

يستحق الانتقال التفكير إن بدا لك أحد هذه المواقف مألوفًا:

• تعمل على PHP 8.1 أو أقدم والترقية ستعطّل إضافات لم يعد أحد يطوّرها.
• لا أحد مسؤول عن المنظومة. عرفت بـ PHP2Shell من الأخبار، لا من مزوّد الاستضافة أو المطوّر.
• موقعك في معظمه صفحات تسويقية ومدونة. تدفع تكلفة صيانة خادم تطبيقات كامل لمحتوى لا يحتاج إليه.
• كنت تخطط أصلًا لإعادة تصميم. إعادة البناء على منصة أسهل صيانة تكلف تقريبًا المبلغ نفسه، وتتوقف عن وراثة مخاطر المنظومة القديمة.

طريقان لترك PHP خلفك، ونستطيع نقلك إلى أيّ منهما

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

الخيار الأول: الانتقال إلى Webflow

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

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

نحن متخصصون في Webflow. اطّلع على تطوير Webflow لدى Carril لتعرف كيف نبني.

الخيار الثاني: موقع مبرمج بالكامل على Cloudflare

الطريق الثاني موقع مبرمج حسب الطلب، مبني بإطار عمل حديث مثل Astro أو Next.js ومنشور على شبكة Cloudflare العالمية. تُبنى الصفحات مسبقًا وتُقدَّم من مراكز بيانات قريبة من كل زائر، وتعمل الأجزاء الديناميكية القليلة، مثل النماذج أو البحث، كدوال صغيرة على منصة Cloudflare نفسها. لا PHP ولا خادم ويب ولا نظام تشغيل تحتاج إلى تحديثه. تتولى Cloudflare صيانة المنصة من تحتها.

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

هكذا بُني موقعنا نفسه. عندما ظهرت PHP2Shell، لم يكن في موقعنا ما يحتاج إلى إصلاح. اطّلع على تطوير المواقع لدى Carril للطريق المبرمج حسب الطلب.

كيف نتولى عملية النقل عنك

في مرحلة النقل تخسر معظم المواقع زياراتها، لذا نقود العملية كاملة بصفتنا شريكك في القيادة Co-Driver:

1. استشارة مجانية. نراجع موقعك ونسخة PHP وإضافاتك وأهدافك، ونوصي بـ Webflow أو Cloudflare. وإن كان البقاء على WordPress مع PHP مُصلَحة هو القرار الصحيح، فسنقول لك ذلك.
2. خطة لكل رابط. كل صفحة يتغير عنوانها تحصل على تحويل 301، لتحافظ على الترتيب والزيارات التي كسبها الموقع القديم. يمكنك معاينة ذلك بنفسك عبر مخطط نقل المواقع المجاني: أدخل موقعك، واختر Webflow أو Astro أو Next.js، فيعرض كل رابط ويبني ملف التحويلات.
3. التصميم والبناء والمحتوى. نعيد بناء الموقع، وننقل صفحاتك ومقالاتك وصورك وإعدادات SEO، ونعيد ربط النماذج والتحليلات وأدوات التتبع.
4. إطلاق آمن. نختبر كل تحويل، ونرسل خريطة الموقع الجديدة إلى Google وBing، ونراقب أخطاء 404 والترتيب في الأسابيع التالية للإطلاق.

يحصل المؤسسون على فريق واحد لعملية النقل كلها، دون الحاجة إلى مطوّر داخلي. ويحصل مديرو التسويق على شريك متمرّس يعمل جنبًا إلى جنب مع فريقهم ويتولى الجدول الزمني. احجز استشارة مجانية وسنخبرك بالطريق الذي يناسب موقعك.

لمزيد من التفاصيل، اقرأ دليل النقل من WordPress إلى Webflow ومقارنة Webflow وWordPress.

الجدول الزمني لـ PHP2Shell

• 20 أكتوبر 2026. تعلن PHP عن إصدار أمني حرج في اليوم التالي الساعة 14:00 بالتوقيت العالمي. تتسرّب تفاصيل الثغرتين.
• 21 أكتوبر، صباحًا. يبلغ شركاء استضافة Patchstack عن استغلال فعلي، وترصد Cloudflare هجمات مبكرة الساعة 07:43 بالتوقيت العالمي.
• 21 أكتوبر، بعد الظهر. تُصدر PHP النسخ 8.5.12 و8.4.27 و8.3.36 و8.2.35 مع إصلاح الثغرتين. يبدأ مزوّدو الاستضافة بنشر الإصلاحات.
• 23 أكتوبر. تنشر PHP إشعارًا إعلاميًا توصي فيه بضبط session.upload_progress.enabled=0 حتى إصدارها المنتظم التالي.
• 31 ديسمبر 2026. تنتهي فترة دعم PHP 8.2 وتتوقف إصلاحاتها الأمنية.

الخلاصة

PHP2Shell ثغرة في PHP وليست في WordPress، لذا فالحل نسخة PHP مُصلَحة على خادمك، لا تحديث لـ WordPress. افحص نسختك اليوم، واطلب من مزوّد الاستضافة تأكيد الإصلاح كتابيًا، وخطّط للترقية إن كنت على PHP 8.1 أو أقدم. ثم اطرح السؤال الأكبر: من المسؤول عن منظومتك التقنية، وهل هو أنت؟

وإن كنت تفضّل التوقف عن تحديث الخوادم نهائيًا، فانتقل إلى Webflow أو إلى موقع مبرمج بالكامل على Cloudflare، ونستطيع تولي عملية النقل عنك، من خطة الروابط حتى الإطلاق. احجز استشارة مجانية. سنفحص وضع موقعك ونخبرك بصراحة إن كان يحتاج إلى إصلاح أم إلى بداية جديدة. شريكك في القيادة Co-Driver على الويب.

الأسئلة الشائعة

هل يُصلح تحديث WordPress ثغرة PHP2Shell؟ لا. الثغرة في PHP، اللغة التي يعمل عليها WordPress. أعلن WordPress.org أنه لا يُخطَّط لأي تحديث لـ WordPress بشأنها. وحدها نسخة PHP مُصلَحة على خادمك تعالجها.

ما نسخ PHP الآمنة؟ PHP 8.5.12 و8.4.27 و8.3.36 و8.2.35 وما بعدها. النسخ الأقدم آمنة فقط إن نقل مزوّد الاستضافة أو توزيعة Linux الإصلاح إليها، فاطلب منهم التأكيد.

هل تحمي إضافة أمان موقعي؟ لا. يقع الهجوم قبل تحميل WordPress وإضافاته. قد يحجب جدار حماية أمام الخادم، مثل Cloudflare، بعض أنماط الهجوم المعروفة، لكنه لا يُغني عن تحديث PHP.

هل مواقع Webflow وFramer متأثرة؟ لا يعمل موقعك على هذه المنصات بنسخة PHP تديرها أنت، فلا يوجد ما تحتاج إلى إصلاحه. كل منصة مسؤولة عن تحديث بنيتها التحتية.

هل تستطيع Carril نقل موقع WordPress الخاص بي إلى Webflow أو Cloudflare؟ نعم. نخطط لكل تحويل، ونعيد بناء الموقع على Webflow أو كموقع مبرمج بالكامل على Cloudflare، وننقل المحتوى وإعدادات SEO، ونتولى الإطلاق. ويبدأ كل ذلك باستشارة مجانية.

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