لا يمكن تقييم php2shell (⁦CVE-2026-109618 / 109619⁩) بالأمر php -v: أين تختلف أرقام الإصدارات بين FPM وDocker والتوزيعات

إذا كانت نسخة PHP التي تعالج طلبات الويب (PHP-FPM أو mod_php في Apache أو php-cgi أو FrankenPHP أو LiteSpeed) أقدم من ⁦8.2.35 / 8.3.36 / 8.4.27 / 8.5.12⁩ فهي متأثرة بالثغرتين CVE-2026-109618 وCVE-2026-109619 المعروفتين باسم php2shell. الإصلاح هو الترقية إلى أحد هذه الإصدارات (أو إلى الحزمة المُصلحة في حالة حزم التوزيعات) ثم إعادة تشغيل العمليات. ما تحتاج إلى فحصه ليس php -v المحلي لديك، بل «نسخة PHP التي تخدم الويب فعليًا» و«إصدار الحزمة المثبّتة».

يركّز هذا المقال على أربعة مواضع يقود فيها الحكم بحسب رقم الإصدار وحده إلى نتيجة خاطئة. جميع الأرقام والمعلومات عن الحالة حتى 2026-10-22، ومصادر كل بند مذكورة في النهاية.

ما هو معروف حتى 2026-10-22

ينص إشعار PHP على أن «الإصلاح الكامل الوحيد هو التحديث». وتناول المقال لاحقًا إجراءات التخفيف للفترة التي تسبق إمكان التحديث.

الفخ الأول: قد يختلف php -v عن PHP المواجه للويب

الأمر php -v الذي تكتبه عبر SSH يعرض إصدار PHP الخاص بـ CLI. أما طلبات الويب فتعالجها عمليات PHP-FPM أو mod_php المحمَّل في Apache، وهي ملفات تنفيذية مستقلة وحزم مستقلة. إذا ثبّتَّ PHP أحدث لـ CLI فقط، أو تشغّل عدة إصدارات جنبًا إلى جنب، أو كان أحد pools الخاصة بـ FPM يشير إلى إصدار آخر، فقد يبقى جانب الويب قديمًا حتى لو أظهر php -v إصدارًا مُصلحًا.

هناك عدة طرق لمعرفة الإصدار الحقيقي على جانب الويب.

# FPM على Debian / Ubuntu (يُسمّى حسب الإصدار)
php-fpm8.3 -v

# FPM على عائلة RHEL
php-fpm -v

# التحقق من تحميل mod_php في Apache
apachectl -M | grep -i php

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

<?php echo PHP_VERSION, ' ', PHP_SAPI;

إذا كانت قيمة PHP_SAPI هي fpm-fcgi فـ PHP يعمل عبر FPM؛ وإذا كانت apache2handler فهو mod_php؛ وإذا كانت cgi-fcgi فهو CGI. تجنّب ترك phpinfo() مكشوفًا، لأن ذلك في ذاته يسرّب معلومات.

إعادة التشغيل خطوة أخرى يسهل نسيانها. فحتى بعد استبدال الحزمة، قد تواصل عمليات php-fpm أو Apache العاملة بالفعل تشغيل الشيفرة القديمة. بعض الإعدادات تعيد التشغيل تلقائيًا عند تحديث الحزم وبعضها لا. بعد التحديث، أعد تشغيل FPM / Apache وافحص إصدار جانب الويب مرة أخرى بالطرق أعلاه.

الفخ الثاني: مع Docker لا يمكنك الحكم من اسم الوسم

تحتوي صورة php الرسمية على «وسوم متحركة» مثل 8.3 و8.3-fpm يُستبدل محتواها، ووسوم مثبّتة مثل 8.3.30 تثبّت الإصدار.

• حتى بعد تحويل الوسم المتحرك إلى إصدار مُصلح على Docker Hub، تبقى نسختك المحلية صورة قديمة حتى تسحبها من جديد. كما تواصل الحاويات العاملة استخدام الصورة القديمة حتى يُعاد إنشاؤها. وملف Dockerfile الذي يحتوي على FROM php:8.3-fpm سيُبنى على الأساس القديم إذا بقي في ذاكرة البناء المؤقتة (build cache).
• الوسم المثبّت يبقى قديمًا إلى الأبد حتى ترفع الرقم بنفسك.

يمكنك التحقق من نشر وسوم الإصدارات المُصلحة باستخدام واجهة Docker Hub API.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

فيما يلي نتائج الاستعلام عن أربعة خطوط إصدار في 2026-10-22 (الأوقات بتوقيت UTC).

أظهر هذا الفحص ثلاث نقاط قد يضلّلك فيها الحكم بالأرقام.

1. «حُدِّث مؤخرًا» لا يعني «تم الإصلاح». أُعيد بناء الوسم المثبّت 8.3.35 خلال 2026-10-21، لكن قيمة PHP_VERSION بداخله بقيت 8.3.35. انظر إلى الإصدار الموجود داخل الصورة لا إلى وقت التحديث.
2. قد يختلف الـ digest ويتطابق المحتوى. كان للوسمين 8.3 و8.3.36 قيمتا digest مختلفتان (قيمة الفهرس الذي يجمع عدّة معماريات)، لكن صورة amd64 كانت هي نفسها وكانت قيمة PHP_VERSION=8.3.36 في كليهما. وكذلك في 8.3-fpm / 8.3.36-fpm و8.4-apache / 8.4.27-apache وlatest / 8.5.12 و8.5-fpm و8.2-fpm، كانت قيمة PHP_VERSION في صورة amd64 إصدارًا مصحَّحًا.
3. لا توجد صور رسمية مصحَّحة للإصدار 8.1 وما قبله. كان آخر تحديث للوسم 8.1-fpm في 2025-12-31.

للتحقق من الصور المحلية والحاويات العاملة:

# إصدار PHP في صورة سُحبت محليًا
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# اسحب الصورة من جديد وأعد إنشاء الحاويات
docker compose pull
docker compose up -d

# إذا كنت تبني صورتك بنفسك، اسحب الصورة الأساسية من جديد ثم ابنِ
docker compose build --pull

# الإصدار داخل حاوية عاملة
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

استبدل app في الأمر الأخير باسم الخدمة لديك. تُبنى كل صورة رسمية بقيمة PHP_VERSION واحدة، لذا يطابق إصدار CLI داخل الحاوية إصدار FPM / Apache فيها (تنطبق الثغرة 1 عند تثبيت PHP مباشرة على المضيف).

يضمّن FrankenPHP نسخة PHP بداخله، لذا فإن إصدار FrankenPHP وإصدار PHP المضمَّن رقمان مختلفان. تذكر ملاحظات إصدار FrankenPHP 1.13.2 الصادر في 2026-10-21 أن صور Docker بُنيت مع PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 وأن الملفات التنفيذية الساكنة بُنيت مع PHP 8.5.12.

المطب 3: حزم التوزيعات «تُصلَح وتبقى أرقامها قديمة»

تنقل Ubuntu وRHEL الإصلاحات فقط إلى الإصدارات الأقدم (backporting، أي نقل الإصلاح إلى إصدار قديم). يبقى الرقم الظاهر في php -v قديمًا، لذا فإن الفحص الرقمي مثل «أقل من 8.3.36 إذن معرَّض للثغرة» سيصنّف نظامًا مصحَّحًا على أنه معرَّض. وبالعكس، لا يمكنك الاطمئنان بالرقم وحده. احكم بناءً على إصدار الحزمة وعلى متتبّع الأمان الخاص بكل توزيعة.

الحزم المصحَّحة المدرجة في كل متتبّع (أمان) حتى 2026-10-22 (وهي نفسها لكلا الثغرتين):

يوضّح هذا الجدول مباشرةً لماذا لا تكفي الأرقام وحدها. إصدار PHP المصحَّح في Ubuntu 24.04 يبدأ بـ 8.3.6، أي أقل بكثير من 8.3.36 في المصدر الأصلي (upstream). وPHP الافتراضية في RHEL 9 مصحَّحة مع بقائها على 8.0.30، رغم أن المصدر الأصلي لم يعد يصدر إصلاحات للإصدار 8.0. أما Debian فقد انتقلت إلى الأرقام نفسها الموجودة في المصدر الأصلي (8.2.35 / 8.4.27).

بعض الحزم لم تُصلَح بعد (حتى 2026-10-22).

• وحدة php ‏8.4 في RHEL 9 مدرجة بحالة «متأثرة، دون إصلاح».
• في Debian forky (testing) الحزمة php8.4 بإصدار 8.4.26-1 وموسومة «vulnerable». أما php8.4 في sid (unstable) فهي 8.4.27-1 ومصحَّحة.

أمثلة على أوامر للتحقق من خادمك:

# Debian / Ubuntu: الإصدار المثبَّت والإصدار المتاح
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: هل أُصلحت هذه الثغرة (CVE) على هذا الخادم
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# عائلة RHEL: هل يوجد تحديث يصلح هذه الثغرة (CVE)، والإصدار المثبَّت
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

عدِّل اسم الحزمة (php8.3-fpm وغيرها) بحسب بيئتك. قارن الإصدار الظاهر بـ«الإصدار المصحَّح» في الجدول أعلاه أو في المتتبّع؛ فإن كان مساويًا له أو أعلى فالإصلاح موجود. بعد ذلك أكمل إعادة التشغيل والتحقق من جهة الويب كما في المطب 1.

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

المطب 4: في الاستضافة المشتركة والبيئات المُدارة لا يمكنك ترقية PHP بنفسك

في خدمات الاستضافة المشتركة وبيئات PHP المُدارة، يتولى المزوّد استبدال بيئة تشغيل PHP. وهنا أيضًا لا يكفي رقم الإصدار وحده: فإذا كان المزوّد يبني PHP بنفسه أو ينقل الإصلاحات إلى إصدارات أقدم (backport)، فقد يبقى رقم الإصدار قديمًا.

هناك ثلاثة أمور يمكنك القيام بها بنفسك.

1. تحقّق من إصدار PHP على جهة الويب. استخدم الملف المؤقت المذكور في الفخ 1 لعرض PHP_VERSION وPHP_SAPI، ثم احذفه فورًا. وإذا كانت لوحة التحكم تتيح اختيار إصدار PHP، فدوّن الإصدار الذي اخترته.
2. اقرأ إشعار المزوّد، واسأله إن لم يوجد إشعار. اسأل: «في أي إصدارات PHP ضمن باقتي ستُطبَّق إصلاحات CVE-2026-109618 وCVE-2026-109619، ومتى (أو هل طُبّقت)؟» السؤال برقم CVE بدلًا من رقم الإصدار يحصل منك على إجابة تشمل الإصلاحات المنقولة (backports) أيضًا.
3. إذا كنت قد اخترت إصدارًا غير مدعوم، فانتقل إلى إصدار أحدث. لا يصدر مشروع PHP أي إصلاحات للإصدار 8.1 وما قبله، وينتهي دعم 8.2 في 2026-12-31. وما لم يكن المزوّد قد نقل الإصلاحات إلى إصدارك، فالتحويل إلى إصدار آخر هو الطريق الموثوق.

حالة مزوّدي الاستضافة (حتى 2026-10-22)

في الاستضافة المشتركة يتولى المزوّد عادةً تحديث بيئة تشغيل PHP، وتذكر إشعارات كثير من المزوّدين أنه «لا يُطلب أي إجراء من المستخدمين». وعلى المستخدم أمران: الاطلاع على الإشعار الرسمي لمزوّده، وإذا كان قد اختار إصدار PHP قديمًا في لوحة التحكم، فعليه أن يقرر هل ينتقل إلى الإصدار الذي يوصي به الإشعار (إصدار صدر له إصلاح).

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

حيثما لم أجد إشعارًا رسميًا أو تعذّر فتحه، كُتب في الجدول «تعذّر التأكد» أو «لم أجد». وغياب المعلومات هناك لا يعني أن المزوّد لم يستجب. تحقق مباشرة من إعلانات مزوّدك ومن الدعم الفني.

إجراءات تخفيف المخاطر إلى أن يمكنك التحديث

يذكر إشعار PHP إعدادات تقلّل سطح الهجوم إلى أن تتمكن من التحديث. غير أن الإشعار نفسه ينص صراحةً على أنها «لا تجعلك آمنًا». وأهمها:

• بالنسبة إلى CVE-2026-109619: اضبط session.upload_progress.enabled=0 في php.ini أو في مجمّع FPM أو في إعدادات الخادم، ثم أعد تشغيل جميع العمليات العاملة (ini_set() وملف .user.ini الخاص بـ FPM لا يعملان هنا). وفي PHP 8.5 اضبط أيضًا fatal_error_backtraces=0.
• بالنسبة إلى CVE-2026-109618: اضبط memory_limit=-1 بطريقة لا يستطيع التطبيق تجاوزها، وقلّل post_max_size (8M إذا لم تكن هناك عمليات رفع، و32M إذا وُجدت). لا تستخدم RLIMIT_AS / RLIMIT_DATA بديلًا عن ذلك.

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

المصادر (جرى التحقق منها في 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: إعلانات إصدارات PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: صورة php الرسمية
• ملاحظات إصدار FrankenPHP 1.13.2
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (إصدارات الحزم المُصلَحة مأخوذة من بيانات VEX الخاصة بـ Red Hat)
• NCSC: Critical security issue affecting PHP