تم نشر إصدارات تصحيحية من PHP 8.5.12 و 8.4.27 و 8.3.36 و 8.2.35، بالإضافة إلى تصحيحات لفروع PHP 7.4 و PHP 8.0 و PHP 8.1 التي لم تعد مدعومة (لا تزال الإصدارات المعرضة للخطر من 5.4 إلى 7.3 بدون تصحيح)، والتي تعالج ثغرتين أمنيتين حرجتين:
- CVE-2026-109618 — ثغرة أمنية تسمح بتنفيذ التعليمات البرمجية عن بُعد، وتنتج عن قيام معالج نفاد الذاكرة بتنفيذ دالة longjmp() عند نفاد ذاكرة العملية. قد تؤدي هذه الثغرة إلى إنهاء مُفسِّر PHP عند تهيئة بعض البنى الداخلية المرتبطة بمعالجة الطلبات فقط. عندئذٍ، تصل دالة إكمال الطلب إلى هذه البنى كما لو كانت مُهيأة مسبقًا، على الرغم من عدم تخصيص أي ذاكرة لها.
تتمثل آلية الهجوم الرئيسية في التلاعب بطلبات multipart لاستنزاف الذاكرة المتاحة للعملية. ولتجاوز حد post_max_size، يمكن حذف ترويسة Content-Length وإرسال عدد كبير من ترويسات HTTP. كما يُمكن شن هجمات مُستهدفة على عمليات مُحددة في تطبيقات PHP التي تستهلك ذاكرة كبيرة. وقد تم تأكيد وجود هذه الثغرة في mod_php، حيث تستدعي الدالة shutdown() حتى عند الفشل. يقوم PHP-FPM بإنهاء العملية الفرعية عند الفشل، مما يجعل الهجوم أكثر صعوبة ولكنه ليس مستحيلاً من الناحية النظرية.
- CVE-2026-109619 – ثغرة أمنية تسمح بتنفيذ تعليمات برمجية عن بُعد نتيجة استخدام الذاكرة بعد تحريرها، بسبب عدم مسح الحالة العامة المرتبطة بطلب معين بشكل صحيح. في حال انقطاع الطلب نتيجة خطأ فادح أو انتهاء المهلة أو نفاد الذاكرة، قد لا تتم إعادة ضبط الحالة العامة، وقد تبقى المؤشرات نشطة رغم تحرير الذاكرة التي تشير إليها. عند معالجة طلب لاحق في نفس العملية، قد يتم الوصول إلى المؤشر المتبقي للوصول إلى الحالة العامة القديمة.
يمكن استغلال الثغرة عن طريق إحداث استنزاف للذاكرة أثناء معالجة طلبات multipart في كود مؤشر تقدم التحميل (session.upload_progress). يُعدّ معالج fatal_error_backtraces في PHP 8.5 هو ناقل الهجوم الرئيسي والمؤكد، حيث لا يُعيد ضبط حالة التتبع عند اكتمال العملية. في الحالة الأولى، يكون الهجوم ممكنًا على mod_php وPHP-FPM، بينما في الحالة الثانية، يكون ممكنًا فقط على mod_php. كما ذُكر هجوم غير مؤكد في الإعدادات التي تحتوي على توجيهات تُطلق تحذيرات في وقت مبكر من معالجة الطلب (على سبيل المثال، تحذيرات بشأن استخدام معلمات قديمة).
ذُكر أن سدّ الثغرات الأمنية بشكل كامل لا يمكن تحقيقه إلا بتثبيت تحديث. تقلل الإجراءات التالية من احتمالية نجاح الهجمات، لكنها لا تجعل النظام آمنًا تمامًا:
- يؤدي تعيين المعلمة "memory_limit=-1" في ملف php.ini إلى صعوبة تحكم المهاجم في استنفاد حدود الذاكرة.
- اضبط قيمة المعامل "post_max_size = 8M" إذا لم تكن بحاجة إلى تحميل ملفات كبيرة. يجب أن تكون قيمة المعامل "upload_max_filesize" أقل من قيمة المعامل "post_max_size".
- تحديد حد لاستهلاك الذاكرة المقبول على مستوى النظام، عبر معلمات استهلاك الذاكرة cgroup memory.max أو container memory، ولكن ليس عبر حدود النظام RLIMIT_AS و RLIMIT_DATA، والتي تؤدي فقط إلى استدعاء longjmp() الإشكالي.
- إذا لم يكن الأداء مهمًا، يمكنك تحديد عدد الطلبات التي تتم معالجتها بواسطة عملية عامل واحدة باستخدام pm.max_requests=1 في PHP-FPM و MaxRequestsPerChild في Apache httpd.
- الإعداد على مستوى ملف php.ini أو مستوى التكوين الخادم (ليس عبر ini_set() أو FPM .user.ini، حيث يجب أن يكون المعلم ساري المفعول قبل معالجة الطلب) المعلمة "session.upload_progress.enabled=0.
- عند استخدام إصدار PHP 8.5، يجب تعيين المعلمة "fatal_error_backtraces=0".
- تمت إزالة الإعدادات القديمة أو الخاطئة لكل طلب (مثل assert.* والمسارات غير الصحيحة في open_basedir) التي كانت تتسبب في إخراج رسائل تشخيصية قبل التهيئة.
- إصلاح مشكلات كود PHP التي يمكن أن تؤدي إلى انتهاء المهلة والأخطاء الفادحة، مثل تلك المتعلقة بمعالجات الاستدعاء وفشل معالجة التنزيل.
- لسد الثغرة الأمنية الأولى في كود الإصدارات القديمة من PHP، يمكنك استبدال استدعاء longjmp() في معالج نفاد الذاكرة بـ _exit().
- بالإضافة إلى ذلك، يمكنك تقليل قيمة المعامل max_input_nesting_level في ملف php.ini وحظر طلبات multipart، كما هو موضح في الإعلان الأولي.
يمكن تقييم حالة إصلاحات الثغرات الأمنية في التوزيعات على هذه الصفحات: Debian, Ubuntu، SUSE، RHEL، Gentoo، Arch،
فيدورا، فري بي إس دي.
الملحق 1: تم تحديد الثغرات الأمنية باستخدام نموذجي الذكاء الاصطناعي GPT-5.6 وGemini 4 Argon. وقد نشرت OpenAI أداة php2shell-checker لاختبار مواقع الويب والملفات التنفيذية المحلية بحثًا عن الثغرات الأمنية، إلا أن هذه الأداة تتحقق فقط من رقم إصدار PHP الذي يُرجعه خادم HTTP أو الأمر "php -v"، دون تقديم تحليل مفصل.
التحديث الثاني: أفاد مطور نموذج أولي لثغرة أمنية تستغل ثغرة تحرير الذاكرة المزدوجة، أن هذه المشكلة لا تزال قائمة في PHP 8.5.12، وأن الثغرة لا تزال تعمل. وكان ممثلو PHP قد صرحوا سابقًا بأن هذه الثغرة لا علاقة لها بالتحديثات القادمة، وأنها ليست مشكلة حقيقية. إلا أن مطور الثغرة ادعى أنها ثغرة مختلفة تمامًا.
المصدر: opennet.ru
