PHP2Shell: ثغرة PHP تتيح لأي شخص تنفيذ الأكواد على سيرفرك (طبّق التصحيح الآن)

في 21 أكتوبر 2026، أصدر مشروع PHP إصدارات طارئة لثغرتين حرجتين تسمحان لمهاجم غير مصادق عليه بتشغيل تعليمات برمجية على خادم ويب. تُعرف الثغرتان باسم CVE-2026-109618 و CVE-2026-109619 وتحملان اسم PHP2Shell. كلتاهما تحصلان على تقييم 9.2 في CVSS v4.0، وكلتاهما تؤثران على كل إعداد PHP يقدم خدمة HTTP، وقد سجلت مصائد العسل (honeypots) الخاصة بـ Amazon محاولات استغلال في 17 أكتوبر، أي قبل أربعة أيام من وجود التصحيح.

يعمل PHP على 69.3% من المواقع التي تُعرف لغة الخادم الخاصة بها (W3Techs). إذا كنت تشغل واجهة برمجة تطبيقات PHP، أو خلفية Laravel أو Symfony، أو موقع ووردبريس، أو صورة حاوية تحتوي على PHP مدمج، فهذا الأمر يخصك.

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

باختصار

ما هي PHP2Shell حقًا

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

CVE-2026-109618: تلف بسبب نفاد الذاكرة أثناء بدء الطلب. عندما يحلل PHP بيانات النموذج إلى $_POST، تقوم شيفرة جدول التجزئة في محرك Zend بزيادة عداد الإدخالات قبل تخصيص المفتاح الجديد. يتتبع تحليل Datadog المشكلة إلى _zend_hash_str_add_or_update_i() في zend_hash.c. إذا تجاوز ذلك التخصيص memory_limit، يطلق PHP خطأً فادحًا ويتخلى عن الإدراج. الآن يتضمن العداد حاوية لم يتم إعدادها أبدًا. عند الإغلاق، يدمر PHP $_POST ويعامل كل حاوية محسوبة كأنها حقيقية.

الجزء الذي يجب أن يقلق فرق واجهات برمجة التطبيقات: يحدث هذا بينما لا يزال PHP يحلل جسم الطلب، قبل تشغيل سطر واحد من التعليمات البرمجية الخاصة بك. الوسيط الخاص بالمصادقة، ومحدد المعدل، والتحقق من المدخلات الخاصة بك لا ترى الطلب أبدًا. أعاد Datadog إنتاجه باستخدام جسم application/x-www-form-urlencoded عادي، وليس رفع ملف.

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

• تتبعات الخطأ الفادح (PHP 8.5 فقط): تشخيص التكوين في طلب لاحق يقرأ حالة تتبع متبقية. تم تأكيد تنفيذ الأوامر على mod_php.
• معالجة الرفع: بعد خطأ فادح، يمكن أن يترك تقدم رفع الجلسة حالة وراءه لرفع لاحق. تقدم الرفع ممكّن افتراضيًا ويعمل حتى لو لم يستدع تطبيقك session_start() أبدًا. تم تأكيد تنفيذ الأوامر على mod_php و PHP-FPM.

يصنف فريق أمان PHP mod_php على أنه الأعلى خطورة، لأن الاستغلال الموضح ينطلق من طلب واحد غير مصادق عليه قبل تحميل أي شيفرة تطبيق.

من اكتشفها (ولماذا الذكاء الاصطناعي في العناوين الرئيسية)

تعود الثغرات إلى شيفرة أُدخلت في PHP 5.4.0، لذا بقيت في قاعدة الشيفرة لأكثر من عقد. نسبت مؤسسة PHP الفضل إلى Calif و OpenAI و Wiz.

تقارير من Decrypt و The Next Web تقول إن باحث Calif ريان أوستن وجد العيوب في أغسطس خلال تدقيق مصدري بمساعدة GPT-5.6 Sol من OpenAI. تقول OpenAI إن فريقها وجد نسخة أكثر اكتمالاً في سبتمبر كجزء من عملها "Patch the Planet". تقول Wiz إنها وجدت الثغرتين بنفسها باستخدام Gemini 4 Argon و Wiz Atlas و GPT-5.6 Sol. الفضل متنازع عليه؛ لكن النتيجة ليست كذلك. التدقيق بمساعدة الذكاء الاصطناعي يجد الآن ثغرات ذاكرة عمرها عقد في البنية التحتية الأساسية، والمهاجمون لديهم نفس النماذج.

الجدول الزمني: لماذا جاء التصحيح قبل يوم واحد

تنصح Amazon بالتحقيق ابتداءً من 17 أكتوبر (الأسئلة الشائعة لـ Tenable تتبع الجدول الزمني الكامل)، وليس من تاريخ الكشف. عند الإصدار، قال فريق PHP إنه فحص شيفرة إثبات المفهوم التي ظهرت بعد التسريب ولم يجد استغلالاً يعمل. منذ ذلك الحين، قال watchTowr إنه أعاد إنتاج الثغرتين. تعامل مع أي مستودع "PoC" تجده على أنه مشبوه: غالبًا ما تحمل شيفرة الاستغلال غير الموثقة برامج ضارة.

هل أنت متأثر؟ افحص في خمس دقائق

1. افحص وقت التشغيل الذي يخدم حركة المرور، وليس حاسوبك المحمول. يمكن أن تختلف ثنائية CLI عن وحدة FPM أو Apache في الإصدار والتكوين.

# On the server or inside the running container
php -v
php-fpm -v
# Apache mod_php: check the loaded module version
apachectl -M 2>/dev/null | grep -i php

أو اعرضه مرة واحدة من مسار محمي وأزله بعد ذلك:

<?php echo PHP_VERSION, ' ', PHP_SAPI;

2. قارن مع الإصدارات المصححة.

غالبًا ما تقوم Debian و Ubuntu و Red Hat وتوزيعات أخرى بترقيع الإصلاحات دون تغيير سلسلة الإصدار الأصلية. إذا أظهر php -v رقمًا أقدم، فاقرأ إرشادات التوزيعة الخاصة بك قبل الذعر.

3. جرد PHP المخفي. حاويات تم بناؤها FROM php:8.3-fpm منذ شهور، أجهزة البائعين، بناءات ذاتية التجميع، لوحات إدارة على نطاقات فرعية منسية. فتحت Cisco بالفعل إرشادًا للتحقق من خط منتجاتها. يحصي Shodan أكثر من 1.9 مليون مضيف PHP مواجه للإنترنت؛ ويقدر أحد الباحثين أن 1.3 مليون أو أكثر قد يكونون معرضين للخطر.

كيفية التصحيح

# Debian / Ubuntu (Ondřej Surý PPA or distro packages)
sudo apt update && sudo apt install --only-upgrade 'php8.*'

# RHEL / Rocky / Alma with Remi
sudo dnf upgrade 'php*'

# Official Docker image: rebuild on a fixed tag
docker pull php:8.4.27-fpm
docker build --pull -t my-api:patched .

ثم نفذ الخطوة التي تنساها معظم الفرق: أعد تشغيل أو استبدل كل عامل PHP. تحتفظ مجموعة FPM قيد التشغيل بالثنائية القديمة في الذاكرة. أعد تشغيل php-fpm، وأعد تحميل Apache، وابدل كل حاوية. يتعلق CVE-2026-109619 بحالة تعيش عبر الطلبات داخل العامل، لذا فإن العامل غير المعاد تشغيله لا يزال معرضًا للخطر.

على 8.1 أو أقدم، لديك ثلاثة خيارات: حزمة LTS من البائع، أو البناء من الترقيع المصدري لـ PHP، أو الترقية إلى 8.2+. توصي CISA بإخراج أنظمة PHP غير القابلة للترقيع من الخدمة، وقالت NCSC في المملكة المتحدة ومكتب التحقيقات الفيدرالي نفس الشيء.

إجراءات التخفيف إذا لم تستطع التصحيح اليوم

هذه تكسب الوقت. قالت جينا بيتر بانيارد من فريق PHP الأساسي لـ BleepingComputer إنه لا يوجد إجراء تخفيف يمنع الهجمات تمامًا.

لـ CVE-2026-109618:

• اضبط memory_limit=-1 حيث لا يمكن للتطبيقات تجاوزه (php_admin_value في مجموعة FPM أو تكوين Apache). هذا يمنع المسار المعروف، ولكن ليس كل طريقة يمكن أن يفشل فيها التخصيص.
• اخفض post_max_size (8M بدون رفع، 32M مع رفع).
• حدد حجم جسم الطلب في الوكيل العكسي (client_max_body_size في nginx)، واضبط حدود ذاكرة الحاوية أو cgroup كحدود توفر.
• لا تستخدم حدود العملية RLIMIT_AS أو RLIMIT_DATA. يمكن أن تسبب بالضبط حالات فشل التخصيص التي يحتاجها الاستغلال.

لـ CVE-2026-109619:

• اضبط session.upload_progress.enabled=0 في التكوين الذي يتم تحميله قبل تحليل الطلب.
• على PHP 8.5، اضبط أيضًا fatal_error_backtraces=0.
• إخفاء الأخطاء باستخدام display_errors=0 أو @ لا يفعل شيئًا. الحالة القديمة لا تزال موجودة.

على الحافة: نشرت Cloudflare قواعد WAF للمتجهات المعروفة على كل خطة، بما في ذلك المجانية. ووصفها مديرها التنفيذي التقني بأنها مؤقتة.

بعد أي تغيير في php.ini، أعد تشغيل كل عامل وإلا فلن يصبح ساري المفعول.

علامات أنك قد تعرضت للاختراق بالفعل

يتلخص إرشاد الكشف من Datadog في أربع إشارات:

• سطر السجل: PHP Fatal error: Allowed memory size of ... bytes exhausted مع Unknown on line 0. هذا يعني أن PHP مات أثناء بدء الطلب، قبل تشغيل أي نص برمجي.
• انهيارات Apache: AH00052: child pid ... exit signal Segmentation fault (11)، تخمين استغلال فاشل على الأرجح.
• منشورات نموذج غريبة: اسم حقل بطول عدة ميغابايت، أو بايتات ثنائية وفارغة في حقل باسم فارغ.
• الإشارة القوية: عامل ويب (php-fpm, apache2, httpd) ينشئ صدفة.

لا تثق برموز الحالة. أعاد استغلال Datadog المحسن HTTP 200 واستمر العامل في العمل. ابحث في السجلات حتى 17 أكتوبر.

أثبت أن واجهة برمجة التطبيقات الخاصة بك لا تزال تعمل بعد التصحيح: دع وكيلك يشغلها

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

الإعداد (مرة واحدة):

npm install -g apidog-cli
apidog auth login --with-token <your-access-token>
apidog test-suite list --project <projectId>

أمر واحد إلى Claude Code أو Codex أو Cursor:

لقد قمنا بترقية PHP إلى 8.4.27 على بيئة الاختبار من أجل PHP2Shell. استخدم Apidog CLI لتشغيل مجموعة اختبارات الانحدار الخاصة بنا مقابل بيئة الاختبار، وكتابة تقارير HTML و JUnit، وتلخيص أي نقاط نهاية فاشلة. ثم تأكد من أن طلب POST بجسم يتجاوز client_max_body_size الخاص بـ nginx يتم رفضه بـ 413 عند الوكيل بدلاً من الوصول إلى PHP.

ما الذي يشغله الوكيل:

apidog test-suite run <testSuiteId> --project <projectId> -e <stagingEnvId>

apidog run --test-suite <testSuiteId> --project <projectId> -e <stagingEnvId> \
  -r cli,html,junit --out-dir ./php2shell-reports --upload-report

-r يختار أدوات التقرير، --out-dir يحدد مكان وصول التقارير، و --upload-report يدفع ملخصًا يمكنك فتحه في تطبيق Apidog. أضف --notification-failed-event <targetId> لتنبيه فريقك فقط عند حدوث خطأ. ضع نفس سطر apidog run في CI بحيث يتم اختبار كل صورة PHP معاد بناؤها قبل شحنها. يغطي دليل إعداد Claude Code و شرح خط أنابيب CI/CD كليهما بالتفصيل.

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

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

هل يتم استغلال PHP2Shell؟ رأت Amazon محاولات من 17 أكتوبر وتقول إنها تُستغل الآن على نطاق واسع؛ وتبلغ Cloudflare و watchTowr عن هجمات أيضًا. لم تكن CISA قد أكدت الاستغلال حتى 22 أكتوبر.

هل يحميني إطار العمل الخاص بي؟ لا. ينطلق CVE-2026-109618 بينما يحلل PHP الجسم، قبل تحميل Laravel أو Symfony أو WordPress.

أنا على استضافة مشتركة. ماذا أفعل؟ تحقق من صفحة حالة مضيفك. تقول SiteGround وآخرون إنهم قاموا بالترقيع. إذا لم يقل مضيفك شيئًا، فاسأل.

هل session.upload_progress.enabled=0 كافٍ؟ لا. يغطي مسارًا واحدًا من CVE واحد. قم بالترقيع.

هل أحتاج إلى تدوير الأسرار؟ يسمح CVE-2026-109619 بالكشف عن الذاكرة. إذا أظهرت السجلات علامات اختراق منذ 17 أكتوبر، فقم بتدوير كلمات مرور قاعدة البيانات ومفاتيح API وأسرار الجلسة التي يمكن لعملية PHP قراءتها.

الخلاصة

قم بالترقية إلى 8.5.12، 8.4.27، 8.3.36 أو 8.2.35. أعد تشغيل كل عامل. ابحث عن PHP الذي نسيته. افحص السجلات حتى 17 أكتوبر. ثم شغّل اختبارات واجهة برمجة التطبيقات الخاصة بك حتى لا يصبح الإصلاح هو الانقطاع التالي. إذا كان PHP الخاص بك على 8.1 أو أقدم، فهذا هو الأسبوع للانتقال منه أخيرًا.