PHP2Shell هو الاسم الذي أطلقه الوسط الأمني على ثغرتين حرجتين في لغة PHP، تحملان الرمزين CVE-2026-109618 وCVE-2026-109619. تسمح الثغرتان لمهاجم بتنفيذ تعليمات برمجية على الخادم عن بُعد ومن دون تسجيل دخول. أصدر فريق PHP إصلاحاتهما يوم الأربعاء 21 أكتوبر 2026 في الإصدارات 8.5.12 و8.4.27 و8.3.36 و8.2.35، والتحديث الفوري هو الحماية الوحيدة المضمونة.
حتى صباح اليوم الخميس 22 أكتوبر 2026، كانت بوابة Overheid.nl الحكومية الهولندية متوقفة، ومعها كل الخدمات الحكومية العامة على الويب في فنلندا، وجميع مواقع وزارة الداخلية الفرنسية. ولم يقع اختراق معلن في أيٍّ من هذه الحالات، فقد اتخذت الحكومات القرار احتياطاً بعدما دعت وكالات أمنية كبرى إلى إيقاف كل خادم يتعذر تحديثه فوراً.
سبب هذا القلق أن نحو 69% من مواقع الويب تعمل بلغة PHP. ويتوقف الخطر الفعلي على إعدادات كل خادم وإصدار PHP المثبّت عليه. نشرح فيما يلي طبيعة الثغرتين، والجهات المعرضة لهما، وكيف خرجت تفاصيلهما قبل الموعد المحدد، وما يمكن أن يفعله صاحب أي موقع اليوم.
ما هي ثغرات PHP2Shell ولماذا تُصنَّف حرجة؟
الثغرتان خللان في طريقة إدارة PHP للذاكرة، وكلاهما يسمح بتنفيذ كود عن بُعد دون مصادقة. منح فريق PHP كلاً منهما درجة 9.2 من 10 وفق معيار CVSS v4.0، وقيّمتهما شركة watchTowr الأمنية بالدرجة الكاملة 10.0.
تظهر الثغرة الأولى (CVE-2026-109618) حين يبلغ طلبٌ ما الحد الأقصى للذاكرة المسموح به في إعداد memory_limit، إذ تخطئ اللغة في التعامل مع نفاد الذاكرة في هذه الحالة. وأخطر ما فيها أن استغلالها ثبت دون مصادقة على خوادم Apache التي تعمل مع وحدة mod_php، وبالإعدادات الافتراضية، وقبل أن يعمل أي سطر من كود التطبيق. معنى ذلك أن جودة برمجة الموقع لا تحميه، لأن الخلل يقع في طبقة أدنى من التطبيق.
الثغرة الثانية (CVE-2026-109619) من نوع use-after-free. بعد وقوع خطأ فادح، تبقى في PHP حالة داخلية تشير إلى ذاكرة تخص طلباً سابقاً، ويستطيع المهاجم استغلال هذه الإشارة. وقد أثبت الباحثون أنها قابلة للاستغلال لتنفيذ كود عن بُعد ضد تطبيق حقيقي يعمل على Apache مع mod_php، وهذا يجعلها خطراً عملياً مثبتاً.
يُعرف هذا النوع من الثغرات في الأوساط الأمنية بأنه الأخطر، لأن من يستغله يحصل على قدرة تشغيل أوامر على الخادم نفسه. من هناك يمكنه سرقة قواعد البيانات، أو زرع أبواب خلفية، أو استخدام الخادم منصةً لهجمات أخرى.
من المتأثر بالثغرتين؟ وهل موقعك في دائرة الخطر؟
الإجابة المختصرة: كل تثبيت PHP يخدم طلبات ويب ولم يُحدَّث إلى الإصدارات الجديدة. يشمل ذلك PHP-FPM، وApache مع mod_php، وphp-cgi، وFrankenPHP، وLiteSpeed، والخطر الأعلى في بيئات mod_php.
تقول شركة Wiz إن كل إصدارات PHP منذ الإصدار 5.4 متأثرة بثغرة واحدة من الاثنتين على الأقل، وإن الخلل موجود في الكود منذ عقود. وتضيف الشركة أن نماذج الذكاء الاصطناعي المتقدمة سهّلت كثيراً تحويل الثغرتين من خلل نظري إلى استغلال فعلي. ومن هنا جاءت سرعة الأحداث في الأيام الأخيرة.
يزيد عمر الإصدارات المثبّتة الأمر تعقيداً. الإصدارات 8.1 وما قبلها خرجت من الدعم الرسمي، ولذلك اكتفى فريق PHP بنشر رقع على مستوى الكود المصدري للإصدارات 7.4 و8.0 و8.1، من دون ملفات تنفيذية جاهزة. وعلى من يشغّل هذه الإصدارات أن يبني PHP من المصدر بنفسه أو أن ينتقل إلى إصدار مدعوم، وكلا الخيارين يحتاج إلى خبرة ووقت لا يتوفران لكثير من أصحاب المواقع الصغيرة.
ولمستخدمي ووردبريس تنبيه خاص. تشغّل هذه المنصة أكثر من 40% من مواقع الإنترنت، لكن تحديثاتها التلقائية لا تعالج الثغرتين، لأن الخلل في PHP المثبتة على الخادم. فالموقع الذي يعرض «كل شيء محدَّث» في لوحة التحكم قد يظل مكشوفاً تماماً. وقدّر أحد الباحثين أن أكثر من 1.3 مليون خادم متصل بالإنترنت قد يكون معرضاً للثغرتين، ونقلت صحيفة وول ستريت جورنال أن الخلل يعرّض ما يصل إلى 70% من مواقع العالم للخطر.
كيف تسربت الثغرتان قبل موعد الإصلاح؟
بدأ التسريب يوم الثلاثاء 20 أكتوبر 2026 نحو الساعة 15:00 بتوقيت غرينتش. انتشر رقما الثغرتين على المنتديات ومواقع التواصل مع موعد إصدار ودرجة خطورة غير صحيحين، فقدّم فريق PHP موعد الإصدار من 22 إلى 21 أكتوبر.
في مساء اليوم نفسه، نشرت شركة Calif بالخطأ مقطع فيديو يعرض إثبات المفهوم (PoC) يعمل ضد عدة أهداف. وفي صباح الأربعاء 21 أكتوبر، عند الساعة 07:41 بتوقيت غرينتش، كسرت شركة Chainguard الحظر المتفق عليه ونشرت صوراً برمجية تتضمن الإصلاح، قبل الموعد المنسق بأكثر من ست ساعات. وصدرت التحديثات الرسمية في الساعة 14:00 من اليوم نفسه.
تعود القصة إلى ما قبل ذلك بكثير. ففي عام 2024 أجرت شركة Quarkslab تدقيقاً أمنياً للغة PHP بتمويل من وكالة Sovereign Tech Agency، ومن هذا التدقيق بدأ اكتشاف الخلل. لكن الإصلاح تعثّر لأن أعضاء الفريق اختلفوا على طريقة المعالجة، ووصفت مؤسسة PHP ما جرى بأنه «فشل هيكلي». بقيت المشكلة معلّقة إلى أن أبلغ الباحث Ryan A من شركة Calif، ضمن برنامج «Patch the Planet»، عن ثغرة تنفيذ كود غير مشروط في 11 أغسطس 2026. وأبلغت OpenAI عنها في اليوم نفسه، ثم أبلغت Wiz في 24 أغسطس.
يبيّن هذا التسلسل الزمني أن أكثر من جهة بحثية وصلت إلى الخلل نفسه خلال أسبوعين، وكثير منها يستخدم أدوات ذكاء اصطناعي. والأرجح أن جهات غير معلنة وصلت إليه أيضاً. وكلما زاد عدد من يعرفون بالثغرة صار الحفاظ على سريتها حتى موعد الإصلاح أصعب، وهذا ما حدث هذا الأسبوع.
We were all supposed to wait until Thursday at 11am ET. Information has leaked wrt zero-day embargoed RCE vulns in PHP. We can confirm that they're real. CVE-2926-109618/619We cannot share further information right now. Take this seriously and apply patches when available. pic.twitter.com/kguM8fpq13شوف المنشور على X
لماذا أوقفت حكومات حول العالم مواقعها؟
أوقفت الحكومات مواقعها احترازياً لأن الوكالات الأمنية الكبرى نصحت بذلك صراحة. وقالت وكالة الأمن السيبراني الأمريكية CISA في تنبيهها يوم 21 أكتوبر 2026 إن أي نظام لا يمكن تحديثه فوراً، أو يعمل بالإصدار 8.1 أو أقدم، يجب إيقافه حتى يُحدَّث.
صدرت نصائح مماثلة عن جهات أخرى. نصحت وكالة الأمن القومي الأمريكية NSA بفصل الأنظمة عن الشبكة مؤقتاً إذا تعذر التحديث، وحذّر المركز الوطني للأمن السيبراني البريطاني NCSC وفريق CERT-EU الأوروبي من ترك التطبيقات غير المحدَّثة تعمل، ودعوا إلى عزلها أو إيقافها.
في أوروبا جاءت الاستجابة سريعة. أوقفت هولندا بوابة Overheid.nl، وأوقفت فنلندا كل خدماتها الحكومية العامة على الويب، وأوقفت فرنسا جميع مواقع وزارة الداخلية، وأوقفت الدنمارك منصة التواصل المدرسي الوطنية. وفي بلجيكا أوقفت وزارة الخارجية مواقعها مؤقتاً، وفي ألمانيا أوقفت هيئة ITZBund عدداً من المواقع الاتحادية دون تسجيل أي حادث. وفي اليابان دعت رئيسة الوزراء ساناي تاكايتشي المؤسسات إلى التحقق من اعتماد مواقعها على PHP.
وفي العالم العربي، أصدرت المديرية العامة لأمن نظم المعلومات المغربية DGSSI، عبر مركز maCERT، نشرة تحذيرية برقم 69782110/26 بتاريخ 21 أكتوبر 2026، صنّفت فيها الثغرتين في مستوى «حرج» ونبّهت إلى توفر إثبات مفهوم للاستغلال. وخارج القطاع الحكومي، أوقفت مؤسسة ويكيميديا عدداً من خدماتها المساندة احترازياً، ومنها Phabricator، وتوقف موقعا 4chan وSomething Awful.
هل بدأ استغلال الثغرتين فعلاً؟
لا تتفق المصادر حتى الآن على الإجابة. قالت CISA إنها لم ترصد أي استغلال حتى وقت نشر تنبيهها، وتحدثت شركات أمنية أخرى عن نشاط هجومي، لكن رواياتها لا تتطابق.
اتخذت Cloudflare إجراءً عملياً بغض النظر عن هذا الخلاف، فنشرت قواعد مؤقتة في جدار حماية تطبيقات الويب ضد الثغرتين، وجعلتها متاحة حتى لمستخدمي الخطة المجانية. وتفيد هذه القواعد كخط دفاع إضافي، لكنها لا تُغني عن تحديث PHP نفسها.
وقبل صدور الإصلاحات، توقّع باحثو شركة Sansec أن تبدأ الهجمات الواسعة خلال 15 دقيقة من نشرها. والمنطق وراء ذلك معروف: المهاجمون يقارنون الكود قبل الإصلاح وبعده ليعرفوا موضع الخلل بالضبط، وفي هذه الحالة كان إثبات المفهوم منشوراً أصلاً.
وظهر تهديد مرتبط بالأزمة في منظومة ووردبريس. ذكرت شركة Patchstack أن مهاجماً يستخدم مفاتيح UpdraftCentral صالحة لزرع أبواب خلفية في مواقع ووردبريس المرتبطة بهذه الأداة، ونصحت بحذف تلك المفاتيح. أما على المدى البعيد، فيتوقع الباحث الأمني كيفن بومونت موجة واسعة من الحوادث، ويرى خبير التحقيق الجنائي الرقمي هال بوميرانز أن الخطر سيبقى سنوات بسبب تثبيتات PHP المدمجة في أجهزة ومنتجات وغير مُدارة، ولن يحدّثها أحد.
كيف تحمي موقعك أو خادمك الآن؟
الحماية الأساسية هي تحديث PHP على الخادم إلى أحد الإصدارات 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35، بحسب فرع الإصدار الذي تستخدمه. وإن لم تستطع التحديث فوراً، فاتبع توصية CISA وأوقف الخدمة إلى أن تحدّثها.
ابدأ بمعرفة الإصدار الذي يعمل على خادمك. يمكنك ذلك من لوحة تحكم الاستضافة، أو بالأمر php -v إذا كان لديك وصول إلى سطر الأوامر. وانتبه إلى أن الخادم قد يشغّل أكثر من إصدار في الوقت نفسه، فبعض الاستضافات تخصص إصداراً مختلفاً لكل موقع.
إذا كنت تستخدم استضافة مشتركة، فراسل الدعم الفني اليوم واسألهم سؤالاً محدداً: هل حُدّثت PHP إلى الإصدارات الصادرة في 21 أكتوبر؟ لا تكتفِ بتحديث ووردبريس أو الإضافات. وإذا كان موقعك يعمل على 8.1 أو أقدم، فهذا هو الوقت المناسب للانتقال إلى إصدار مدعوم، حتى لو اضطررت إلى إصلاح بعض التوافق في الكود.
بعد التحديث بقيت خطوات أخرى. احذف مفاتيح UpdraftCentral إن كنت تستخدمها كما نصحت Patchstack، وفعّل قواعد جدار الحماية المؤقتة لدى Cloudflare إذا كان موقعك يمر عبرها. وراجع سجلات الخادم بحثاً عن ملفات جديدة غير مألوفة أو حسابات إدارية لم تنشئها، لأن التحديث يغلق الثغرة لكنه لا يزيل بابًا خلفياً زُرع قبله. ولا تنسَ الأجهزة والأنظمة الداخلية التي قد تحتوي على PHP دون أن تعرف، مثل لوحات إدارة الأجهزة أو التطبيقات القديمة على الشبكة الداخلية.
أهم النقاط
- PHP2Shell اسم يجمع ثغرتين، CVE-2026-109618 وCVE-2026-109619، وكلتاهما تسمح بتنفيذ كود عن بُعد بلا تسجيل دخول.
- صدرت الإصلاحات يوم الأربعاء 21 أكتوبر 2026 الساعة 14:00 غرينتش: 8.5.12 و8.4.27 و8.3.36 و8.2.35.
- تحديثات ووردبريس التلقائية لا تحمي منهما، والحل تحديث PHP على الخادم.
- الإصدارات 8.1 وما قبلها لم تحصل إلا على رقع في الكود المصدري، ولا توجد لها ملفات تنفيذية جاهزة.
- بيئات Apache مع mod_php أشد خطراً، لأن الاستغلال ممكن فيها بالإعدادات الافتراضية وقبل أن يعمل كود التطبيق.
- أوقفت هولندا وفنلندا وفرنسا والدنمارك وبلجيكا وألمانيا مواقع حكومية احترازياً، وأصدر maCERT المغربي نشرة بمستوى «حرج».
- التحديث لا يزيل أي باب خلفي زُرع قبله، فراجع سجلات الخادم وملفاته بعد التحديث.
أسئلة شائعة
ما رقم إصدار PHP الآمن الذي يجب التحديث إليه؟
الإصدارات الآمنة هي 8.5.12 و8.4.27 و8.3.36 و8.2.35، وكل منها يخص فرعه. أي إصدار أقدم داخل الفرع نفسه يظل معرضاً للثغرتين.
هل موقعي على ووردبريس معرض للخطر رغم أنه محدَّث؟
نعم، إذا كانت PHP على الخادم لم تُحدَّث. تحديثات ووردبريس تشمل المنصة والإضافات فقط ولا تصل إلى PHP، فاطلب من شركة الاستضافة تأكيد التحديث.
هل تكفي حماية Cloudflare بدل تحديث PHP؟
لا تكفي. قواعد جدار الحماية المؤقتة التي نشرتها Cloudflare تقلل احتمال الهجوم، لكنها خط دفاع إضافي فقط، والحماية الحقيقية هي التحديث.
ماذا أفعل إذا كان موقعي يعمل بإصدار PHP 7.4 أو 8.0؟
نشر فريق PHP رقعاً لهذه الإصدارات على مستوى الكود المصدري فقط، فتطبيقها يتطلب بناء PHP يدوياً. الحل الأفضل هو الانتقال إلى إصدار مدعوم، وتنصح CISA بإيقاف النظام حتى يتم التحديث.
كيف أعرف إن كان موقعي قد اخترق بالفعل؟
ابحث في الخادم عن ملفات PHP جديدة لا تعرف مصدرها، وعن حسابات إدارية لم تنشئها، وعن طلبات غريبة في السجلات. وإذا ظهرت مؤشرات مريبة فاستعن بمختص، لأن تحديث PHP لا يزيل ما زُرع قبله.
الخلاصة
بالنسبة إلى صاحب أي موقع، المطلوب في الساعات المقبلة واضح: تأكد من إصدار PHP على خادمك، وحدّثه أو أوقف الموقع مؤقتاً، ثم افحص الخادم بحثاً عن أي اختراق ربما وقع قبل التحديث. ستبقى المشكلة الأكبر في الأنظمة التي لا يتابعها أحد، أي الإصدارات القديمة غير المدعومة والتثبيتات المدمجة في الأجهزة، فهذه قد تبقى مكشوفة مدة طويلة بعد أن تعود المواقع الحكومية إلى العمل. وعلى مستوى المؤسسة، أعلنت مؤسسة PHP أنها نشرت 15 ثغرة منذ 1 يوليو 2026، وأن فريقها الأمني سيتخذ قراراته بالأغلبية من الآن، إلى جانب فريق أمني للمنظومة أنشأته في مايو 2026 لتسريع معالجة الثغرات المعقدة. وقد ظهر سبب هذا التغيير في هذه الأزمة: خلاف داخلي أخّر الإصلاح منذ تدقيق 2024، في وقت صارت فيه أدوات الذكاء الاصطناعي تختصر كثيراً الوقت بين اكتشاف الثغرة واستغلالها.
