ثغرتان حرجتان في نواة ⁨PHP⁩: من المكشوف وبأي ترتيب ترقّع

في 21 أكتوبر 2026 أصدر مشروع ⁨PHP⁩ النسخ ⁨8.5.12⁩ و⁨8.4.27⁩ و⁨8.3.36⁩ و⁨8.2.35⁩، ونشرته الأمنية واضحة: حدّث الآن. هذه النسخ تصلح ثغرتين حرجتين قد تسمحان بتنفيذ كود عن بعد دون أي مصادقة، والنشرة تعدّ كل تثبيت ⁨PHP⁩ يخدم طلبات ويب معرّضًا للخطر، سواء كان ⁨PHP-FPM⁩ أو ⁨mod_php⁩ على ⁨Apache⁩ أو ⁨php-cgi⁩ أو ⁨FrankenPHP⁩ أو ⁨LiteSpeed⁩. المشكلة في بيئة التشغيل تحت كودك، لا في كودك نفسه، فلا يلزم أن يكون في تطبيقك أي خطأ حتى تنطبق عليك.

ما هما الثغرتان

الأولى ⁨CVE-2026-109618⁩ تتعلق بنفاد الذاكرة: قد يُقطع تنفيذ ⁨PHP⁩ بفشل في حجز الذاكرة بينما بيانات الطلب الداخلية لم تكتمل تهيئتها بعد، ثم تتعامل مرحلة التنظيف في نهاية الطلب مع هذه البيانات الناقصة كأنها سليمة. وتضيف نشرة ⁨GitHub⁩ أن عدة مسارات في تحليل رفع الملفات متعدد الأجزاء قد تصل إلى نفاد الذاكرة والطلب يبدو ضمن حدوده. والثانية ⁨CVE-2026-109619⁩ تتعلق بحالة قديمة: شيء يملكه طلب ما قد يبقى بعد تحرير الذاكرة التي تحمله، فيستخدمه الطلب التالي على العامل نفسه قبل أن تعيد التهيئة العادية ضبطه.

متتبّع الحوادث ⁨pwn.watch⁩، وهو جهة خارجية، يسمّي الثغرتين ⁨PHP2Shell⁩ ويقيّم كلًّا منهما بدرجة ⁨CVSS 9.2⁩، ويقول إن التفاصيل خرجت مبكرًا بعد تسرّب من فترة الحظر. وبحسب المتتبّع نفسه رُصدت محاولات استغلال قبل الترقيع وبعده، وتتحدث ⁨watchTowr⁩ و⁨AWS⁩ عن فحص نشط، وما زال مصنّعو أجهزة مثل ⁨QNAP⁩ يجهّزون إصلاحاتهم. هذه رواية المتتبّع، أما ما يجب تثبيته فتحدده نشرة ⁨php.net⁩.

أي الإعدادات أكثر عرضة

الخطر ليس متساويًا بين واجهات الخادم. نشرة ⁨GitHub⁩ تشرح السبب: ⁨mod_php⁩ ينفّذ مرحلة إنهاء الطلب دائمًا حتى لو فشل بدء الطلب، فإذا نفدت الذاكرة أثناء تحليل جسم الطلب عولجت حالة غير صالحة قبل أن يعمل أي سطر من كود التطبيق، وقد أُثبت استغلال فعلي هناك. أما ⁨PHP-FPM⁩ فيُنهي العملية الفرعية حين يفشل البدء ويخرجها من المجموعة، فهو عرضة بحسب تحليل الكود المصدري لكن لم يُعرض استغلال كامل له. و⁨FrankenPHP⁩ عرضة على الأرجح بالطريقة نفسها التي يعمل بها ⁨mod_php⁩، وواجهة ⁨LSAPI⁩ في ⁨LiteSpeed⁩ تسلك سلوك ⁨FPM⁩.

اعثر على كل نسخة ⁨PHP⁩ ثم رقّع بالترتيب

قاعدة عامة: قد يحمل الخادم الواحد أكثر من ⁨PHP⁩، والأمر ⁨php -v⁩ في الطرفية يخبرك بنسخة سطر الأوامر، وهي ليست دائمًا النسخة التي يستخدمها خادم الويب. افحص كل مكان قد تختبئ فيه نسخة: سطر الأوامر، وخدمة ⁨FPM⁩، وكل صورة ⁨Docker⁩ تبنيها أو تسحبها، ومحدد الإصدار في لوحة الاستضافة.

# the command-line PHP (may differ from the web one)
php -v
# the PHP inside a container image you deploy
docker run --rm your-image:tag php -v

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

<?php
echo PHP_VERSION, ' ', PHP_SAPI;

كل ما هو أقدم من ⁨8.2.35⁩ أو ⁨8.3.36⁩ أو ⁨8.4.27⁩ أو ⁨8.5.12⁩ متأثر. توزيعات ⁨Linux⁩ ومزوّدو الدعم الطويل حصلوا على الترقيعات مسبقًا، فابدأ بحزم مزوّدك. وتذكر النشرة أن مستودع ⁨rpms.remirepo.net⁩، الذي يديره متطوعون، لن تكون فيه التحديثات يوم الإصدار، وتقترح حزم التوزيعة أو البناء من المصدر بدلًا منه. أما ⁨PHP 8.1⁩ وما قبله فلا يصلها تحديث من مشروع ⁨PHP⁩، وبعض المزوّدين ينقلون الإصلاحات إليها، ونشر فريق الأمن نقلًا مصدريًا مختصرًا للإصدارات ⁨7.4⁩ و⁨8.0⁩ و⁨8.1⁩ لمن يبني من المصدر.

بعد التحديث أعد تشغيل كل عمّال ⁨PHP⁩. مجموعة ⁨FPM⁩ طويلة العمر أو عامل ⁨FrankenPHP⁩ يبقي النسخة القديمة في الذاكرة حتى يُعاد تشغيله.

ما تفعله إجراءات التخفيف وما لا تفعله

النشرة صريحة: التحديث هو الحل الكامل الوحيد، والإجراءات التي تسردها تقلّل التعرّض لمسارات بعينها ولا تجعل التثبيت آمنًا. لثغرة نفاد الذاكرة: ضبط ⁨memory_limit=-1⁩ حيث لا يستطيع التطبيق تجاوزه، عبر ⁨php_admin_value⁩ في مجموعة ⁨FPM⁩ أو إعداد ⁨Apache⁩، وقيمة منخفضة لـ ⁨post_max_size⁩ (⁨8M⁩ دون رفع ملفات و⁨32M⁩ معه، مع ⁨upload_max_filesize⁩ أقل منها)، وحدود في خادم الويب أو الوكيل على حجم الطلب وعدد الحقول والأجزاء والترويسات والتداخل، وحد ذاكرة من الحاوية أو ⁨cgroup⁩ بدل ⁨RLIMIT_AS⁩ أو ⁨RLIMIT_DATA⁩ اللذين قد يسببان فشل الحجز نفسه. ولثغرة الحالة القديمة: ⁨session.upload_progress.enabled=0⁩ في ⁨php.ini⁩ أو إعداد المجموعة، لا عبر ⁨ini_set()⁩ أو ⁨.user.ini⁩، مع إعادة تشغيل كل العمّال، و⁨fatal_error_backtraces=0⁩ على ⁨8.5⁩، وإزالة الإعدادات غير الصالحة أو المهمَلة لكل طلب، وإصلاح الأخطاء القاتلة ومهل التنفيذ التي يستطيع المهاجم الوصول إليها.

خطوة اليوم: اكتب قائمة بكل خادم وصورة حاوية وحساب استضافة يشغّل ⁨PHP⁩، وسجّل النسخة التي يخدم بها كل منها، وحدّث ما هو أقدم من النسخ المُصلحة قبل أن تلمس أي إعداد. المصدر: النشرة الأمنية على ⁨php.net⁩ بتاريخ 21 أكتوبر 2026.