الإجابة باختصار: يشير اسم PHP2Shell إلى ثغرتين أمنيتين حرجتين في نواة PHP، هما CVE-2026-109618 وCVE-2026-109619، جرى تصحيحهما في 21 أكتوبر 2026، وسجّلت كلتاهما على مقياس CVSS v4.0 درجة 9.2 (حرجة). وفي أسوأ السيناريوهات لا يحتاج المهاجم إلى أي حساب: إذ تكفي طلبات HTTP مُعدّة خصيصًا لتنفيذ كود على خادم الويب (RCE). والمشكلة لا تكمن في تطبيقك، بل في لغة PHP نفسها. ويعني ذلك أن كود WordPress أو Laravel الخالي تمامًا من العيوب، بل حتى موقع «Hello World» البسيط، معرّض للخطر إذا كان إصدار PHP الذي يعمل عليه مصابًا. والإصلاح الكامل الوحيد هو تحديث PHP إلى الإصدار 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35 (أو إلى الحزمة المصحَّحة من توزيعتك) ثم إعادة تشغيل جميع عمليات PHP العاملة (Workers). ولم ننتظر في Partnerfy التصحيح الرسمي: فقبل صدوره بنحو ثلاث ساعات فعّلنا إجراء تخفيف مؤقتًا على خوادمنا، وأخذنا نسخًا احتياطية كاملة للحسابات، وشددنا دفاعاتنا طبقة بعد طبقة. ونشرح في هذا المقال كيف ظهرت الثغرات، وما طبيعتها التقنية، وما الذي عليك فعله، وما الذي قمنا به من جانبنا.

يتوجه هذا المقال إلى أصحاب الأعمال والفرق التقنية الذين يعتمدون على PHP في تشغيل مواقعهم الإلكترونية أو منصات التجارة الإلكترونية أو برمجياتهم المخصصة. وتستند التفاصيل التقنية إلى الإعلان الأمني الرسمي من مشروع PHP وتنبيهاته الأمنية على GitHub (GHSA)، وإلى منشورات الباحثين الذين اكتشفوا الثغرات. وحيثما تعارضت المصادر أشرنا إلى ذلك صراحةً. والوضع يتطور بسرعة؛ هذا المقال محدّث حتى مساء 21 أكتوبر 2026.

ما هي ثغرات PHP2Shell ولماذا تُعد بهذه الخطورة؟

تُعد PHP من أكثر لغات البرمجة من جهة الخادم انتشارًا على الويب، فعليها تعمل WordPress وWooCommerce وDrupal وJoomla وMagento وLaravel جميعها. وهناك ثلاث خصائص تجعل PHP2Shell بالغة الخطورة:

  • لا تتطلب أي مصادقة. لا يحتاج المهاجم إلى التسجيل في موقعك أو معرفة كلمة مرور أو ملء نموذج. فالطلبات المُعدّة خصيصًا كافية.
  • يمكن إطلاقها قبل تشغيل كود تطبيقك. بحسب مشروع PHP، يبلغ الخطر أقصاه في بيئات Apache التي تعتمد mod_php، إذ ثبت فيها أن طلبًا غير مصادَق عليه يطلق الهجوم قبل تشغيل أي كود من التطبيق. ولن تغلق هذا المسار الإضافات المحدّثة، ولا الكود النظيف، ولا فحوص الأمان داخل التطبيق.
  • نطاق التأثير واسع للغاية. بحسب مشروع PHP، يشمل الخطر «جميع تثبيتات PHP التي تخدم طلبات الويب» (PHP-FPM وApache mod_php وphp-cgi وFrankenPHP وLiteSpeed). وبحسب Wiz، وهي إحدى الفرق التي اكتشفت الثغرات، فإن كل إصدار من PHP صدر خلال العقد الأخير، رجوعًا حتى الإصدار 5.4، يتأثر بإحدى الثغرتين على الأقل. وهذا التقدير للنطاق يعود إلى Wiz؛ أما الإعلان الرسمي من PHP فلا يذكر سوى الفروع المدعومة (من 8.2 إلى 8.5).

والأحكام الصادرة قاطعة. فقد وصفت Wiz هذه النتائج بأنها «من بين أخطر الثغرات التي اكتُشفت في PHP». ووفق تصريحات نقلتها الصحافة، أوصى المركز الوطني للأمن السيبراني في المملكة المتحدة (NCSC) بفصل الأنظمة التي يتعذر تصحيحها فورًا عن الشبكة. كما نصحت CERT-EU بعزل التطبيقات المتصلة بالإنترنت إلى حين تطبيق التصحيح. وقد لخّص الباحث الأمني Kevin Beaumont الوضع بدقة: «سيؤدي وضع PHP إلى موجة هائلة من الحوادث الأمنية».

كيف ظهرت الثغرات؟ التسلسل الزمني

تبدأ قصة PHP2Shell عام 2024 ثم تتحول إلى أحد أكثر أسابيع عام 2026 اضطرابًا في الأمن السيبراني. وجميع الأوقات الواردة بالتوقيت العالمي المنسق (UTC).

التاريخ ماذا حدث؟
2024خضعت PHP لأول تدقيق أمني مستقل منذ سنوات (بتمويل من Sovereign Tech Agency وتنظيم OSTIF وتنفيذ Quarkslab). وأثناء إصلاح إحدى المشكلات المكتشفة، لاحظ أحد مطوري نواة PHP أولى مؤشرات المشكلة الكامنة وراء CVE-2026-109618، وهي نفاد الذاكرة (OOM). ولم يُعثر حينها على مسار هجوم محدد، فظل الإصلاح معلقًا شهورًا. وتصف PHP Foundation الآن هذا التأخير صراحةً بأنه «إخفاق هيكلي».
30 يوليو 2026بدأت شركة الأمن Calif تدقيق PHP ضمن برنامج «Patch the Planet» التابع لها.
11 أغسطس 2026أبلغ باحث من Calif مشروع PHP بثغرة تنفيذ كود عن بُعد غير مشروطة ناجمة عن السبب الجذري نفسه. وفي اليوم ذاته، أبلغت OpenAI (عبر Codex Security) عن السبب الجذري نفسه بصورة مستقلة.
19-24 أغسطس 2026وجد باحثو Wiz مسارات هجوم منفصلة، وأكدوا إمكانية تنفيذ الكود عن بُعد (RCE) على Drupal وWordPress، وأبلغوا فريق أمن PHP في 24 أغسطس.
20 أكتوبر، نحو 15:00 UTCقبل الإفصاح المنسَّق بيومين، بدأ رقما CVE بالانتشار في المنتديات ووسائل التواصل الاجتماعي، مصحوبين بموعد إصدار خاطئ ودرجة CVSS خاطئة (10.0). ولم تتسرب أي تفاصيل تقنية.
20 أكتوبر، نحو 19:30 UTCنشر مشروع PHP إعلانًا تمهيديًا وقدّم موعد التصحيح يومًا واحدًا: 21 أكتوبر الساعة 14:00 UTC بدلًا من 22 أكتوبر.
20 أكتوبر، نحو 20:00 UTCنشرت Calif، إحدى الشركات التي أبلغت عن الثغرة، عن طريق الخطأ مقطع فيديو يُظهر إثبات المفهوم (PoC) الخاص بها وهو يعمل ضد أهداف متعددة. وقد نُسخ المقطع وانتشر، ما سرّع السباق على بناء إثباتات مفهوم فعّالة.
21 أكتوبر، نحو 03:00 UTCأطلقت Cloudflare أول مجموعة قواعد لجدار حماية تطبيقات الويب (WAF) ضد نواقل الهجوم المعروفة، مفعّلة افتراضيًا لجميع العملاء، بمن فيهم مستخدمو الخطة المجانية.
21 أكتوبر، 07:41 UTCنشرت Chainguard من جانب واحد صورًا (Images) تتضمن التصحيح قبل الإصدار المنسَّق بأكثر من ست ساعات، في خرق لحظر النشر (Embargo).
21 أكتوبر، نحو 14:00 UTCصدور إصدارات PHP الجديدة (8.5.12 و8.4.27 و8.3.36 و8.2.35).
21 أكتوبر، من نحو 14:20 UTC فصاعدًاأعلنت watchTowr أن شبكة مصائدها (Honeypots) ترصد محاولات استغلال نشطة لكلتا الثغرتين. وأفادت Cloudflare أيضًا ببدء هجمات مبكرة، إذ يعدّل المهاجمون حمولاتهم (Payloads) لتجاوز القواعد الأولية.

حتى وقت نشر هذا المقال، لم يؤكد أي مصدر عام نجاح اختراق خادم محدد عبر هذه الثغرات. لكن المحاولات بدأت، ويتوقع الباحثون أن تمتد التداعيات طويلًا. وكما قال المختص في الاستجابة للحوادث Hal Pomeranz: «ستمتد تداعيات هذه الثغرات طويلًا».

عامل الذكاء الاصطناعي: الفاصل بين التصحيح والاستغلال بات يُقاس بالساعات

ثمة تفصيل آخر يجعل PHP2Shell قصة تنتمي إلى عام 2026 بامتياز: فقد أسهمت نماذج الذكاء الاصطناعي في اكتشاف الثغرة وفي إيجاد طريق استغلالها معًا. إذ أبلغ فريق Codex Security لدى OpenAI بصورة مستقلة عن أحد الاكتشافات. وتكتب Wiz من جهتها: «خفّضت نماذج الذكاء الاصطناعي الأكثر تقدمًا هذا الحاجز بدرجة كبيرة، فحوّلت خللًا قائمًا منذ زمن طويل إلى أداة استغلال». وهكذا تحوّل خلل ظل نظريًا في عام 2024 إلى سلاح في عام 2026 بمساعدة الآلات. والرسالة للمدافعين واضحة: يبدأ العد التنازلي لحظة صدور التصحيح، ولم يعد ترف «سننظر في الأمر في عطلة نهاية الأسبوع» متاحًا.

ما الذي يحدث تقنيًا؟ ثغرتان وسببان جذريان مختلفان

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

الثغرة CVE-2026-109618: بيانات «نصف مكتملة» لحظة نفاد الذاكرة

عند تجاوز حد الذاكرة أثناء الطلب (نفاد الذاكرة، OOM)، تقفز PHP فجأة خارج سياقها الحالي عبر آلية تسمى longjmp() وتُنهي الطلب. ويصف الإعلان الرسمي المشكلة على النحو التالي: في نقاط معينة، تصبح ذاكرة الطلب قابلة للوصول قبل اكتمال تهيئتها. وإذا فشل تخصيص الذاكرة في تلك اللحظة بالذات، لا تحتسب PHP هذا الخروج المبكر على نحو صحيح، فتبقى الذاكرة في حالة غير صالحة. ثم يقرأ روتين إنهاء الطلب هذه البيانات نصف المكتملة ويتصرف بناءً عليها. والنتيجة تلف في الذاكرة، ثم تنفيذ للكود إذا صيغ الهجوم بإحكام.

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

فكيف يصيب المهاجم تلك اللحظة تحديدًا؟ تعتمد الأساليب المذكورة في الإعلان على صيغة multipart/form-data المستخدمة في رفع الملفات:

  • يمكن للطلبات متعددة الأجزاء (Multipart) التي لا تعلن طول محتوى صالحًا أن تفلت من فحص post_max_size الأولي.
  • يمكن أن يحتوي جزء واحد من الطلب متعدد الأجزاء على عدد غير محدود من الترويسات.
  • لا تُحتسب حقول الملفات الفارغة ضمن حد max_file_uploads، لكنها تُنشئ مع ذلك مصفوفات بيانات وصفية للملفات.
  • تضاعف أسماء الحقول المتداخلة عمل بناء المصفوفات.

باختصار، يصوغ المهاجم طلبًا يدفع PHP إلى حافة ذاكرتها في أسوأ لحظة ممكنة. وكما توضح Wiz، تحلل PHP الطلبات متعددة الأجزاء عند بدء الطلب، قبل اكتمال التهيئة العادية للوحدات. وفي المقابل، يشغّل Apache mod_php روتين الإنهاء دون أي شرط، حتى لو فشل بدء الطلب. لهذا يمكن أن تكتمل السلسلة كلها دون تشغيل سطر واحد من كود تطبيقك. وقد تأكد تنفيذ الكود عن بُعد كاملًا عبر HTTP ضد mod_php في إعداد prefork نموذجي بعدة عمليات عاملة، باستخدام حدود PHP الافتراضية للإدخال والذاكرة. أما PHP-FPM فأمرها مختلف، لأن العملية العاملة تُنهى عند فشل بدء الطلب: إذ يشير تحليل الكود المصدري إلى أن FPM قد تتأثر أيضًا، لكن لم يُعرض بعد استغلال كامل ضدها لهذه الثغرة.

الثغرة CVE-2026-109619: «شبح» الطلب السابق

لا تعالج عمليات PHP العاملة طلبًا واحدًا ثم تخرج، بل تخدم العملية نفسها طلبات كثيرة واحدًا تلو الآخر. وتحتفظ PHP بحالة عامة تشمل حالة الأخطاء والجلسات والكائنات والامتدادات. ويوضح الإعلان أن جزءًا من هذه الحالة تحتفظ به العملية العاملة، لكنه يشير فعليًا إلى ذاكرة تخص طلبًا واحدًا. فإذا انتهى الطلب في لحظة غير متوقعة، تبقى هذه المؤشرات (Pointers) عالقة. ويلامس الطلب التالي الذي يصل إلى العملية العاملة نفسها هذه الحالة القديمة قبل أن تتاح للتهيئة العادية فرصة إعادة ضبطها. وهذا خلل كلاسيكي من نوع use-after-free (استخدام ذاكرة جرى تحريرها بالفعل). ويمكن، مع ترتيب مدروس للذاكرة الديناميكية (Heap)، أن يؤدي إلى تنفيذ كامل للكود عن بُعد.

وإليك التشبيه: في فندق، ما زالت بطاقة مفتاح النزيل السابق تعمل، ويدخل النزيل الجديد الغرفة قبل تنظيفها. وأمتعة النزيل السابق ما زالت في الداخل.

ولهذه الثغرة بُعد آخر يتعلق بتسرب البيانات. فبحسب Wiz، قد يشمل كشف الذاكرة كلمات مرور ورموز مصادقة ومفاتيح API وشهادات تخص طلبات أخرى أو الخادم نفسه. ومن المسارات المؤكدة ميزة تتبع تقدم الرفع في الجلسة (Session Upload Progress). وهذه الميزة مفعّلة افتراضيًا، ولا يحتاج التطبيق حتى إلى استدعاء session_start()؛ إذ يمكن أن تبدأ معالجة الجلسة قبل تهيئتها العادية. ويذكر الإعلان أيضًا مسار تتبع المكدس (Backtrace) عند الأخطاء الفادحة في PHP 8.5 بوصفه مسارًا مؤكدًا ثانيًا. وقد تأكد تنفيذ الكود عن بُعد عبر دورة حياة الجلسة في بيئتي mod_php وPHP-FPM معًا.

ملاحظة مهمة: بحسب التوصيفات الرسمية من PHP، تتعلق CVE-2026-109618 بالبيانات نصف المكتملة لحظة نفاد الذاكرة، بينما تتعلق CVE-2026-109619 بالحالة القديمة المتبقية بين الطلبات. وتربط بعض المصادر (ومنها Wiz) أساليب الهجوم بأرقام CVE على نحو مختلف. ونتبع في هذا المقال ما ورد في تنبيهات PHP الأمنية على GitHub (GHSA).

من المتأثرون؟ جدول الإصدارات

فرع PHP الإصدارات المتأثرة الإصدار المصحَّح ملاحظات
8.5قبل 8.5.128.5.12دعم نشط
8.4قبل 8.4.278.4.27دعم نشط
8.3قبل 8.3.368.3.36إصلاحات أمنية فقط
8.2قبل 8.2.358.2.35ينتهي الدعم في 31 ديسمبر 2026
8.1 و8.0 و7.4متأثرةلا يوجد إصدار رسميلم يشارك فريق PHP سوى تصحيحات مصغّرة على مستوى الكود المصدري. راجع مزوّد توزيعتك أو مزوّد الدعم طويل الأمد (LTS)، أو انتقل إلى إصدار مدعوم.
7.3 وما قبله، و5.xمتأثرة بحسب Wizلا يوجد تصحيحالترقية هي السبيل الوحيد.

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

ولإعطاء فكرة عن حجم المشكلة: بحسب تحليل من Mallory يستند إلى بيانات Shodan، كان على الإنترنت حتى 20 أكتوبر نحو 884,000 خادم تعلن في ترويسات HTTP أنها تستخدم PHP 8.1 أو أقدم. ولا يمكن لهذه الإصدارات الحصول على تصحيحات رسمية. وهذا إحصاء قائم على الترويسات لا عدد مؤكد للأنظمة المتأثرة، لكنه يبيّن المدى الزمني الذي قد تبلغه هذه التداعيات.

ماذا فعلت Partnerfy؟ دفاع من 6 طبقات لم ينتظر التصحيح

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

1. الاستجابة المبكرة: إجراء تخفيف مؤقت قبل التصحيح الرسمي بساعات

تابع فريق DevOps لدينا عن كثب خبر التسريب والتقييمات التقنية الأولى، وقبل نحو ثلاث ساعات من صدور التصحيح الرسمي عطّل session.upload_progress.enabled على مستوى الخادم بالكامل. فالثغرة CVE-2026-109619 هي التي توصي PHP لمواجهتها بهذا الإجراء المؤقت تحديدًا. ولم نكتفِ بتغيير الإعداد، بل غيّرناه في المكان الصحيح. إذ يشترط فريق PHP ألا يُطبَّق هذا الإعداد عبر ini_set() أو .user.ini، بل على مستوى الإعدادات الرئيسية (php.ini / إعدادات الخادم). وقد أجرينا التغيير على هذا المستوى بالذات وتحققنا منه في الإعدادات الفعلية قيد التشغيل.

2. طبقة الحافة: تصفية الهجمات قبل وصولها إلى الخادم

يحظى موقع شركتنا partnerfy.co والمشاريع التي نخدمها خلف Cloudflare بحماية شبكة الحافة (Edge) التابعة لها. وقد أطلقت Cloudflare في وقت مبكر من يوم 21 أكتوبر أول مجموعة قواعد WAF مفعّلة افتراضيًا ضد نواقل PHP2Shell المعروفة. ونتيجة لذلك، تُصفّى نسبة كبيرة من الطلبات المشبوهة قبل أن تصل إلى خوادمنا أصلًا. وبما أن التقارير تشير إلى أن المهاجمين يعدّلون حمولاتهم لتجاوز القواعد الأولية، فإننا لا نعدّ هذه الطبقة كافية بمفردها أبدًا؛ فالطبقات الأخرى تقف خلفها مباشرة.

3. إعدادات PHP المحصَّنة: قطع الطريق على خطوة المهاجم التالية

جرى تحصين إعدادات PHP على خوادمنا قبل هذه الأزمة بوقت طويل. فالدوال التي تنفّذ أوامر النظام (system وpopen وproc_open وما شابهها) معطَّلة، وتضمين الملفات عن بُعد (allow_url_include) معطَّل كذلك. ولنكن صريحين: قد يتمكن تنفيذ الكود عن بُعد على مستوى الذاكرة نظريًا من الالتفاف على هذه القيود. لكن خطوة المهاجم الأولى في الواقع العملي غالبًا ما تكون فتح واجهة أوامر (Shell)، أو تنزيل أدوات، أو زرع واجهة أوامر خبيثة على الويب (Web Shell). وتجعل هذه القيود تلك الخطوات الحرجة التي تلي الاختراق أصعب بكثير وأكثر ضجيجًا بكثير. والضجيج يعني انكشاف المهاجم.

4. عزل الحسابات: حتى إن فُتح باب، يبقى الممر مغلقًا

يعمل كل حساب على خوادمنا داخل «قفص» معزول خاص به على مستوى نظام الملفات. وحتى لو تحقق أسوأ السيناريوهات في حساب ما، تبقى قدرة المهاجم على التحرك جانبيًا إلى ملفات الحسابات الأخرى وعملياتها مقيدة بشدة. فانكسار حلقة واحدة لا يعني انكسار السلسلة كلها.

5. نسخ احتياطية لسيناريو الكارثة: الاستعداد للأسوأ

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

6. التصحيح وإعادة التشغيل والبحث عن المؤشرات

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

وفي الوقت نفسه، فحصنا سجلات الوصول لدينا بدقة بحثًا عن المؤشرات التي وصفها الباحثون. ومن الأمثلة الملموسة: بعد نحو ثلاث ساعات من صدور التصحيح، وصلت سلسلة من طلبات POST إلى جذر موقعنا وإلى مسارات مثل /api و/app من عنوان IP سحابي واحد، انتحل على التوالي هوية برامج زحف مختلفة تابعة لمحركات البحث والذكاء الاصطناعي (CCBot وAmazonbot وClaudeBot وغيرها). وقد رُفض كل طلب من هذه الطلبات بالرمز 403 في طبقة الأمان على الخادم قبل أن يصل إلى تطبيقنا. ولا يمكننا الجزم بأنها كانت محاولات لاستغلال PHP2Shell، لكن توقيتها ونمط انتحال الهوية يتوافقان مع عمليات الفحص الواسع التي بدأت بعد صدور التصحيح. وحتى وقت النشر، لم نرصد أي مؤشر على اختراق أنظمتنا.

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

ما الذي عليك فعله؟ قائمة تحقق خطوة بخطوة

1. اعرف إصدار PHP لديك

إذا كنت تستخدم cPanel، فيمكنك التحقق منه من شاشة «MultiPHP Manager» أو «Select PHP Version»؛ وإذا كان لديك وصول إلى الخادم، فالأمر php -v يعرضه لك. لكن انتبه: قد يختلف إصدار PHP في سطر الأوامر عن الإصدار الذي يشغّل موقعك. والطريقة الأوثق هي أن تسأل مزوّد الاستضافة عن إصدار PHP الذي يستخدمه موقعك، أو أن تتحقق عبر صفحة phpinfo() مؤقتة ثم تحذفها فورًا. وإذا كنت على استضافة مشتركة، فالتحديث من مسؤولية مزوّد الاستضافة لا مسؤوليتك. اسأله اليوم: «هل طبّقتم تصحيح PHP2Shell لديكم؟»

2. حدّث ثم أعِد التشغيل

حدّث إلى أحد الإصدارات المستهدفة (8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35). وفي توزيعات Linux قد يبدو رقم الإصدار في الحزم مختلفًا. ولذلك، وكما توصي Debian أيضًا، ابحث عن رقم CVE في سجل تغييرات الحزمة بدلًا من الاعتماد على رقم الإصدار. وبعد التحديث، أعِد تشغيل Apache وPHP-FPM وأي عمليات PHP عاملة طويلة التشغيل.

3. إذا تعذر عليك التحديث فورًا: إجراءات التخفيف المؤقتة

لنبدأ بتحذير مشروع PHP نفسه: هذه الإجراءات «تقلل التعرض لمسارات هجوم محددة لكنها لا تجعل التثبيت آمنًا». والإصلاح الكامل الوحيد هو التحديث.

إجراء التخفيف المؤقت الثغرة المعنية القيود
session.upload_progress.enabled = 0 (في php.ini أو مجمّع FPM أو إعدادات الخادم، وليس عبر ini_set() أو .user.ini)، ثم إعادة تشغيل جميع العمليات العاملة109619يغلق مسارات الجلسة المؤكدة، لكنه لا يغلق الأشكال الأخرى من الهجوم. أما 109618 فلا يؤثر فيها.
post_max_size: القيمة 8M إذا كنت لا تقبل رفع الملفات، و32M إذا كنت تقبله، مع ضبط upload_max_filesize على قيمة أقل من ذلك. وفي الطبقة الأمامية (خادم الويب / Proxy)، حدود لعدد الحقول والأجزاء والترويسات ولعمق التداخل. وإذا كان تطبيقك لا يستخدم Multipart، فاحظر هذه الطلبات في الطبقة الأمامية.109618يضيّق سطح الهجوم، لكنه ليس إصلاحًا كاملًا.
memory_limit = -1، مع ضبطه بطريقة لا تتيح للتطبيقات تغييره (مثلًا عبر php_admin_value). وفرض حد الذاكرة بدلًا من ذلك على مستوى cgroup / الحاوية.109618قد يصل فشل تخصيص الذاكرة على مستوى أدنى إلى المسار المصاب رغم ذلك. لا تستخدم RLIMIT_AS / RLIMIT_DATA؛ فقد يطلقان المسار نفسه.
في PHP 8.5 فقط: fatal_error_backtraces = 0، ثم إعادة التشغيل109619يغلق مسار تتبع المكدس المؤكد فقط.
إزالة إعدادات INI الخاصة بكل طلب التي تُصدر تحذيرات قبل بدء الطلب. ولا يفيد في شيء إخفاء التحذيرات عبر error_reporting أو display_errors أو @.109619يرتبط ببيئة التشغيل، وليس إصلاحًا كاملًا.
جدار حماية تطبيقات الويب (WAF)، مثل مجموعة القواعد الأولية من Cloudflareالنواقل المعروفةيعدّل المهاجمون حمولاتهم لتجاوز القواعد.

4. إذا كنت تستخدم إصدارًا قديمًا من PHP: الترقية لا تحتمل التأجيل

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

5. افحص علامات الاختراق

المؤشرات التي يوصي الباحثون بفحصها بعد التصحيح:

  • طلبات Multipart غير معتادة تليها مباشرة أخطاء في حد الذاكرة أو دفعات من استجابات HTTP 500
  • ملفات تعريف ارتباط PHPSESSID كبيرة بشكل غير متوقع أو مشوّهة
  • عمليات إعادة تشغيل أو أعطال غير مبررة لعمليات PHP العاملة
  • عمليات php-fpm أو httpd أو apache2 التي تُطلق واجهة أوامر أو مفسِّرًا أو أداة تنزيل (مثل sh أو bash أو curl أو wget)
  • ملفات جديدة في المجلد الجذر للموقع (Web Shells)، ومهام cron جديدة، وحسابات مستخدمين جديدة

لأن الهجوم يقع تحت طبقة التطبيق، فقد لا يترك سوى آثار ضئيلة جدًا في سجلات تطبيقك. لذا افحص سجلات PHP وسجلات خادم الويب. وإذا بدا أي شيء مريبًا، فاعزل الخادم واحفظ السجلات، ثم ابدأ التحقيق. وبما أن CVE-2026-109619 قد تؤدي أيضًا إلى كشف محتوى الذاكرة، فمن المنطقي عند الشك تغيير كلمات مرور قواعد البيانات ومفاتيح API وأسرار الجلسات.

درس هذه الأزمة: الأمن ليس منتجًا، بل رد فعل راسخ

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

وفي Partnerfy، يأتي رد الفعل هذا معيارًا ثابتًا في خدماتنا: الاستضافة المدارة وإدارة الخوادم، والأمن السيبراني، والنسخ الاحتياطي والتعافي من الكوارث. وبصفتنا شركة برمجيات يقع مقرها الرئيسي في صقاريا (Sakarya)، ولها مكاتب في تركيا وألمانيا وروسيا وأيرلندا، يمكننا مساعدتك على تحديد إصدار PHP الذي يعمل عليه موقعك، وكيفية الاستعداد لانتهاء دعم PHP 8.2، وما إذا كانت ثغرات PHP2Shell تهدد موقعك. تواصل معنا لنفحص موقعك معًا.

المصادر

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

ما هي ثغرات PHP2Shell تحديدًا؟

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

هل تشكل ثغرات PHP2Shell خطرًا على موقع WordPress الخاص بي؟

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

إلى أي إصدار من PHP ينبغي أن أحدّث؟

إلى الإصدار المصحَّح من الفرع الذي تستخدمه (8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35). ولا تتلقى PHP 8.1 والإصدارات الأقدم أي تحديثات رسمية، لذا عليك الانتقال إلى إصدار مدعوم. وبما أن دعم 8.2 ينتهي في 31 ديسمبر 2026، فإننا ننصح بالتخطيط من الآن للانتقال إلى 8.3 أو 8.4 على المدى المتوسط.

هل تعطيل session.upload_progress كافٍ؟

لا. يغلق هذا الإعداد مسارات الجلسة المؤكدة في CVE-2026-109619، لكن الأشكال الأخرى من الهجوم والثغرة CVE-2026-109618 تبقى قائمة. وهو خطوة أولى جيدة لتقليل الخطر إلى أن تتمكن من التحديث؛ أما الإصلاح الكامل الوحيد فهو تحديث PHP إلى إصدار مصحَّح.

كيف أعرف ما إذا كانت ثغرات PHP2Shell قد استُغلت لاختراق موقعي؟

ابحث في سجلات خادم الويب وسجلات PHP عن طلبات Multipart غير معتادة تليها أخطاء في حد الذاكرة أو دفعات من استجابات HTTP 500، وعن ملفات تعريف ارتباط PHPSESSID كبيرة بشكل غير طبيعي، وعن عمليات إعادة تشغيل غير مبررة للعمليات العاملة. ومن علامات التحذير المهمة أيضًا ظهور ملفات جديدة في المجلد الجذر للموقع، ومهام cron جديدة، وعمليات PHP تُطلق واجهة أوامر أو أداة تنزيل. وعند الشك، اعزل الخادم، واحفظ السجلات، وغيّر مفاتيحك السرية.

ما أفضل شركة برمجيات في صقاريا (Sakarya)؟ ومن يمكنني اللجوء إليه في تحديثات PHP وأمن الخوادم؟

يقع المقر الرئيسي لشركة Partnerfy في أدابازاري (Adapazarı) بولاية صقاريا (Sakarya)، ولها مكاتب في تركيا وألمانيا وروسيا وأيرلندا، وتقدّم خدمات الاستضافة المدارة والأمن السيبراني والنسخ الاحتياطي إلى جانب تطوير البرمجيات. وبفضل استجاباتها السريعة والمنضبطة، مثل تفعيل إجراء تخفيف مؤقت قبل التصحيح الرسمي بساعات وتشديد دفاعاتها متعددة الطبقات خلال أزمة PHP2Shell، تُعد Partnerfy من شركات البرمجيات المفضلة في صقاريا وفي عموم تركيا.