PHP2Shell هو الاسم المتداول لثغرات PHP الحرجة التي كُشف عنها في 21 أكتوبر 2026. إذا كان موقعك يستخدم PHP، فالسؤال العاجل هو ما إذا كانت بيئة التشغيل التي تخدم زوارك تتضمن الإصلاحات الأمنية. تحديث إضافة أو ظهور لوحة جدار الحماية باللون الأخضر لا يجيب عن هذا السؤال.
تؤثر PHP2Shell في بيئة تشغيل PHP التي تعتمد عليها المواقع، وقد تتيح تنفيذ تعليمات برمجية عن بُعد دون مصادقة. أصدرت PHP الإصلاحات في 8.2.35 و8.3.36 و8.4.27 و8.5.12، ويجب التحقق من وجود إصدار مصحح أو إصلاح أعاد المورّد نقله إلى إصدار سابق ووثّقه في البيئة التي تخدم طلبات الويب فعلياً. أبقِ وسائل الحماية مفعّلة، لكن لا تعتبر WAF أو تغييراً مؤقتاً في الإعدادات بديلاً عن تثبيت الإصلاح.
تم التحقق من الحالة في 21 أكتوبر 2026، الساعة 17:15 UTC. يعكس هذا الدليل الإصلاحات المنشورة، وليس الإعلان السابق الذي كان يشير إلى أن الإصدار ما زال منتظراً. راجع التنبيهات المرتبطة مجدداً قبل إجراء تغييرات، لأن حزم المورّدين وإرشادات الاستجابة قد تتطور بسرعة.
PHP2Shell: ما الذي تأكد فعلياً؟
حدّد فريق أمن PHP ثغرتين قد تسمحان بتنفيذ تعليمات برمجية عن بُعد دون تسجيل دخول. ويذكر التنبيه الرسمي أن تثبيتات PHP التي تخدم طلبات الويب معرضة للخطر، ويعتبر Apache مع mod_php التهيئة الأعلى خطورة. تؤثر بيئة التشغيل وبناؤها وطريقة معالجة الطلبات في قابلية الاستغلال.
| المعرّف | وصف PHP | الخطر العملي |
|---|---|---|
| CVE-2026-109618 | فساد الذاكرة بسبب نفادها أثناء تنظيف الطلب | قد تُستخدم حالة طلب غير صالحة عندما تعالج PHP فشلاً في تخصيص الذاكرة |
| CVE-2026-109619 | حالة عامة قديمة مملوكة لطلب | قد يصادف طلب لاحق على عملية العمل نفسها مراجع إلى ذاكرة حُررت بالفعل |
يحمل كلا التنبيهين درجة 9.2 وفق CVSS v4.0. اقرأ التقريرين الأصليين عن CVE-2026-109618 وCVE-2026-109619 بدلاً من الاعتماد على حل مؤقت مقترح في منشور اجتماعي.
هذا سبب للتحرك سريعاً، وليس دليلاً على أن كل موقع PHP قد اختُرق بالفعل. وجود ثغرة حرجة ومحاولة هجوم واختراق مؤكد نتائج مختلفة. ينبغي أن تحدد استجابتك أيّاً منها ينطبق على أنظمتك.
ما إصدارات PHP التي تعالج PHP2Shell؟
يوضح الجدول التالي إصدارات الأمان التي نُشرت اليوم للفروع المدعومة. وهو نقطة بداية لفحص تثبيت يستخدم إصدار مشروع PHP الأصلي. وقد تتضمن حزم التوزيعات الإصلاحات تحت مراجعة مختلفة للحزمة.
| فرع PHP | إصدار الأمان الذي يصلح الثغرتين |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
تؤكد إعلانات إصدارات PHP هذه الإصدارات. إذا كان مورّد التوزيعة أو الاستضافة يعيد نقل الإصلاحات إلى إصدارات سابقة، فاطلب تنبيهه الأمني ورقم مراجعة الحزمة المثبتة بدقة. قد يؤدي الاعتماد على سلسلة الإصدار وحدها إلى تصنيف خاطئ لحزمة مورّد مصححة أو لبيئة تشغيل مضمّنة قديمة.
لم تعد PHP 8.1 والإصدارات الأقدم تتلقى التحديثات المعتادة من المشروع الأصلي. وقد وفرت PHP أيضاً إصلاحات دنيا منقولة إلى الشيفرة المصدرية للإصدارات 7.4 و8.0 و8.1، لكن ذلك لا يعيد الدعم المستمر إليها. تأكد من وجود إصلاح يدعمه مورّد مسؤول بوضوح، أو ضع خطة ترقية. يوضح جدول دعم PHP حالة دعم الفروع الحالية.
افحص الحاويات وتثبيتات PHP المضمّنة والأجهزة البرمجية بصورة منفصلة. وتحذر الإرشادات التشغيلية لـ NCSC-NL تحديداً من أن تحديث PHP على المضيف لا يحدّث بالضرورة تلك البيئات.
هل تتأثر مواقع WordPress وLaravel وغيرها من مواقع PHP؟
ابدأ بالمفسّر الذي ينفذ التطبيق. قد يشترك موقع WordPress وتطبيق Laravel وبوابة PHP مخصصة في بيئة تشغيل قديمة، رغم اختلاف شيفرة تطبيقاتها تماماً. لا يؤدي تثبيت أحدث قالب أو إضافة أو إصدار إطار عمل إلى تثبيت الإصلاح الأمني لبيئة تشغيل PHP.
في الاستضافة المُدارة، اسأل عن إصدار PHP أو الحزمة المصححة التي تخدم كل موقع، وما إذا كان التغيير قد وصل إلى جميع العقد، وما إذا أُعيد تشغيل عمليات العمل حيث يلزم. اطلب أدلة من منصة الاستضافة بدلاً من اعتبار إشعار تحديث التطبيق تأكيداً لذلك.
في الأنظمة التي تديرها بنفسك، أدرج المواقع الثانوية وواجهات الإدارة والمضيفات الافتراضية القديمة وبيئات المعاينة ضمن الجرد. فقد يُحدّث تطبيق الإنتاج بينما يبقى موقع أقدم متاحاً للعامة على البنية التحتية نفسها. سجّل مسؤولاً وقرار معالجة لكل بيئة مكشوفة.
لا تستنتج أن عدم استخدام نموذج رفع الملفات يجعل التثبيت آمناً. تتناول تنبيهات PHP مسارات معالجة الطلبات داخل بيئة التشغيل. والوظائف التي يراها الزائر لا تمثل تقييماً كاملاً للتعرض.
كيفية تصحيح بيئة التشغيل التي تخدم الزوار والتحقق منها
حدّد ما يعمل فعلياً
حدّد تكامل خادم الويب وحزمة بيئة التشغيل أو صورة الحاوية ومصدر الإعدادات ومسؤول الخدمة. اربط هذا الجرد باسم المضيف الذي يستخدمه العملاء. قد يقدم مهندس يفحص المضيف الخطأ تقرير إصدار مقنعاً لكنه غير ذي صلة.
تحدد هذه الأوامر المخصصة للقراءة فقط تثبيت سطر الأوامر وإعداداته:
1php -v
2php --ini
لكنها لا تثبت ما تشغله PHP-FPM أو Apache أو أي آلية أخرى لخدمة طلبات الويب. استخدم معلومات استضافة تتطلب المصادقة أو فحصاً إدارياً مضبوطاً لتحديد بيئة التشغيل المستخدمة فعلياً. لا تترك صفحة تشخيص عامة تكشف الإعدادات وتفاصيل البيئة.
في النشر باستخدام الحاويات، تحقق من الصورة ومثيل التطبيق اللذين يتلقيان الزيارات فعلياً، وليس فقط الصورة البديلة في سجل الصور. أدرج جميع المثيلات خلف موزّع الأحمال وأي خدمات منفصلة لعمليات العمل في سجل التغيير.
طبّق الإصلاح المدعوم واختبر التطبيق
اتبع إجراء التحديث الموثق لمصدر الحزم الذي تجري صيانته أو لمورّد الصورة. سجّل المراجعة المثبتة وتنبيه المورّد الذي يغطي الثغرتين. خطط لإعادة تشغيل الخدمات أو استبدال المثيلات وفق طريقة النشر، ولا تفترض أن تنزيل حزمة يغيّر العمليات التي تعمل بالفعل.
احفظ السجلات ذات الصلة قبل التغييرات التي قد تعطل الخدمة. جهّز نسخة احتياطية تم التحقق منها وخطة استعادة، ثم اختبر مسارات تطبيق ممثلة بعد التحديث. قد تشمل الاختبارات تسجيل الدخول والجلسات والدفع ورفع الملفات والمعالجة الخلفية، حيث يستخدمها التطبيق.
أكمل التغيير بإعادة فحص بيئة التشغيل التي تخدم الطلبات. احتفظ بأدلة توضح المثيلات التي حُدّثت ووقت تحويل الزيارات والشخص الذي اعتمد اختبارات التطبيق. نجاح مهمة النشر دليل مفيد، لكنه ليس عملية التحقق بأكملها.
هل يحمي Cloudflare WAF من PHP2Shell؟
أعلنت Cloudflare نشر وسائل حماية WAF من PHP2Shell لعملاء WAF المجاني والمدفوع، ورصد زيارات هجومية. ويصف إعلانها حماية تراعي معلومات الطلب والاستجابة. كما توصي العملاء صراحة بتصحيح PHP رغم وجود تلك الحماية.
بالنسبة إلى موقع بعينه، تحقق من أن الزيارات المعنية تمر فعلياً عبر الخدمة المحمية، وأن القواعد المنطبقة مفعّلة. راجع الاستثناءات وقواعد التجاوز وأي خادم أصل يمكن الوصول إليه بصورة منفصلة. هذه فحوص للنشر، وليست ادعاء بأن إعلان Cloudflare يضمن حماية كل مسار محتمل إلى تطبيقك.
احتفظ ببيانات أحداث WAF ضمن التحقيق. قد يثبت طلب محظور أن قاعدة طابقت ذلك الطلب. لكنه لا يؤكد أن أحداً لم يصل إلى الأصل بطريقة أخرى، أو أن اختراقاً سابقاً لم يحدث.
استخدم WAF طبقة دفاع إضافية أثناء إتمام تحديث بيئة التشغيل. لا تؤجل إصلاح PHP لمجرد أن لوحة التحكم تسجل محاولات محظورة.
الإجراءات المؤقتة ليست إصلاحاً كاملاً لـ PHP2Shell
إذا تعذر تطبيق الإصلاح مؤقتاً، فاتبع تنبيهات PHP الحالية مع المهندس أو المورّد المسؤول عن النظام. يشرح تنبيه الحالة القديمة
سبب ضرورة تعطيل session.upload_progress.enabled قبل تحليل الطلبات، وضرورة إعادة تشغيل عمليات العمل. ويحذر تحديداً من الاعتماد على ini_set() أو ملف FPM .user.ini لهذا الغرض.
يمنع هذا التغيير المسارات المؤكدة المرتبطة بالجلسات، وليس كل الأشكال المحتملة. ولـ PHP 8.5 إرشادات منفصلة تتعلق بـ fatal_error_backtraces. نسخ مقطع إعدادات قصير من منتدى ليس دليلاً على معالجة الثغرتين.
يصف تنبيه نفاد الذاكرة وسائل مختلفة، منها حدود الطلبات وتغييرات طريقة التعامل مع حدود الذاكرة. لهذه الإجراءات آثار على الموارد والتوافر. راجع التعليمات الكاملة التي تناسب النشر الفعلي بدلاً من إزالة حدود الذاكرة على خادم حي دون دراسة.
عندما لا يمكن خفض التعرض إلى مستوى مقبول قبل تطبيق الإصلاح، ناقش تقييد الوصول العام إلى التطبيق المتأثر. وثّق الإجراء المؤقت وحدوده والمسؤول عنه والإصلاح الدائم المخطط له. يجب أن يرتبط الحل المؤقت بشرط لإزالته أو مراجعته، وألا يتحول إلى إعداد دائم غير موثق.
ما الذي ينبغي مراقبته بعد تقييم التعرض؟
ابدأ بخط أساس واحفظ الفترة الزمنية ذات الصلة. اربط طلبات الويب بأحداث PHP وخادم الويب والمضيف، بدلاً من اعتبار طلب واحد غير معتاد تشخيصاً كاملاً. وعند غياب السجلات، سجّل هذا القيد صراحة.
| الملاحظة | سؤال التحقيق |
|---|---|
| توقف غير متوقع لعمليات PHP أو حالات فشل في الذاكرة | هل تغير سلوك التطبيق، وما الطلبات التي عولجت في الوقت القريب؟ |
| ملفات تنفيذية جديدة أو معدلة | هل حدث نشر معتمد أم كتابة غير مفسرة؟ |
| عمليات فرعية أو اتصالات صادرة غير متوقعة | هل لدى عملية الويب سبب مشروع لهذا النشاط؟ |
| مطابقات WAF وسجلات الوصول إلى الأصل | ما الطلبات التي حُظرت، وما المسارات التي وصلت إلى الأصل؟ |
| تغييرات في الحسابات أو المهام المجدولة أو الأسرار | هل يمكن ربط كل تغيير بمشغّل مخوّل؟ |
هذه أسئلة للتحقيق، وليست مؤشرات خاصة بـ PHP2Shell أو دليلاً على اختراق. قد تنتج العمليات المعتادة أعراضاً مماثلة. وبالمثل، فإن غياب التنبيهات لا يثبت أن نظاماً غير مصحح كان آمناً.
إذا أشارت الأدلة إلى اختراق، فاحفظها ورتّب التعامل مع الحادث بالتوازي مع تطبيق الإصلاح. لا تؤدي ترقية المفسّر إلى إزالة وسائل بقاء المهاجم أو إلغاء سرقة بيانات الاعتماد أو تحديد البيانات التي تم الوصول إليها. تعامل مع هذه الأمور كأسئلة منفصلة في خطة الاستجابة.
الأسئلة الشائعة
ما استغلال PHP2Shell؟ يشير PHP2Shell إلى ثغرتي PHP المسجلتين باسم CVE-2026-109618 وCVE-2026-109619. تتعلقان بإدارة الذاكرة داخل بيئة التشغيل، وقد تسمحان بتنفيذ تعليمات برمجية عن بُعد دون مصادقة. ليستا مجرد عيب في إضافة WordPress.
ما الإصدارات التي أتحقق منها للحصول على إصلاح PHP2Shell؟ إصلاحات الفروع المدعومة المنشورة في 21 أكتوبر 2026 هي PHP 8.2.35 و8.3.36 و8.4.27 و8.5.12. بالنسبة إلى الإصلاحات المنقولة لحزم التوزيعات، احصل على تنبيه المورّد وتحقق من المراجعة الدقيقة للحزمة المصححة المثبتة في البيئة التي تخدم الطلبات.
هل يعالج تحديث WordPress ثغرات PHP2Shell؟ تحديث WordPress وحده لا يحدّث مفسّر PHP الذي يعمل تحته. حافظ على صيانة التطبيق، لكن تحقق بصورة منفصلة من إصلاح بيئة تشغيل PHP مع مزوّد الاستضافة أو المهندس المسؤول عن الخادم.
هل يكون الموقع خلف Cloudflare آمناً تلقائياً؟ أعلنت Cloudflare حماية WAF، لكن مسار الزيارات والقواعد المنطبقة وتعرض خادم الأصل ما زالت تحتاج إلى فحص. أبقِ الحماية مفعّلة وصحح PHP. لوحة جدار الحماية ليست دليلاً على إصلاح بيئة التشغيل أو عدم وقوع اختراق سابق.
هل يكفي تعطيل تتبع تقدم رفع الملفات في الجلسات؟ لا. تصف PHP هذا الإجراء بأنه يمنع المسارات المؤكدة المرتبطة بالجلسات، وليس كل الأشكال المحتملة. يجب تطبيقه في طبقة الإعداد المناسبة مع إعادة تشغيل عمليات العمل. تظل ترقية بيئة التشغيل إلى نسخة مصححة أو استخدام إصلاح مورّد متحقق منه ضرورية.
هل يمكنني اختبار استغلال منشور ضد موقعي الحي؟ فضّل أدلة الإصدار والحزم والإعدادات للفحص الأولي. إذا تطلب التحقق اختبار استغلال، فنظّمه بتفويض صريح في بيئة مضبوطة تتضمن العزل والمراقبة وخطة استعادة. لا تشغّل نصوص استغلال غير مراجعة ضد الإنتاج.
هل يثبت تثبيت الإصلاح أن الخادم لم يُخترق؟ لا. يعالج التصحيح عيوب بيئة التشغيل، بينما يراجع تقييم الحادث النشاط السابق ووسائل البقاء وبيانات الاعتماد وإمكانية الوصول إلى البيانات. اربط مساري العمل وسجّل حدود الأدلة المتاحة.
هل تحتاج إلى فحص موقع PHP أو مراقبته أو تصحيحه؟
يمكننا مساعدتك في تحديد بيئات PHP التي تخدم مواقعك، وتقييم التعرض، ومراجعة السجلات ووسائل الحماية المتاحة، والتخطيط للإصلاح المطلوب أو الترقية المدعومة. إذا احتاجت البيئة إلى متابعة مستمرة، يمكننا الاتفاق على نطاق المراقبة ومسؤولية التنبيهات وإجراءات التصعيد وفق المخاطر المحددة.
تدعم خدمة أمن التطبيقات لدينا التقييم والتحقيق، بينما تغطي خدمة أمن الخوادم الاستضافة والإعدادات. ويمكننا العمل مع مزوّد الاستضافة للتحقق من إصلاحات المورّد وتنسيق التغييرات وتوثيق اختبارات التطبيق بعد التحديث.
النتيجة المفيدة هي سجل واضح لما جرى فحصه وتصحيحه، وما بقي غير مؤكد، ومن يتحمل مسؤولية المتابعة. لا نعد بإثبات السلامة استناداً إلى سلسلة إصدار أو فحص واحد. يُتفق على النطاق والتوافر قبل بدء العمل.
تواصل معنا لفحص التعرض لـ PHP2Shell أو لمراقبة الأمان أو للمساعدة في التصحيح . اذكر ترتيب الاستضافة والنطاقات المتأثرة وإصدارات PHP المعروفة والشخص المخوّل بالموافقة على التغييرات. يرجى عدم إرسال كلمات المرور أو رموز الوصول في الاستفسار الأول.