هل تأثر موقعك الإلكتروني بثغرة PHP2Shell؟ فحص في 5 دقائق لأصحاب الأعمال في الإمارات

في 21 أكتوبر 2026، أصدر مشروع PHP تصحيحات طارئة لثغرتين أمنيتين خطيرتين أُطلق عليهما اسم PHP2Shell (CVE-2026-109618 و CVE-2026-109619، حصل كل منهما على تصنيف 9.2 وفقًا لنظام CVSS v4.0) تتيح للمهاجم تشغيل تعليمات برمجية على خادم الويب دون الحاجة إلى تسجيل الدخول، بغض النظر عن نظام إدارة المحتوى (CMS) أو المكونات الإضافية التي يستخدمها الموقع. تؤثر هذه الثغرات الأمنية على كل من WordPress وDrupal وJoomla وتطبيقات PHP المخصصة على حد سواء. وفي غضون ساعات، دخلت خدمات الويب الحكومية في جميع أنحاء أوروبا وأمريكا الشمالية، والمنصات الكبرى بما في ذلك إنترنت أرشيف وديفيانت آرت، ومجموعة من مواقع الشركات في وضع الصيانة لتصحيح الثغرة قبل أن يتمكن المهاجمون من استغلالها.

حجم هذه المشكلة غير عادي. فكل إصدارات PHP التي صدرت خلال العقد الماضي متأثرة بواحد على الأقل من هذين الخللين، منذ إصدار PHP 5.4 فصاعدًا، وفقًا لشركة الأمن Wiz. وتكمن نقاط الضعف هذه في طريقة معالجة الذاكرة في PHP، وليس في WordPress أو أي مكون إضافي، لذا فإن تحديث WordPress أو المكونات الإضافية وحده لا يجدي نفعًا. يجب على مزود الاستضافة أو مسؤول الخادم تحديث لغة PHP نفسها وإعادة تشغيل خادم الويب. ولهذا السبب قامت العديد من المؤسسات، اتباعًا لإرشادات كل من CISA والمركز الوطني للأمن السيبراني في المملكة المتحدة (NCSC) وCERT-EU والمكتب الألماني للسلامة المعلوماتية (BSI)، بإيقاف مواقعها مؤقتًا حتى تتمكن من التأكد من نشر التصحيح. تعمل نسبة كبيرة من مواقع الويب التجارية في الإمارات العربية المتحدة على WordPress واستضافة PHP المشتركة، لذا فإن هذا الأمر مهم على الصعيد المحلي على الرغم من عدم صدور أي بيان خاص بالإمارات حتى الآن. إذا كان موقعك مبنيًا على مجموعة JavaScript حديثة مثل Next.js (التي تستخدمها The Digital Agency في مشاريع العملاء)، فإنه لا يعمل بـ PHP ولن يتأثر بهذه الثغرات.

ما أعلنه مشروع PHP

أصدر مشروع PHP إصدارات مصححة في 21 أكتوبر 2026: PHP 8.5.12 و8.4.27 و8.3.36 و8.2.35. وكانت التفاصيل قد تسربت قبل ذلك بيوم واحد، وصدرت تنبيهات الأمان على GitHub في حوالي الساعة 13:34 بالتوقيت العالمي المنسق (UTC) يوم 21 أكتوبر. انتهت مدة دعم PHP 8.1 والإصدارات الأقدم، مما يعني عدم وجود إصدارات رسمية، على الرغم من توفر تصحيحات المصدر لـ PHP 7.4 و8.0 و8.1. يجب على مستخدمي هذه الإصدارات مراجعة مزود نظام التشغيل الخاص بهم أو الترقية إلى إصدار مدعوم.

تؤثر هاتان الثغرتان على خدمات PHP التي تعالج طلبات الويب: فكل من PHP-FPM وApache mod_php وphp-cgi وFrankenPHP وLiteSpeed معرضة للخطر. ونظرًا لأن هذه الثغرات تسمح بتنفيذ تعليمات برمجية عن بُعد دون مصادقة، يمكن للمهاجم الاستيلاء على الخادم دون الحاجة إلى أي بيانات اعتماد. اكتشف باحثون في شركتي Calif وWiz هذه الثغرات الأمنية في أغسطس 2026 باستخدام نماذج الذكاء الاصطناعي، وتقول Wiz إنها تأكدت من إمكانية الاستيلاء دون مصادقة على أحدث إصدارات WordPress وDrupal وJoomla خلال الاختبارات المعملية.

سجلت شبكة MadPot التابعة لشركة أمازون محاولة استغلال أمني في 17 أكتوبر 2026، أي قبل أربعة أيام من الإعلان عن الخلل للجمهور، مما يعني أن المهاجمين كان لديهم إمكانية الوصول إلى ثغرات فعالة قبل الإعلان عن التصحيح. ونصحت أمازون المؤسسات بالتحقق من وجود أي أنشطة مشبوهة تعود إلى 17 أكتوبر على الأقل.

كيف جرت الهجمات وما هي وسائل الحماية المتاحة

قامت Cloudflare بتفعيل الحماية المجانية بجدار الحماية (WAF) لجميع الباقات، بما في ذلك الحسابات المجانية، في الساعة 03:02 بالتوقيت العالمي المنسق (UTC) يوم 21 أكتوبر، أي قبل حوالي تسع ساعات من الإعلان عن الخرق. أفاد ماثيو برينس، الرئيس التنفيذي لشركة Cloudflare، بوقوع آلاف محاولات الاستغلال خلال الساعات العشر التي سبقت الإعلان العام، وعشرات الآلاف خلال 45 دقيقة بعد الإعلان، ومئات الآلاف خلال ساعتين، وملايين المحاولات بحلول اليوم التالي. قام المهاجمون بتكييف حمولاتهم في محاولة لتجاوز جدار الحماية. هذه محاولات مسجلة، وليست اختراقات ناجحة مؤكدة. وأكدت Cloudflare أن قواعد جدار الحماية الخاص بها تمثل طبقة أمان إضافية، وليست بديلاً عن تثبيت التصحيحات.

أصدرت وكالة الأمن السيبراني والبنية التحتية (CISA) تنبيهًا في 21 أكتوبر تطلب فيه من المؤسسات تثبيت التصحيحات على الفور، بدءًا من الأنظمة المتصلة بالإنترنت. وإذا تعذر تثبيت التصحيحات، أو إذا كان الموقع يعمل بنظام PHP 8.1 أو أقدم، فقد نصحت الوكالة بفصل أنظمة PHP عن الإنترنت حتى يتم تثبيت التصحيحات. ورددت وكالات الأمن السيبراني الوطنية الأخرى نفس التوجيهات. ونتيجة لذلك، تم إيقاف خدمات الويب الحكومية في فنلندا، وهولندا (Overheid.nl)، وفرنسا (مواقع وزارة الداخلية)، والدنمارك (منصة مدرسية وطنية)، وكندا، أو دخلت في مرحلة الصيانة، إلى جانب خدمات دعم ويكيميديا، وأرشيف الإنترنت، وDeviantArt، والعديد من ألعاب الهواتف المحمولة الكبيرة في اليابان. ولا تعني صفحة الصيانة بحد ذاتها أن الموقع قد تعرض للاختراق، بل تعني فقط أن المؤسسة اتبعت التوصيات الرسمية.

ماذا يعني ذلك للشركات في الإمارات العربية المتحدة

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

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

بالإضافة إلى تثبيت التصحيحات، تحقق من وجود أي علامات على الاختراق تعود إلى 17 أكتوبر 2026. ابحث عن مستخدمين إداريين مجهولين في WordPress أو نظام إدارة المحتوى (CMS) الخاص بك، أو ملفات جديدة أو تم تغييرها في جذر الموقع، أو عمليات إعادة توجيه غير متوقعة، أو صفحات غير مرغوب فيها مفهرسة من قبل Google، أو عمليات PHP التي تطلق شل أو تنزل أدوات. إذا كنت تستخدم Cloudflare أو جدار حماية آخر لتطبيقات الويب، فاحرص على إبقائه مفعلًا كطبقة حماية إضافية، ولكن لا تعتمد عليه كبديل للتحديث. بالنسبة للشركات التي تدرس التخلي عن مجموعات PHP القديمة، يمكن لفريق تصميم المواقع لدينا مساعدتك في تقييم البدائل الحديثة التي تقضي على هذه الفئة من المخاطر بالكامل.

الفحص في 5 دقائق

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

إذا كان موقعك يعمل بنظام PHP 8.1 أو إصدار أقدم، فأنت تستخدم إصدارًا غير مدعوم. لا توجد إصدارات رسمية لـ 8.1 أو 8.0 أو 7.4 أو أي إصدار أقدم من ذلك. يقوم بعض مزودي أنظمة التشغيل بتطبيق تصحيحات الأمان على الإصدارات القديمة، لذا اسأل مزودك عما إذا كان توزيع نظام التشغيل الخاص بك قد أصدر تصحيحًا أم لا. إذا لم يكن الأمر كذلك، فخطط للترقية إلى PHP 8.2 أو إصدار أحدث كمشروع عاجل. اختبر موقعك على الإصدار الجديد في بيئة تجريبية أولاً، لأن PHP 8.2 أدخل تغييرات جذرية قد تؤثر على الكود القديم.

راجع سجلات الخادم والتطبيقات الخاصة بك للفترة بدءًا من 17 أكتوبر فصاعدًا. ابحث عن طلبات POST غير عادية، أو أخطاء PHP غير متوقعة، أو ملفات جديدة في /tmp أو جذر الموقع، أو تغييرات في ملفات نظام إدارة المحتوى (CMS) الأساسية، أو حسابات إدارية جديدة، أو عمليات تم إنشاؤها بواسطة مستخدم خادم الويب. إذا وجدت أي شيء مريب، تعامل معه على أنه اختراق محتمل واستعن بأخصائي في التحقيق الجنائي. قم بتغيير جميع كلمات مرور المسؤولين ومفاتيح واجهة برمجة التطبيقات (API) كإجراء احترازي.

وأخيرًا، إذا لم يكن لديك جدار حماية لتطبيقات الويب (WAF)، فقم بإعداده الآن. توفر Cloudflare باقة مجانية توفر الحماية الأساسية من WAF. احرص على إبقائه قيد التشغيل حتى بعد تثبيت التصحيحات، لأن الثغرة الأمنية التالية هي مسألة متى، وليس إذا.

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