ثغرتا PHP CVE-2026-109618 و109619: الحل

تم الكشف عن الثغرتين CVE-2026-109618 وCVE-2026-109619، اللتين تتيحان تنفيذ تعليمات برمجية عن بُعد (RCE) دون مصادقة أثناء الإنهاء غير الطبيعي لمحرك PHP الأساسي وإدارة حالة الطلبات. ولا تتعلق المشكلة بتطبيقات الويب مثل WordPress أو GnuBoard، بل بخلل في تلف الذاكرة وإعادة استخدام الذاكرة بعد تحريرها (Use-After-Free) داخل محرك PHP نفسه. ولحل المشكلة، يجب الترقية فورًا إلى إصدار يتضمن التصحيحات الأمنية، مثل PHP 8.5.12 و8.4.27 و8.3.36 و8.2.35، ثم إعادة تشغيل عمليات العمال.

ثغرة في محرك PHP لا يمكن منعها بتحديث تطبيق الويب وحده

في 21 أكتوبر 2026 (UTC)، أعلن فريق تطوير PHP عن ثغرتين أمنيتين بدرجة خطورة 9.2 وفق معيار CVSS v4.0. ويمكن للمهاجم تنفيذ تعليمات برمجية عشوائية على الخادم بمجرد إرسال طلب HTTP مُعدّ خصيصًا، من دون الحاجة إلى تسجيل الدخول.

يعمل هذا الخلل في طبقة PHP الأساسية التي تحلل طلبات الويب وتنظف الذاكرة. لذلك، حتى مع إبقاء CMS أو الإضافات في الموقع محدثة، يظل الموقع معرضًا للهجوم إذا كان إصدار وقت تشغيل PHP قديمًا. وتبين خصوصًا أنه في بيئات Apache ذات الإعداد الافتراضي لـ mod_php، يمكن تنفيذ التعليمات البرمجية من خلال طلب واحد قبل أن يبدأ تنفيذ كود تطبيق الويب.

عند نجاح الهجوم، يحصل المتسلل على صلاحيات حساب النظام الذي تعمل به عملية PHP. ولا يعني ذلك الاستيلاء الفوري على صلاحيات الجذر (root)، لكنه قد ينشئ webshell في الدليل الجذري للويب، أو يقرأ بيانات اتصال قاعدة البيانات المسجلة في ملفات الإعدادات، مما يتيح تسريب البيانات الداخلية أو تعديلها. وإذا كانت عدة مواقع على خادم واحد تشترك في حساب تشغيل PHP-FPM نفسه، فقد يمتد اختراق موقع واحد إلى مواقع أخرى على الخادم.

مبدأ تلف الذاكرة وإعادة استخدامها بعد تحريرها عند الإنهاء غير الطبيعي

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

CVE-2026-109618 (تلف الذاكرة أثناء معالجة تجاوز حد الذاكرة): عندما يتجاوز PHP حد الذاكرة المسموح به أثناء معالجة الطلب (Out-Of-Memory)، يستدعي longjmp() لإيقاف التنفيذ فورًا. وإذا توقف العمل بينما لم تُهيأ هياكل بيانات الطلب الداخلية بالكامل، فقد تبقى الحالة غير المكتملة من دون التراجع عنها. وبعد ذلك، يثق روتين تنظيف الطلب (cleanup) بهذه الذاكرة غير المهيأة باعتبارها بيانات سليمة، ويصل إليها، مما يؤدي إلى تلف الذاكرة وتنفيذ تعليمات برمجية عن بُعد.

CVE-2026-109619 (Use-After-Free يشير إلى ذاكرة محررة من الطلب السابق): تشير بعض الحالات العامة الداخلية في PHP أو حالات معالجة الأخطاء مؤقتًا إلى منطقة ذاكرة يملكها طلب واحد. وعند إنهاء الطلب بصورة غير طبيعية بسبب خطأ فادح (fatal error) أو نفاد الذاكرة، قد تُحرر الذاكرة فعليًا، بينما تبقى مراجع المؤشرات الداخلية التي تشير إليها من دون تهيئة. وفي بيئات إعادة استخدام عمليات العمال، مثل PHP-FPM أو mod_php، عندما يعالج العامل نفسه طلب HTTP التالي، فإنه يقرأ مجددًا منطقة الذاكرة المحررة، مما ينشئ مسارًا لتنفيذ التعليمات البرمجية (Use-After-Free).

ويذكر الإشعار الأمني الرسمي أن المسارات المؤكدة في CVE-2026-109619 تشمل وظيفة تقدم رفع الجلسة (session.upload_progress)، وتحذيرات الإعدادات التي تُطبع قبل تهيئة الطلب، والتتبع العكسي للأخطاء الفادحة في PHP 8.5 (fatal_error_backtraces). لكنه يوضح أن منع هذه المسارات لا يلغي المسارات البديلة الأخرى.

حالة التصحيحات حسب إصدار PHP ونطاق التأثير وفق بيئة التشغيل

تتأثر إصدارات PHP من 8.2 إلى 8.5 الأقدم من الإصدارات المُصلحة، أما 8.1 والإصدارات الأقدم التي انتهى دعمها فلا تدخل ضمن التحديثات الرسمية لمشروع PHP. وتشمل طرق التشغيل المستهدفة جميع عمليات التثبيت التي تعالج طلبات الويب، بما في ذلك PHP-FPM وmod_php وphp-cgi وFrankenPHP وLiteSpeed، ويعتبر الإشعار الرسمي أن خطر mod_php هو الأعلى بينها. وتصنف Red Hat PHP-FPM على أنه يتأثر بصورة مشروطة عبر مسار على مستوى التطبيق.

بيئة التحقق: اعتبارًا من 22 أكتوبر 2026، تمت الترقية من PHP 8.4.26 إلى 8.4.27 في بيئة خادم Linux تستخدم مستودع Remi، كما تم التحقق من إعادة تشغيل عمال PHP-FPM وانعكاس التغيير على طلبات الويب.

إجراءات تحديث الحزم وتطبيق إعدادات التخفيف في PHP-FPM

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

1. تثبيت تحديث حزم PHP
   قم بترقية الحزم عبر مدير حزم نظام التشغيل إلى الإصدار المصحح من سلسلة PHP المستخدمة، مثل 8.4.27 لسلسلة 8.4. وبعد التثبيت، تحقق أولًا من إصدار CLI في الطرفية.

   php -v

   عند تنفيذ الأمر، سيظهر على الشاشة رقم الإصدار المحدث وتاريخ البناء، مثل PHP 8.4.27 (cli). لكن قد يختلف إصدار CLI عن حالة إصدار عملية PHP المرتبطة فعليًا بخادم الويب، لذلك يجب متابعة الخطوة التالية.

2. ضبط إعدادات PHP-FPM لتقليل سطح الهجوم (تخفيف اختياري ومؤقت)
   إذا تعذر تطبيق التحديث فورًا أو أردت إضافة طبقة دفاعية، فانسخ احتياطيًا ملف php.ini أو ملف إعداد مجموعة PHP-FPM، مثل /etc/php-fpm.d/www.conf، ثم عدّل العناصر التالية.

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   يؤدي تعطيل session.upload_progress.enabled إلى حظر مسار الهجوم المؤكد القائم على الجلسات. كما أن خفض post_max_size، مثل 8M في البيئات التي لا تحتاج إلى رفع الملفات أو 32M في البيئات التي تحتاج إليه، يصعّب محاولات استنزاف الذاكرة عبر الطلبات الكبيرة. ومع مراعاة حجم الرؤوس الإضافية لـ multipart، يجب ضبط upload_max_filesize على قيمة أقل قليلًا من post_max_size. وفي بيئة PHP 8.5، طبّق أيضًا الإعداد fatal_error_backtraces = 0.

3. فحص صياغة إعدادات PHP-FPM وإعادة تشغيل العمليات
   بعد حفظ الإعدادات، اختبر عدم وجود أخطاء نحوية ثم أعد تشغيل خدمة PHP-FPM.

   php-fpm -t
   systemctl restart php-fpm

   إذا لم توجد مشكلة في الإعدادات عند تنفيذ php-fpm -t، فستظهر الرسالة NOTICE: configuration file ... test is successful على الشاشة. ويجب إعادة تشغيل عمليات العمال لإنهاء العمال القدامى الذين كانت نسخهم القديمة مقيمة في الذاكرة وتطبيق التصحيح والإعدادات الجديدة.

4. التحقق من الإصدار المطبق فعليًا عبر طلب ويب
   استدعِ علامة تبويب معلومات «حالة الموقع (Site Health)» في WordPress أو صفحة تشخيص تكامل خادم الويب، وتحقق من أن عامل PHP-FPM الذي يعالج طلبات الويب يستجيب بإصدار مصحح مثل 8.4.27. وإذا وُجد ملف PHP تشخيصي أنشئ مؤقتًا لأغراض التحقق، فاحذفه فور الانتهاء من الفحص حتى لا تُكشف معلومات النظام خارجيًا.

كيفية التعامل مع تأخر التحديث أو الآثار الجانبية لتغيير الإعدادات

تعذر تنزيل الحزمة بسبب تأخر انعكاس المستودع على خوادم النسخ المتطابقة التابعة لجهة خارجية مثل Remi

بعد التصحيح الأمني العاجل مباشرة، قد لا تظهر حزم التحديث فورًا في مستودعات الجهات الخارجية، مثل rpms.remirepo.net، أو قد تكون سرعة التنزيل بطيئة بسبب زيادة حركة المرور أو تأخر المزامنة. ويوضح الإشعار الرسمي أن التحديث قد لا يُنشر في هذا المستودع الذي يديره متطوعون في يوم الإعلان، ويوصي بالتحول إلى حزم التوزيعة أو البناء من المصدر.

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

المخاوف من نفاد الذاكرة (OOM) أو رفض الرفع عند تطبيق إعدادات التخفيف

يوصي الإشعار الرسمي، عند تعذر التحديث فورًا، بالإعداد memory_limit = -1 (غير محدود) كتخفيف لـ CVE-2026-109618، مع فرض حد للذاكرة على الحاوية أو cgroup في الوقت نفسه. لكن إلغاء حد الذاكرة على خادم لا يملك ذاكرة فعلية كافية قد يؤدي إلى استهلاك طلب واحد لذاكرة الخادم بالكامل، ومن ثم إلى عطل يفرض فيه OOM Killer في نظام التشغيل إيقاف خدمات أساسية. هذا الإعداد إجراء مؤقت إلى حين التحديث، ومن الآمن إعادة حد الذاكرة الأصلي بعد الترقية إلى الإصدار المصحح.

كذلك، عند خفض post_max_size عن قيمته الحالية، مثل 64MB، يجب أولًا التحقق من طريقة نقل الملفات في الموقع. فقد تُحظر الطلبات في المواقع التي ترفع ملفات النسخ الاحتياطي الكبيرة أو الإضافات مباشرة عبر صفحة إدارة الويب. أما في البيئات التي تنقل الملفات الكبيرة عبر SFTP أو rsync، أو التي يكون فيها حد التطبيق مضبوطًا أصلًا على 30MB أو أقل، فلن يؤثر خفض حد رفع PHP إلى 32MB في الخدمة.

من ناحية أخرى، إذا بدأت عمليات PHP-FPM بالإنهاء غير الطبيعي بصورة متقطعة بعد ترقية إصدار PHP، فقد يكون من المفيد الاشتباه في إعداد تجميع JIT (Just-In-Time) ضمن OPcache. ولا ترتبط وظيفة JIT، مثل opcache.jit=1255، مباشرة بهذه الثغرة الأمنية، لكن إذا كانت لها سوابق في التسبب بمشكلات استقرار عند تغيير الإصدار، فيمكن تعطيلها من ملف الإعدادات باستخدام opcache.jit=off لمنع التعارضات.

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

هل تُحل المشكلة بتحديث WordPress أو الإضافات إلى أحدث إصدار؟

لا. تحدث هذه الثغرة في محرك PHP الأساسي، قبل تشغيل WordPress أو الإضافات الأمنية. ويمكن لجدار حماية الويب، مثل Cloudflare أو AWS WAF، حظر أنماط الهجوم المعروفة مؤقتًا، لكن الحل الجذري يتطلب تحديث إصدار PHP نفسه على الخادم عبر مزود الاستضافة أو مسؤول الخادم.

هل يصبح الخادم آمنًا من دون تحديث إذا عطلت إعداد session.upload_progress.enabled؟

لا. يوضح الإشعار الرسمي أن هذا الإعداد يحظر مسار الجلسة المؤكد فقط، ولا يمنع المسارات البديلة الأخرى. كما يجب وضع الإعداد في موضع يُطبق قبل تحليل الطلب، مثل php.ini أو مجموعة FPM أو إعدادات الخادم، وليس عبر ini_set() أو .user.ini في FPM، مع إعادة تشغيل جميع العمال. والحل الكامل هو تثبيت التصحيح.

هل يمكن تشغيل النظام فورًا دون فحص إضافي بعد اكتمال تطبيق التصحيح؟

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

كيف أتعامل مع بيئات الحاويات أو صور السحابة؟

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

المصادر

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 (بالكورية)