PHP2Shell: أين تقع ثغرتا PHP وكيف تعالجهما؟

PHP2Shell هو الاسم المتداول لثغرتين خطيرتين في محرك PHP نفسه: CVE-2026-109618 وCVE-2026-109619. ترتبط الأولى بنفاد الذاكرة، والثانية ببقاء حالة داخلية بعد تحرير الذاكرة التي تعتمد عليها. صدرت التحديثات الأمنية في 21 أكتوبر 2026. المطلوب من مشغّل الموقع تحديث PHP واستبدال عمليات التشغيل القديمة؛ تحديث WordPress أو حزم Composer وحده لا يُكمل الإصلاح.

هذا دليل للمطورين ومسؤولي الخوادم يشرح أين يقع الخلل، وما الفرق بين الثغرتين، وكيف تنفذ التحديث وتتأكد من وصوله إلى جميع النسخ. جرى التحقق من المصادر في 23 أكتوبر 2026. تفاصيل الثغرات والإصدارات حقائق من المراجع الأولية المرفقة، أما خطة النشر ومعايير الإغلاق فهي توصيات هندسية.

أين تقع المشكلة بالضبط؟

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

توضح مؤسسة PHP أن الخلل يمس إدارة الذاكرة والأخطاء في المحرك. ويوجد مسار استغلال مثبت مع Apache mod_php يحدث قبل تشغيل التطبيق. لذلك قد يصل فحص تسجيل الدخول داخل Controller متأخرًا عن المرحلة المعرضة للهجوم؛ لقد بدأ المحرك معالجة الإدخال بالفعل.

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

الثغرة الأولى: CVE-2026-109618 ونفاد الذاكرة

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

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

الثغرة الثانية: CVE-2026-109619 والحالة المتبقية

بحسب نشرة الحالة العامة المتبقية، يمكن للعامل الاحتفاظ بحالة تخص طلبًا انتهى وتحررت ذاكرته. قد يمنع انقطاع التنفيذ إعادة ضبطها، ثم يستخدمها طلب لاحق على العامل نفسه قبل التهيئة الطبيعية. هذا استخدام للذاكرة بعد تحريرها، أو Use-after-free.

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

ما البيانات الداخلية التي تتأثر؟

يسمي بحث Wiz الأصلي أمثلة محددة: حالة معرّف الجلسة PS(id)، وبيانات متتبع فك التسلسل BG(unserialize)، وحالة تتبع الخطأ EG(last_fatal_error_backtrace). هذه أسماء داخل محرك PHP، وليست أعمدة قاعدة بيانات في موقعك.

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

الإصدارات المتأثرة والتحديثات المطلوبة

تحدد إعلانات PHP الرسمية الإصدارات الأمنية التالية:

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

تصنف CERT-EU الثغرتين بدرجة حرجة 9.2 وفق CVSS v4.0، وتشمل قائمة التعرض PHP-FPM وmod_php وCGI وFrankenPHP وLiteSpeed. لا تحصر الجرد في نظام إدارة محتوى واحد.

انتبه: رقم إصدار أقدم قد يتضمن الإصلاح

تحتفظ بعض التوزيعات برقم أساس قديم وتنقل التصحيح إليه. مثلًا، تسجل نشرة Ubuntu USN-8948-1 الحزمة 8.3.6-0ubuntu0.24.04.13 لـUbuntu 24.04 والحزمة 8.1.2-1ubuntu2.28 لـUbuntu 22.04 ضمن الحزم المصححة.

قارن رقم الحزمة كاملًا بالنشرة الخاصة بتوزيعتك ومستودعها. المقارنة الحسابية مع رقم PHP الأصلي وحدها قد تعطي نتيجة خاطئة. وكذلك عبارة «آخر إصدار متاح» لا تكفي إذا كان المستودع المستخدم لم يوفر التصحيح أصلًا.

افحص PHP الذي يخدم الزوار فعلًا

ابدأ بجرد للقراءة فقط. توثق خيارات سطر أوامر PHP فحص الإصدار والإعدادات والامتدادات:

command -v php
php -v
php --ini
php -m
php -r 'printf("PHP=%s SAPI=%s\n", PHP_VERSION, PHP_SAPI);'

هذه النتائج تخص برنامج CLI الذي استدعيته. قد يكون محدثًا بينما يعمل الموقع عبر FPM أقدم، أو وحدة Apache مختلفة، أو حاوية لم تُبنَ مجددًا. سجّل لكل نطاق مسار الخدمة الفعلي، ومقبس FPM أو الوحدة، ومصدر الحزمة، والإصدار، ومعرّف النسخة وصورة الحاوية.

في مثال Ubuntu 24.04 مع PHP 8.3 يمكن فحص الحزم هكذا:

dpkg-query -W 'php8.3*' 'libapache2-mod-php8.3'
apt-cache policy php8.3-fpm libapache2-mod-php8.3

عدّل الأسماء بحسب بيئتك. تحقق من واجهة تشغيل الويب عبر قناة عمليات خاصة أو تشخيص داخلي يمر بمسار الخدمة الحقيقي، ويعيد فقط الإصدار وSAPI وهوية النسخة. لا تترك صفحة phpinfo() عامة، ولا تنشر إعدادات قد تحتوي أسرارًا.

خطة التحديث والتحقق من جميع النسخ

استخدم التسلسل التالي كخطة تشغيلية:

1. احصر التعرض: النطاقات البديلة، ومواقع المعاينة، وVirtual Hosts القديمة، والوصول المباشر إلى الأصل، والنسخ الموجودة خارج موازن الحمل الرئيسي.
2. اختر بناءً موثوقًا: طابق الثغرتين مع إصدار PHP مصحح أو نشرة المورد المناسبة، وتحقق من توافق الامتدادات.
3. جهز الاستعادة: انسخ بيانات التطبيق وإعداداته احتياطيًا، واحتفظ ببناء مصحح معروف الصلاحية. استعادة محرك ضعيف تعيد التعرض الأمني.
4. اختبر نسخة محدودة: تسجيل الدخول، والجلسات، والرفع المشروع، والاستيراد، والدفع، والـAPIs والمهام المجدولة. راقب الأخطاء والزمن والذاكرة والتوافق.
5. استبدل العمليات القديمة: تحديث الملفات على القرص لا يثبت أن العمال الحاليين حمّلوا المحرك الجديد. صرّف الطلبات ثم أعد تشغيل أو استبدل كل عامل ونسخة متأثرة.
6. أثبت اكتمال التغطية: اجمع إصدار التشغيل وهوية البناء لكل نسخة، وافحص القوالب التي قد ينشئ منها التوسع التلقائي نسخًا لاحقة.

إذا كانت بيئتك تستخدم فعلًا خدمة Ubuntu باسم php8.3-fpm، فقد يكون فحص الإعداد ثم إعادة التشغيل المخطط لها كالتالي:

sudo /usr/sbin/php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
sudo systemctl is-active php8.3-fpm

ظهور الخدمة Active يثبت أنها تعمل فقط. تحقق أيضًا من رقم الحزمة واستجابة الويب لكل نسخة. مع mod_php يجب استبدال عمليات Apache التي تحمل الوحدة. إعادة تشغيل Nginx وحده لا تستبدل PHP-FPM المنفصل عنه.

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

لماذا قد تتغير مراقبة الذاكرة بعد التصحيح؟

تصف وثائق حدود الذاكرة المحدثة حدًا مرنًا وآخر صلبًا عبر memory_hard_limit_percent. إنهاء العملية عند الحد الصلب يتجاوز دوال التنظيف، وقد يظهر برمز خروج 137، الذي قد ينتج أيضًا عن SIGKILL خارجي. افحص stderr وأحداث المنصة لتمييز السبب.

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

ماذا لو تعذر التحديث فورًا؟

توصي CERT-EU بالتحديث وعزل الخدمات المتأثرة عندما يتعذر إنجازه بسرعة. الإعدادات المؤقتة تقلل مسارات معينة ولا تمثل إصلاحًا شاملًا.

من الأمثلة تعطيل متابعة تقدم الرفع قبل تحليل الطلب وإعادة تشغيل العمال جميعًا، وتعطيل تتبع الأخطاء القاتلة في PHP 8.5. موضع الإعداد حاسم؛ التغيير داخل سكربت التطبيق قد يصل متأخرًا. توضح وثائق FPM الإعدادات الإدارية للمجمع وكيف يمنع php_admin_value تجاوزها من التطبيق، وتوضح وثائق تقدم الرفع أن هذه المعالجة تسبق السكربتات.

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

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

هل Cloudflare أو الاستضافة السحابية تحل المشكلة؟

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

تميّز إرشادات Google Cloud بين التحديث التلقائي لبيئات App Engine standard المدعومة، ومسؤولية العميل عن إعادة النشر في مسارات أخرى تشمل خدمات الحاويات. اسم مزود السحابة لا يحدد وحده من يحدث PHP. اطلب دليلًا للخدمة المستخدمة بدل افتراض أن VM أو CDN يحدث صورة التطبيق.

هل رُصد استغلال قبل الإعلان؟

نعم، رُصدت محاولات استغلال. أعلنت Amazon Threat Intelligence وجود محاولة في بيانات MadPot بتاريخ 17 أكتوبر، قبل الكشف العام بأربعة أيام، ثم محاولات أوسع لاحقًا. وتوضح أن نجاح تلك المحاولات ضد أنظمة حقيقية لم يكن محسومًا. يجب الحفاظ على الفرق بين رصد محاولة وإثبات اختراق.

في بيئتك، احتفظ بالأدلة المتاحة من 17 أكتوبر على الأقل. اربط الطلبات وأعطال العمال وتنفيذ العمليات وتغيرات الملفات والاتصالات الخارجية بحسب الوقت وهوية النسخة. افحص احتمال كشف الأسرار أيضًا؛ غياب أثر داخل سجل التطبيق لا يثبت سلامة المعالجة الأصلية التي تسبقه.

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

متى نعتبر المعالجة مكتملة؟

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

للتوسع في التنفيذ: تصريف مرور Kubernetes قبل خروج العمال، وتطبيق NetworkPolicy دون كسر الإنتاج، وضبط الضغط وإعادة المحاولة. وتجد شروحًا إضافية في مكتبة المقالات الهندسية.

المراجع الأولية

• PHP: التحديثات الأمنية وإرشادات أكتوبر 2026
• نشرة PHP: CVE-2026-109618 وفساد الذاكرة عند OOM
• نشرة PHP: CVE-2026-109619 والحالة العامة المتبقية
• مؤسسة PHP: الإصلاح وخلفيته الهندسية
• Wiz Research: التفاصيل التقنية لـPHP2Shell
• CERT-EU: النشرة 2026-018
• Ubuntu: النشرة USN-8948-1 وأرقام الحزم المصححة
• دليل PHP: خيارات سطر الأوامر
• دليل PHP: حدود الذاكرة
• دليل PHP: إعدادات FPM
• دليل PHP: متابعة تقدم رفع الملفات
• Cloudflare: الحماية المنشورة ضد PHP2Shell
• Google Cloud: مسؤولية التحديث حسب الخدمة
• Amazon Threat Intelligence: المحاولات السابقة للإفصاح

إعداد: Noor Yasser