آخر تحديث: 21 أكتوبر 2026 — هذا التنبيه حيّ وسيُحدَّث مع ظهور معلومات جديدة. راجع قسم «سجل التحديثات» في نهاية المقال.

الاسم الشائعPHP2Shell
المعرّفاتCVE-2026-109618 (GHSA-w8hw-w9fx-j79w)
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)
الخطورةحرجة — CVSS v4.0: 9.2 لكل ثغرة
المتجهCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
نوع الأثرتنفيذ أوامر عن بُعد (RCE) دون مصادقة بصلاحيات مستخدم خادم الويب، وتسريب محتوى ذاكرة عمليات PHP
المنتج المتأثرمُفسّر PHP نفسه (php-src) — وليس تطبيقًا أو إضافة بعينها
الإصدارات المُصلِحة8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
حالة الاستغلالتقارير متعددة من جهات أمنية عن استغلال فعلي؛ غير مدرجة في كتالوج CISA KEV حتى الآن
الأولويةعاجلة جدًا — التحديث فورًا

الملخص التنفيذي

في 21 أكتوبر 2026 أصدر فريق أمن PHP تحديثات طارئة لمعالجة ثغرتين حرجتين في مُفسّر PHP ذاته، اشتهرتا باسم PHP2Shell. تسمح الثغرتان لمهاجم غير مصادَق بتنفيذ شيفرة على الخادم عبر الشبكة بصلاحيات حساب عامل الويب، دون أي تفاعل من المستخدم. ولأن الخلل في محرك اللغة نفسه، فإن تحديث ووردبريس أو Laravel أو Drupal أو Magento وحده لا يكفي؛ المطلوب هو تحديث نسخة PHP على الخادم.

تكتسب هذه الثغرات أهمية استثنائية بسبب حجم الانتشار: PHP يشغّل قرابة 69% من المواقع التي تُعرف لغة الخادم فيها بحسب W3Techs، ورصدت Palo Alto Networks عبر Cortex Xpanse أكثر من 22.6 مليون نسخة مكشوفة قد تكون متأثرة. كما أفادت Cloudflare وwatchTowr وPatchstack وAikido برصد محاولات استغلال فعلية بعد ساعات من الكشف، واتخذت حكومة أوروبية واحدة على الأقل قرارًا احترازيًا بإيقاف موقعها مؤقتًا.

الخط الزمني

  • 20 أكتوبر 2026: تسرّب معلومات عن الثغرتين ومعرّفاتهما عبر Hacker News ووسائل التواصل قبل موعد الإفصاح المنسّق، مع لقطات ومقطع فيديو لأداة استغلال باسم PHP2Shell.
  • 20 أكتوبر 2026 (مساءً بتوقيت UTC): فريق أمن PHP ينشر إشعارًا مسبقًا بإصدار أمني طارئ، وCERT-EU ينشر التنبيه 2026-018.
  • 21 أكتوبر 2026 — 14:00 UTC (5:00 مساءً بتوقيت الرياض): صدور الإصدارات المُصلِحة 8.5.12 و8.4.27 و8.3.36 و8.2.35، ونشر استشارتي GitHub الرسميتين.
  • 21 أكتوبر 2026: تقارير عن استغلال فعلي، ونشر قواعد WAF مؤقتة من Cloudflare، وتحذيرات من NCSC البريطاني وUnit 42 وTenable وغيرها.
  • 22 أكتوبر 2026: كان الموعد الأصلي للإفصاح المنسّق قبل أن يُقدَّم بسبب التسريب.

التفاصيل التقنية

CVE-2026-109618 — تنفيذ أوامر عبر إفساد الذاكرة عند نفادها (OOM Corruption)

يستخدم PHP آلية longjmp() للخروج الفوري من السياق الحالي عند حدوث خطأ نفاد الذاكرة (Out-of-Memory). المشكلة أن ذاكرة الطلب تكون أحيانًا «مكشوفة» قبل اكتمال تهيئتها؛ فإذا فشلت أي عملية حجز ذاكرة في تلك اللحظة — حتى لو لم تكن مرتبطة بها — يبقى جزء من بيانات الطلب في حالة غير صالحة، ثم تتعامل معه إجراءات إنهاء الطلب (Shutdown) وكأنه سليم، ما يمهّد لتنفيذ شيفرة عن بُعد.

ووفق الاستشارة الرسمية، يمكن للمهاجم دفع الطلب إلى نفاد الذاكرة وهو ما يزال ضمن الحدود الظاهرة لإعدادات PHP، عبر أساليب تتعلق بتحليل طلبات multipart/form-data (مثل طلبات بلا طول محتوى صالح، أو أجزاء بعدد ضخم من الترويسات، أو حقول ملفات فارغة متداخلة الأسماء). والأخطر أن ذلك يحدث في Apache mod_php أثناء بدء الطلب وقبل تنفيذ أي سطر من شيفرة التطبيق. وقد تحقّق فريق PHP من تنفيذ أوامر كامل عبر HTTP ضد mod_php بالإعدادات الافتراضية.

CVE-2026-109619 — تنفيذ أوامر عبر حالة عامة متبقية (Stale Global State)

يحتفظ عامل PHP (Worker) بحالة عامة — مثل حالة الأخطاء والجلسات والكائنات والإضافات — قد تشير إلى ذاكرة يملكها طلب سابق. يُفترض تصفير هذه الحالة قبل تحرير ذاكرة الطلب، لكن خطأً قاتلًا (بما فيه نفاد الذاكرة أو تجاوز مهلة التنفيذ) قد يقطع العملية قبل التصفير. وعندما يعالج العامل نفسه طلبًا لاحقًا، قد تقرأ بعض العمليات المبكرة — التي تعمل قبل التهيئة الطبيعية للطلب — تلك الحالة القديمة، فتنشأ ثغرة استخدام بعد التحرير (Use-After-Free) قابلة للتحويل إلى تنفيذ أوامر كامل.

يتطلب الاستغلال «مُنتِجًا» يترك الحالة معلّقة في طلب، و«مستهلِكًا» يقرؤها في طلب لاحق يصل إلى العامل نفسه. ومن المسارات المؤكدة رسميًا:

  • ميزة تتبّع تقدّم رفع الملفات في الجلسة (session.upload_progress): مفعّلة افتراضيًا، ولا تحتاج إلى استدعاء session_start() من التطبيق. تحقّق فريق PHP من تنفيذ الأوامر عبرها ضد mod_php وPHP-FPM.
  • تتبّع الأخطاء القاتلة في PHP 8.5 (fatal_error_backtraces): وهو أقوى مسار مُثبت، وأساس الاستغلال المؤكد ضد mod_php.
  • تحذيرات إعدادات INI المطبّقة قبل بدء الطلب: مثل إعدادات .htaccess وphp_value في Apache، أو معاملات PHP_VALUE التي يمررها nginx إلى FPM. ومهم جدًا: تغيير error_reporting أو استخدام @ أو تعطيل display_errors لا يحمي من هذه الثغرة.

تصنيفات الضعف (CWE) للثغرتين: CWE-416 (استخدام بعد التحرير)، CWE-755، CWE-824، CWE-1325، CWE-1419.

من المتأثر؟

كل إصدارات PHP غير المُحدَّثة التي تخدم طلبات ويب، وتشير التقارير إلى أن الخلل قائم منذ PHP 5 تقريبًا. ويختلف مستوى الخطر حسب طريقة تشغيل PHP (SAPI):

بيئة التشغيلمستوى الخطرملاحظات
Apache + mod_phpالأعلىاستغلال مؤكد للثغرتين، ويمكن تنفيذه قبل وصول الطلب إلى شيفرة التطبيق
PHP-FPM (nginx / Apache proxy_fcgi)مرتفعمسار رفع الملفات في الجلسة مؤكد ضد FPM؛ ومعاملات PHP_VALUE الممررة من الواجهة تزيد التعرض
FrankenPHPمرتفع (مرجّح)يستدعي إنهاء الطلب دون شرط مثل mod_php وفق التحليل الرسمي
LiteSpeed (LSAPI) وphp-cgiمشروطاستغلال مرجّح بحسب التطبيق والإعدادات، ولم يُثبت بالكامل

الإصدارات المتأثرة والمُصلِحة

الفرعمتأثرالإصدار المُصلِح
PHP 8.5أقدم من 8.5.128.5.12
PHP 8.4أقدم من 8.4.278.4.27
PHP 8.3أقدم من 8.3.368.3.36
PHP 8.2أقدم من 8.2.358.2.35
PHP 8.1 / 8.0 / 7.4متأثر (منتهي الدعم)لا إصدار رسمي؛ نشر فريق PHP ترقيعات مصدرية مختصرة لمن يبني من المصدر، أو اعتمد على حزم توزيعتك/مزوّد الدعم الممتد
PHP 7.3 وما قبله و5.xمتأثر (منتهي الدعم)لا يوجد إصلاح — الترقية أو العزل

حصلت توزيعات لينكس ومزودو الدعم طويل الأمد على الترقيعات قبل الإصدار العام، لذا تحقّق من حزم توزيعتك (Ubuntu، Debian، RHEL وغيرها) إذ قد يُنقَل الإصلاح إلى حزم برقم إصدار أقدم ظاهريًا. ونُبّه مستخدمو مستودع remirepo إلى أن التحديثات لم تكن متاحة فيه يوم الإصدار.

حالة الاستغلال

  • Cloudflare: أعلنت رصد بدايات هجمات، ونشرت قواعد WAF لجميع العملاء بما فيهم المجانيون، مؤكدة أنها حل مؤقت فقط.
  • watchTowr: أعلنت إعادة إنتاج CVE-2026-109618، ثم رصد استغلال فعلي عبر شبكة مصائدها (Honeypots).
  • Patchstack وAikido: أفادتا بحوادث استغلال نشطة.
  • CISA KEV: لم تُدرَج الثغرتان بعد حتى وقت كتابة هذا التنبيه.
  • شيفرات إثبات المفهوم (PoC): تنتشر علنًا شيفرات وأبحاث تزعم استغلال الثغرتين، بعضها يركز على مسار session.upload_progress. ننبّه إلى أن الشيفرات غير الموثقة قد تحتوي برمجيات خبيثة، ويجب ألا تُختبر إلا في بيئات معزولة ومصرّح بها.

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

مؤشرات الاختراق (IOCs) ومؤشرات الكشف

الوضع الحالي: حتى مساء 21 أكتوبر 2026 لم تنشر أي جهة رسمية (فريق PHP أو CERT-EU أو CISA) مؤشرات اختراق خاصة بثغرتي PHP2Shell، وأكدت كل من Huntress وSOC Prime وBrandefense عدم وجود عناوين IP أو بصمات ملفات أو نطاقات مؤكدة مرتبطة بحملة استغلال بعينها. لذلك نجمع هنا ما شاركته جهات استخبارات التهديدات، مع توضيح درجة الثقة في كل منها، وسنحدّث هذا القسم فور نشر مؤشرات مؤكدة.

1. قائمة Team Cymru لعناوين IP النشطة في الاستغلال

نشر فريق أبحاث Team Cymru عبر حسابه @teamcymru_S2 تنبيهًا استخباراتيًا (INTEL DROP) بعنوان PHP2SHELL، يتضمن 1,187 عنوان IP صنّفتها منصة Total Insights بأنها «نشطة في الاستغلال» بدرجة ثقة 90 فأعلى. هذه العناوين تستهدف حاليًا ثغرات معروفة في Ivanti وJoomla وLaravel وXWiki وWebmin وphpunit وغيرها، ويرجّح الفريق أن الجهات الانتهازية نفسها ستتبنى أي شيفرة استغلال لـ PHP2Shell فور توفرها.

عينة من أول العناوين في القائمة:

عنوان IPالمصدرالتصنيف
1.95.73.195Team Cymruنشط في الاستغلال (90+)
102.201.110.181Team Cymruنشط في الاستغلال (90+)
102.244.97.185Team Cymruنشط في الاستغلال (90+)

تنبيه حول الثقة: هذه القائمة تمثل بنية تحتية لاستغلال انتهازي واسع، وليست مؤشرات مؤكدة لاستغلال PHP2Shell تحديدًا. يُنصح باستخدامها للحظر الاستباقي والمراقبة ورفع أولوية التنبيهات، لا كدليل قاطع على الاختراق. القائمة الكاملة متاحة في منشور Team Cymru الأصلي.

2. مؤشرات على مستوى طلبات HTTP

بناءً على الاستشارات الرسمية وتحليل الشيفرات المنشورة، أصدر فريق ASTRO في Abstract Security قواعد كشف تطابق الأنماط التالية:

الثغرةالنمط المشبوهالثقة
CVE-2026-109619طلبات multipart/form-data صغيرة تحتوي PHPSESSID كحقل نموذجعالية
CVE-2026-109619وسوم PHP مثل <?php أو <?= داخل اسم الملف المرفوععالية
CVE-2026-109619صيغة كائنات مسلسلة (Serialized) داخل اسم الملف المرفوععالية
CVE-2026-109619وجود الحقل PHP_SESSION_UPLOAD_PROGRESS (للربط والتحليل فقط، قد يكون استخدامًا مشروعًا)منخفضة
CVE-2026-109618أسماء حقول نموذج بطول 1000 بايت أو أكثر (urlencoded أو multipart)عالية
CVE-2026-109618ترويسات Content-Disposition مطوية أو طلبات POST كبيرة (تقارب 1MB أو أكثر) إلى صفحات PHPمتوسطة
كلتاهمادفعات كثيفة من طلبات POST من مصدر واحد إلى المسار نفسه، أو بترويسة User-Agent فارغة أو غير معتادةمتوسطة

3. مؤشرات في سجلات الخادم

  • أخطاء PHP قاتلة تحتوي على in Unknown on line 0 (خطأ من سكربت غير معروف).
  • أخطاء Allowed memory size ... exhausted مقترنة باستجابات 200 لطلبات POST كبيرة.
  • رسائل AH00052 في سجل أخطاء Apache (انهيار عامل بسبب Segmentation Fault)، خصوصًا إذا تكررت بالتزامن مع طلبات POST كبيرة من عنوان واحد.
  • تكرار «Maximum execution time exceeded» أو تحذيرات INI قبل تنفيذ السكربتات.

4. مؤشرات على مستوى النظام (ما بعد الاستغلال)

الفئةما يجب رصده
العملية الأمphp-fpm، php-cgi، php-cgi.exe، httpd، apache2
العمليات الفرعية المشبوهةsh، bash، cmd.exe، powershell.exe، python، perl، curl، wget، nc، socat، certutil.exe
أنماط سطر الأوامر/dev/tcp/، mkfifo، fsockopen، base64 -d
أوامر الاستطلاعwhoami، id، uname -a، ipconfig
الشبكةاتصالات TCP صادرة مُنشأة من عمليات PHP أو خادم الويب
الاستمراريةملفات .php جديدة خلال آخر 48 ساعة في /var/www أو public_html أو مجلدات الرفع والملفات المؤقتة، مهام cron جديدة، مستخدمون جدد (UID ≥ 1000)، تعديلات حديثة على authorized_keys

5. تواقيع وقواعد كشف متاحة

  • Palo Alto Networks: توقيع Threat Prevention رقم 543004 (متاح منذ 20 أكتوبر 2026).
  • Cloudflare: قواعد WAF مُدارة لجميع العملاء بما فيهم الخطة المجانية.
  • Abstract Security: قواعد Suricata (SID 1001201–1001204 لـ CVE-2026-109619، وSID 1001103–1001107 لـ CVE-2026-109618) وقواعد ModSecurity (3201001–3201004 و3101004–3101009). يُنصح بتشغيلها في وضع التسجيل أولًا قبل الحظر.
  • Tenable: إضافات Nessus لاكتشاف نسخ PHP غير المدعومة (48243، 58987، 200476، 216936) مع إضافات مخصصة للثغرتين على صفحات CVE.

الإجراءات الموصى بها

1. التحديث فورًا (الحل الوحيد الكامل)

  1. حصر جميع نسخ PHP في البيئة: الخوادم، الحاويات، صور Docker، لوحات الاستضافة (cPanel/Plesk)، والأجهزة والتطبيقات التي تضمّن PHP داخليًا.
  2. التحقق من الإصدار عبر php -v وكذلك من خلال صفحة الويب نفسها، لأن نسخة سطر الأوامر قد تختلف عن نسخة خادم الويب.
  3. الترقية إلى 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35، أو تثبيت حزمة التوزيعة المُصلِحة، مع البدء بالأنظمة المكشوفة على الإنترنت.
  4. إعادة تشغيل PHP-FPM أو خادم الويب بعد التحديث لضمان تحميل النسخة الجديدة في كل العمّال.
  5. إعادة بناء صور الحاويات ونشرها، وعدم الاكتفاء بتحديث الخادم المضيف.

2. إجراءات تخفيف مؤقتة (لمن لا يستطيع التحديث فورًا)

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

  • تعطيل تتبّع تقدّم الرفع: session.upload_progress.enabled=0 — ويوصي فريق PHP بإبقائه معطّلًا حتى بعد التحديث إن لم تكن تحتاجه.
  • في PHP 8.5: fatal_error_backtraces=0 لإزالة مسار الاستغلال المؤكد ضد mod_php.
  • لـ CVE-2026-109618: يذكر فريق PHP أن ضبط memory_limit=-1 هو التخفيف الأساسي عبر الإعدادات، لكنه جزئي ويرفع خطر حجب الخدمة باستهلاك الذاكرة؛ إن اعتمدته فضع حدًا للذاكرة على مستوى الحاوية/cgroup. وتجنّب استخدام RLIMIT_AS أو RLIMIT_DATA لأنهما يفعّلان المسار المعرّض.
  • تقييد طلبات multipart/form-data: إبقاء post_max_size متحفظًا، وتقليل max_input_nesting_level، وتحديد عدد المتغيرات والأجزاء والترويسات والملفات المرفوعة، وحظر طلبات multipart في الواجهة الأمامية إن لم يكن التطبيق يحتاجها.
  • نقل إعدادات PHP إلى php.ini أو إعدادات مجمع FPM بدل التجاوزات لكل طلب (.htaccess وPHP_VALUE)، وإزالة التوجيهات القديمة أو المهملة التي تولّد تحذيرات.
  • عند عدم أهمية الأداء: pm.max_requests=1 في FPM لتقليل إعادة استخدام العامل بين الطلبات.
  • تفعيل قواعد WAF (مثل Cloudflare أو توقيع Palo Alto 543004) كطبقة مؤقتة.
  • إذا تعذّر كل ما سبق: عزل التطبيقات المكشوفة عن الإنترنت أو وضعها خلف VPN، كما توصي CERT-EU وNCSC البريطاني.

3. الكشف والاستجابة

يحدث الاستغلال تحت طبقة التطبيق، وقد يعيد الخادم استجابة طبيعية (200 OK) دون أثر واضح في سجلات التطبيق، لذا ركّز على سلوك ما بعد الاستغلال:

  • تنبيه عند قيام عمليات php-fpm أو php-cgi أو apache2/httpd بتشغيل أصداف (sh/bash) أو مفسّرات (python/perl) أو أدوات تنزيل (curl/wget) أو أدوات شبكية (nc/socat).
  • مراقبة الاتصالات الصادرة غير المتوقعة من خوادم الويب.
  • البحث عن ملفات جديدة أو معدّلة في مجلدات الويب (Web Shells)، ومهام cron جديدة، وحسابات غير معروفة.
  • رصد طلبات multipart غير معتادة إلى مسارات لا تستقبلها عادةً، وتكرار أعطال العمّال (Segfault) أو أخطاء نفاد الذاكرة و«Maximum execution time exceeded».
  • تذكّر أن سجلات Apache الافتراضية لا تسجّل ترويسة Content-Type، وأن غياب الأخطاء في السجلات ليس دليلًا على السلامة.
  • مراجعة القياسات خلال الأيام 7–14 الماضية على الأقل، وعند وجود مؤشرات اختراق: عزل الخادم، حفظ الأدلة، والانتقال إلى الاستجابة للحوادث بدل الاكتفاء بالتحديث.

توصيات خاصة لبيئات ووردبريس والاستضافة المشتركة

  • تحديث ووردبريس والإضافات لا يعالج هذه الثغرة؛ تواصل مع مزود الاستضافة للتأكد من تحديث PHP وإعادة تشغيله.
  • تحقق من نسخة PHP عبر «أدوات ← صحة الموقع ← معلومات» في لوحة تحكم ووردبريس.
  • المواقع على PHP 7.x أو 8.0 أو 8.1 يجب ترقيتها إلى فرع مدعوم في أقرب وقت، فهي خارج نطاق الإصلاحات الرسمية.

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

المراجع

سجل التحديثات

  • 21 أكتوبر 2026 (22:30 بتوقيت الرياض): إضافة قسم «مؤشرات الاختراق (IOCs) ومؤشرات الكشف»، ويشمل قائمة Team Cymru لعناوين IP النشطة في الاستغلال، وأنماط الطلبات والسجلات، ومؤشرات ما بعد الاستغلال، والتواقيع المتاحة.
  • 21 أكتوبر 2026: النشر الأول للتنبيه بعد صدور الإصدارات المُصلِحة والاستشارات الرسمية.