PHP2Shell (CVE-2026-109618 وCVE-2026-109619): ما الذي يجب أن تفعله الشركات التي تشغّل PHP الآن

فني يعمل على حامل خوادم ومعه حاسوب محمول

في 21 أكتوبر 2026 أصدر مشروع PHP الإصدارات PHP 8.5.12 و8.4.27 و8.3.36 و8.2.35 لإصلاح ثغرتين "يمكن أن تتيحا تنفيذ الشيفرة عن بعد دون مصادقة". وبعبارة بسيطة: أي شخص يستطيع إرسال طلب HTTP إلى موقعك قد يتمكن من تشغيل شيفرته الخاصة على خادمك. لا يحتاج إلى كلمة مرور، وفي بعض الإعدادات ينجح الهجوم قبل أن ينفّذ تطبيقك سطراً واحداً. أُطلق على الثغرتين اسم PHP2Shell، ويمنح مشروع PHP كلتيهما درجة 9.2 (وفق CVSS 4.0، على مقياس من 10).

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

باختصار

حدِّث PHP نفسه، ثم أعد تشغيله. تحديث WordPress أو Drupal أو Laravel أو إحدى الإضافات لا يصلح هذه المشكلة. فالثغرة في PHP، تحت تطبيقك.
كل تثبيت PHP يخدم طلبات الويب داخل النطاق، بحسب PHP: PHP-FPM، وApache مع mod_php، وphp-cgi، وFrankenPHP، وLiteSpeed. ويصنّف PHP إعداد Apache مع mod_php على أنه الأعلى خطراً.
قرابة نصف مواقع PHP تعمل على فرع لم يعد مشروع PHP يصدر له إصدارات (وفق قراءتنا لبيانات W3Techs، أدناه). ولهذه المواقع لا توجد حزمة رسمية يمكن تثبيتها.
الإعدادات وجدران الحماية تشتري الوقت، لا الأمان. يسرد PHP تدابير مؤقتة ويقول إنها "لا تجعل التثبيت آمناً".
إن لم تستطع الترقيع اليوم، فالوكالات الأمريكية والبريطانية والأوروبية تقدم النصيحة نفسها: افصل النظام عن الإنترنت حتى تستطيع.

ما الذي حدث، بالترتيب

19 أغسطس 2026. عثر باحثو Wiz على أولى الثغرتين، بحسب إفصاحهم، وأبلغوا فريق أمن PHP بهما في 24 أغسطس. وتنسب النشرات الأمنية لـ PHP الفضل أيضاً إلى باحثين من عدة شركات أخرى.
20 أكتوبر. تسرّبت أرقام CVE على الإنترنت قبل يومين من الإفصاح المخطط له. فقدّم PHP موعد الإصدار يوماً واحداً، إلى 21 أكتوبر الساعة 14:00 UTC، وطلب من الجميع الاستعداد.
21 أكتوبر، 03:02 UTC. فعّلت Cloudflare قواعد جدار حماية لكل عملائها الذين يستخدمون جدار حماية تطبيقات الويب (WAF) لديها، بما في ذلك الخطة المجانية. وأفادت لاحقاً بأنها "رصدت حركة هجومية تستهدف عملاءنا"، وبأنها رأت المهاجمين "يحوّرون حمولة الهجوم لمحاولة تجاوز وسائل الحماية لدينا".
21 أكتوبر، نحو الساعة 14:00 UTC. نشر PHP الإصلاحات ونشرته الأمنية. وفي اليوم نفسه دعت وكالة CISA الأمريكية، والمركز الوطني للأمن السيبراني البريطاني (NCSC)، وCERT-EU المؤسساتِ إلى الترقيع فوراً، وكذلك فعل بيان مشترك صادر عن المفوضية الأوروبية وENISA وCERT-EU وEuropol وفرق الاستجابة للحوادث الأمنية الحاسوبية (CSIRT) الوطنية في دول الاتحاد الأوروبي.

ما مدى خطورتها؟

ثلاثة أمور تميّز هذه المرة عن الرقع الشهرية المعتادة.

لا يحتاج المهاجم إلا إلى طلب. لا تسجيل دخول، ولا حاجة إلى أن ينقر أحد على رابط. تصف النشرة الأمنية لـ PHP استغلالاً جرى إثباته ضد Apache مع mod_php "حيث يمكن لطلب غير مصادَق عليه أن يطلق الهجوم قبل تشغيل أي شيفرة من التطبيق". وأثبتت Wiz هجمات على إصدارات حالية من WordPress وDrupal وJoomla، وتلاحظ أن "حتى تطبيق 'Hello World' بسيط يعمل على إصدار PHP متأثر يمكن أن يكون معرَّضاً للثغرة". والشيفرة التي تُشغَّل بهذه الطريقة تحمل صلاحيات حساب خادم الويب، وهو في معظم المواقع قادر على قراءة إعدادات التطبيق: كلمة مرور قاعدة البيانات، ومفاتيح API، وبيانات اعتماد البريد والدفع. وبالنسبة للثغرة الثانية، CVE-2026-109619، يؤكد PHP أيضاً كشف محتوى الذاكرة: بيانات من ذاكرة الخادم تتسرب إلى الخارج، حتى دون تنفيذ كامل للشيفرة.

قاعدة التثبيتات هائلة. بحسب W3Techs، يشغّل PHP نسبة 69.3% من المواقع التي تُعرف لغتها من جهة الخادم (أرقام 22 أكتوبر 2026). ويحصي فريق Unit 42 التابع لـ Palo Alto Networks أكثر من 22.6 مليون نسخة مكشوفة يُحتمل أنها معرَّضة للثغرة، استناداً إلى مسحه الخاص للإنترنت، ويفيد بأن حكومة أوروبية واحدة على الأقل أوقفت موقعها الإلكتروني احترازياً.

العمل على الاستغلال يتقدم بسرعة. يفيد CERT-EU بأن أولى نماذج إثبات المفهوم (proofs of concept) "بدأت تنتشر". وتقول شركة الأمن watchTowr إن مصائد الاختراق (honeypots) لديها سجّلت استغلالاً منذ 21 أكتوبر. وتفيد Cloudflare برصد حركة هجومية. وتقول Wiz إن باحثيها استخدموا نماذج الذكاء الاصطناعي طوال العمل، فأنجز باحث واحد في أسبوع ما "كان سيستغرق من فريق عالمي المستوى شهوراً". والمهاجمون الذين يكيّفون استغلالاً مع إصدار PHP لديك يملكون الأدوات نفسها.

وإنصافاً للجانب الآخر: حين نشرت CISA تنبيهها في 21 أكتوبر، لم تكن قد رصدت أي استغلال، ولم تكن أي من الثغرتين قد أُدرجت بعد في كتالوج Known Exploited Vulnerabilities (الثغرات المستغلّة المعروفة) لديها. وتصنّف Red Hat المشكلة بدرجة "مهمة" (Important) لا حرجة، لأن خادم Red Hat Enterprise Linux القياسي يشغّل PHP-FPM، حيث الاستغلال أصعب. لكن الأصعب ليس مستحيلاً: يؤكد PHP أن أحد مسارات الثغرة الثانية يعمل على PHP-FPM أيضاً. لا شيء من هذا يغيّر ما يجب أن تفعله. إنه يغيّر فقط مقدار الإنذار المسبق الذي ستحصل عليه.

أي إصدار تستخدم؟ الأرقام

وتنشر W3Techs أيضاً إصدارات PHP التي تعمل عليها المواقع، محتسبةً المواقع التي تكشف عن إصدارها. وبالجمع بين جدوليها الصادرين في 22 أكتوبر 2026:

فرع PHP	الحصة من مواقع PHP	إصلاح من مشروع PHP
8.3 و8.4 و8.5	نحو 34%	نعم: 8.3.36 و8.4.27 و8.5.12
8.2	نحو 18%	نعم: 8.2.35. لكن 8.2 نفسه يصل إلى نهاية الدعم في 31 ديسمبر 2026
8.0 و8.1	نحو 14%	لا يوجد إصدار. 8.0 و8.1: إصلاح منقول (backport) في الشيفرة المصدرية فقط
7.x	26.9%	لا يوجد إصدار. 7.4: إصلاح منقول في الشيفرة المصدرية فقط؛ 7.3 والأقدم: لا شيء
5.x والأقدم	7.8%	لا شيء

أي إن نحو 48% من مواقع PHP تعمل على فرع لا ينشر له مشروع PHP أي إصدار مُصلَح، و18% أخرى تحصل على إصلاحها الآن وتفقد الدعم بعد عشرة أسابيع.

تحفّظان. لا ترى W3Techs إلا المواقع التي تُظهر إصدارها. وقد تكون توزيعة Linux قد رقّعت فرعاً قديماً بنفسها: وهذا ما فعلته Ubuntu، كما سترى أدناه. رقم الإصدار وحده لا يخبرك إن كنت محمياً. إصدار الحزمة لدى مورّدك هو ما يخبرك.

الخطوة 1: احصر كل نسخة PHP تشغّلها

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

أين تبحث:

المواقع والمتاجر: WordPress وWooCommerce، وDrupal، وJoomla، وMagento وAdobe Commerce، وShopware، وPrestaShop، وTYPO3، وكل ما بُني على Laravel أو Symfony.
المنسيّة: المواقع المصغّرة للحملات، ونسخة لغوية قديمة، وخوادم البيئة المرحلية والاختبار التي يمكن الوصول إليها من الإنترنت، وبريد الويب أو نظام الدعم الفني الذي ثبّته أحدهم قبل سنوات.
الحاويات: كل صورة مبنية من صورة أساس php تحمل نسخة PHP خاصة بها. وتحديث المضيف لا يفيدها في شيء.
لوحات التحكم بالاستضافة: تأتي cPanel وPlesk واللوحات المشابهة بنسخ PHP خاصة بها إلى جانب نسخة النظام. وكل إصدار مفعّل في اللوحة شيء منفصل يجب تحديثه.
منتجات بداخلها PHP: الأجهزة المتكاملة (appliances)، وأدوات المراقبة، وأنظمة إدارة علاقات العملاء (CRM)، وأنظمة الدعم الفني، وواجهات الإدارة لدى المورّدين. ويحتفظ المركز الوطني للأمن السيبراني الهولندي (NCSC) بـقائمة عامة لهذه المنتجات مع حالتها، مورّداً بعد مورّد.
المورّدون: شركة الاستضافة لديك، ووكالتك الرقمية، وأي خدمة تعرف أن PHP يعمل تحتها. اسألهم كتابةً عن إصدارات PHP التي تشغّل أنظمتك ومتى ستُرقَّع.

ولكل واحد منها، دوّن إصدار PHP، وطريقة تشغيل PHP (mod_php، أو PHP-FPM، أو LiteSpeed، أو FrankenPHP، أو حاوية)، وما إذا كان يمكن الوصول إليه من الإنترنت، ومن يستطيع ترقيعه.

الخطوة 2: رقِّع بالترتيب الصحيح

ابدأ بكل ما يمكن الوصول إليه من الإنترنت، وضمن ذلك بإعدادات Apache مع mod_php.

على فرع مدعوم (من 8.2 إلى 8.5). حدِّث إلى 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35، أو إلى حزمة توزيعتك التي تتضمن الإصلاح. يقول PHP إن توزيعات Linux تلقّت الرقع مسبقاً. المؤكد حتى الآن:

Ubuntu: حزم مُصلَحة لكل إصدار من 14.04 إلى 26.10. على 22.04 والأحدث تصل مع التحديثات العادية؛ وعلى 20.04 والأقدم تحتاج إلى اشتراك Ubuntu Pro، وهو مجاني لما يصل إلى خمسة أجهزة (إشعار Canonical).
Debian: الحزمة php8.4 بالإصدار 8.4.27 لـ Debian 13 (DSA-6574-1) والحزمة php8.2 بالإصدار 8.2.35 لـ Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: تسرد النشرة الأمنية RHSB-2026-013 من Red Hat الحزم لكل إصدار.
مستودع Remi، المستخدم على نطاق واسع للحصول على إصدارات PHP أحدث على أنظمة عائلة Red Hat: في 21 أكتوبر لاحظ CERT-EU أنه لم تكن فيه حزم في يوم الإصدار، ونصح بالتحول إلى حزم التوزيعة أو البناء من الشيفرة المصدرية. تحقق مما إذا كان قد لحق بالركب قبل أن تعتمد عليه.

على PHP 7.4 أو 8.0 أو 8.1. لا ينشر مشروع PHP أي إصدار لهذه الفروع. وقد أعدّ فريقه الأمني إصلاحات منقولة (backports) بسيطة في الشيفرة المصدرية للفروع الثلاثة، وهي تفيد إن كنت تبني PHP بنفسك. وإلا فيجب أن يأتي الإصلاح من مورّدك (يغطي Ubuntu Pro مثلاً PHP 7.4 على Ubuntu 20.04) أو من ترقية PHP. ونصيحة CISA لكل من يعمل على 8.1 أو أقدم ولا يستطيع التحديث صريحة: افصل النظام عن الشبكة حتى يُرقَّع أو تتم ترقيته.

على PHP 7.3 أو أقدم. لا يأتي شيء من مشروع PHP. وما لم يكن هناك مورّد لا يزال يرقّع نسختك، فالخيار بين الترقية وفصل النظام عن الشبكة.

أعد التشغيل بعد التحديث. تثبيت الحزمة لا يستبدل PHP الذي يعمل بالفعل. وإشعار Ubuntu يقولها بوضوح: التطبيق "سيحتاج على الأرجح إلى إعادة تشغيل". أعد تشغيل PHP-FPM أو Apache أو LiteSpeed أو الحاوية على كل خادم. ثم تحقق من الإصدار الذي يشغّله خادم الويب فعلاً، لا من php -v في سطر الأوامر وحده، فقد يكون نسخة مختلفة.

الحاويات: أعد بناء صورك من صورة أساس مرقّعة وانشرها من جديد. فالمضيف المرقّع الذي يشغّل صورة قديمة يبقى مكشوفاً.

الاستضافة المُدارة: اسأل مزوّدك عن التاريخ والإصدار، ثم تحقق بنفسك.

الخطوة 3: إن لم تستطع الترقيع اليوم

تسرد النشرة الأمنية لـ PHP تدابير مؤقتة وتقدّمها بتحذير: إنها "تقلّل التعرض لمسارات هجوم محددة لكنها لا تجعل التثبيت آمناً". وباختصار، لمن يدير خوادمك:

بالنسبة لـ CVE-2026-109618: اضبط memory_limit=-1 بحيث لا يستطيع التطبيق تغييره (مثلاً عبر php_admin_value في إعدادات pool الخاصة بـ PHP-FPM أو في إعدادات Apache)؛ واضبط قيمة منخفضة لـ post_max_size (يقترح PHP القيمة 8M دون رفع ملفات، و32M مع رفعها)؛ وقيّد حجم الطلب وعدد الحقول وأجزاء multipart على مستوى خادم الويب أو الوكيل (proxy)؛ واستخدم حداً للذاكرة على مستوى الحاوية أو cgroup، ولا تستخدم أبداً RLIMIT_AS أو RLIMIT_DATA.
بالنسبة لـ CVE-2026-109619: اضبط session.upload_progress.enabled=0 في php.ini أو في إعدادات الخادم (لا عبر ini_set() ولا عبر ملف .user.ini) وأعد تشغيل كل العمليات العاملة (workers). وعلى PHP 8.5، اضبط أيضاً fatal_error_backtraces=0.

تحذيران. إعداد الجلسة الذي انتشر على نطاق واسع في 20 أكتوبر يغلق مسارات الثغرة الثانية فقط، كما أوضح أحد أعضاء الفريق الأمني لـ PHP؛ ولا يفعل شيئاً ضد الأولى. كما أن memory_limit=-1 يزيل الحد الأقصى للذاكرة الخاص بـ PHP نفسه، فيصبح بإمكان طلب ثقيل واحد أن يستنفد موارد الخادم. اقرنه بحد الذاكرة على مستوى الحاوية أو cgroup.

جدار حماية تطبيقات الويب يساعد، قليلاً. قواعد Cloudflare مفعّلة افتراضياً في كل خطة تتضمن جدار حماية تطبيقات الويب لديها، بما فيها الخطة المجانية، كما نشرت Palo Alto Networks ومورّدون آخرون وسائل حماية خاصة بهم. ومع ذلك تطلب Cloudflare من عملائها ترقيع PHP "حتى مع وجود حماية WAF"، وقد شاهدت المهاجمين يغيّرون حمولاتهم للتسلل عبر قواعدها. كما أن WAF لا يحمي إلا الحركة التي تمر عبره. فإن كان خادمك يستجيب على عنوان IP الخاص به مباشرة، يستطيع المهاجم الالتفاف حوله.

إن تعذّر فعل أي من ذلك بسرعة، فإن CISA وCERT-EU وNCSC والبيان الأوروبي المشترك تشير كلها في الاتجاه نفسه: افصل النظام عن الإنترنت العام حتى يُصلَح. صفحة صيانة ليوم واحد تكلّف أقل من خادم يُعاد بناؤه.

الخطوة 4: تحقق مما إذا كنت قد تعرّضت للاختراق بالفعل

انفتحت نافذة الخطر في 20 أكتوبر، حين بدأ التسريب، وأُبلغ عن حركة هجومية صباح اليوم التالي. فإن كان نظام ما قابلاً للوصول وغير مرقّع خلال تلك النافذة، فإن الترقيع يغلق الباب لكنه لا يخبرك إن كان أحدهم قد دخل أولاً. ويطلب NCSC من كل من لم يستطع الترقيع فوراً أن يبحث عن علامات الاختراق والأبواب الخلفية.

ما الذي تبحث عنه، وفق الإرشادات المنشورة وممارسات الاستجابة للحوادث المعتادة:

عمليات PHP تفعل ما لا يفعله PHP أبداً، مثل تشغيل واجهة أوامر (shell) أو تنزيل أدوات (CISA).
طلبات multipart غير معتادة تليها أخطاء حد الذاكرة أو استجابات HTTP 500 متكررة، وإعادة تشغيل العمليات العاملة لـ PHP دون سبب واضح، وملفات تعريف ارتباط PHPSESSID كبيرة على نحو غير معتاد أو مشوّهة في الاستجابات (Wiz).
ملفات PHP جديدة أو معدّلة في مجلدات الرفع أو مجلدات التخزين المؤقت أو المجلد الجذر للموقع (web root)، وحسابات مسؤول جديدة في نظام إدارة المحتوى لديك، ومهام مجدولة لم ينشئها أحد.

السجلات النظيفة ليست دليلاً. فالنشرة الأمنية لـ PHP الخاصة بالثغرة الثانية تحذّر من هذا تحديداً، وتلاحظ Wiz أن سجلات التطبيق قد لا تحمل إلا قليلاً من السياق.

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

الخطوة 5: ما الذي قد يتعين عليك الإبلاغ عنه

الثغرة وحدها ليست حادثاً يستوجب الإبلاغ. أما الثغرة المستغلّة فقد تكون كذلك.

NIS2: إن كانت مؤسستك مشمولة وكان الاختراق حادثاً جسيماً، فيجب إرسال الإنذار المبكر إلى فريق CSIRT الوطني لديك خلال 24 ساعة. راجع دليلنا لـ NIS2.
اللائحة العامة لحماية البيانات (GDPR): إن جرى الوصول إلى بيانات شخصية، فيجب إخطار الجهة الرقابية خلال 72 ساعة من علمك بالخرق، ما لم يكن من غير المرجح أن يعرّض الأفراد للخطر. راجع دليلنا للائحة العامة لحماية البيانات.
قانون المرونة السيبرانية: إن كنت تبيع برمجيات أو جهازاً بداخله PHP، فأنت مصنّعه بموجب قانون المرونة السيبرانية. ومنذ 11 سبتمبر 2026 بات على المصنّعين الإبلاغ عن الثغرات المستغلّة فعلياً في منتجاتهم عبر منصة الإبلاغ الموحدة لقانون المرونة السيبرانية، كما يذكّر البيان الأوروبي المشترك. راجع دليلنا لقانون المرونة السيبرانية.
عملاؤك: إن كنت تستضيف PHP أو تشغّله لعملاء، فسيسألونك. مذكرة مكتوبة قصيرة (ما الذي تشغّله، ومتى رُقِّع، وما الذي تحققت منه) تجيب عن معظم أسئلتهم، وهي المذكرة نفسها التي سيطلب رؤيتها المدقق أو شركة التأمين السيبراني.

بعد حالة الطوارئ: ما الذي يجب تغييره

على معظم الخوادم المُدارة جيداً سيُرقَّع PHP2Shell خلال أيام. لكن ما كشفه عن إعداداتك سيظل صحيحاً بعد ذلك.

اعرف كم يستغرق منك الترقيع. من النشرة الأمنية إلى إعادة تشغيل كل خادم: ساعات أم أيام أم أسابيع؟ إن كانت الإجابة الصادقة "سنحتاج إلى سؤال الوكالة الرقمية"، فأصلح ذلك قبل الثغرة التالية. وحين يقول الباحثون إن الذكاء الاصطناعي اختصر عملهم على الاستغلال من شهور إلى أسبوع، فافترض أن المهاجمين يستطيعون التحرك بهذه السرعة أيضاً.
احتفظ بقائمة الجرد التي بنيتها للتو. كانت أصعب جزء في الاستجابة، وتصبح قديمة في اللحظة التي لا يتولى فيها أحد مسؤوليتها.
تخلّص من إصدارات PHP المنتهية الدعم. موقع على 7.4 أو 8.1 احتاج هذه المرة إلى مورّد أو إلى إصلاح منقول في الشيفرة المصدرية؛ وفي المرة القادمة قد لا يتوفر أي منهما. يصل PHP 8.2 إلى نهاية دعمه في 31 ديسمبر 2026، لذا على الموقع الذي يغادر 8.1 أن ينتقل مباشرة إلى 8.3 أو أحدث. وكثيراً ما يعني تغيير إصدار PHP تحديث التطبيق أيضاً: يبيّن مقالنا عن نهاية دعم Drupal وUmbraco وKentico ما يتضمنه ذلك لنظام إدارة محتوى واحد.
فضّل PHP-FPM على mod_php حيثما استطعت. فقد كان الإعداد الأقل خطراً هذه المرة.
أبقِ ميزة تقدّم الرفع (upload progress) معطّلة إن لم تكن تستخدمها. تقترح النشرة الأمنية لـ PHP إبقاء session.upload_progress.enabled معطّلاً حتى بعد الترقيع إن لم يكن التطبيق يحتاج إليه.
اكتب مدد الترقيع في عقودك. اسأل مزوّد الاستضافة ووكالتك الرقمية عن سرعة تطبيقهما لإصلاحات PHP الحرجة، واحصل على الإجابة كتابةً.

قائمة تحقق لهذا الأسبوع

أدرج كل تثبيت PHP، بما في ذلك الحاويات ولوحات التحكم ومنتجات المورّدين وخوادم البيئة المرحلية.
رقِّع الأنظمة المكشوفة على الإنترنت أولاً، بدءاً بـ Apache مع mod_php.
أعد تشغيل كل عمليات PHP وتحقق من الإصدار الذي يُبلغ عنه خادم الويب.
أعد بناء صور الحاويات وانشرها من جديد.
حيث لا تستطيع الترقيع اليوم، طبّق الإعدادات المؤقتة التي يقترحها PHP، أو مرّر الحركة عبر WAF، أو افصل النظام عن الشبكة.
اطلب من المورّدين ومزوّدي الاستضافة إصدار PHP لديهم وتاريخ الترقيع، كتابةً.
راجع السجلات وتغييرات الملفات على كل ما كان مكشوفاً وغير مرقّع منذ 20 أكتوبر.
قرّر ما إذا كان أي التزام بالإبلاغ (NIS2، أو اللائحة العامة لحماية البيانات، أو قانون المرونة السيبرانية) ينطبق عليك.
خطّط للانتقال من PHP 8.1 وما قبله، ومن 8.2 قبل 31 ديسمبر.

أين يمكننا المساعدة

لا ينقص معظم الشركات الرغبة في الترقيع. ما ينقصها صورة واضحة عمّا تشغّله، أو الأشخاص الذين ينجزون العمل هذا الأسبوع. وهذا هو الجزء الذي نتولاه:

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

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

راسلنا على office@c9group.dev مع وصف لما تشغّله، وسنرد عليك بما كنا سنفعله أولاً.

المصادر

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

مشروع PHP

الوكالات

الباحثون والمورّدون والبيانات