ما الذي يجب أن ينتجه جرد المحفظة
جرد المحفظة ليس أمرًا يُنفَّذ مرة واحدة. إنه سجل: سطر لكل موقع، فيه إصدار PHP المقروء، وطريقة قراءته، والتاريخ، ودرجة اليقين. من دون هذه المعلومات الثلاث لا قيمة للرقم، لأن إصدارًا قُرئ الشهر الماضي لا يقول شيئًا عن حالة اليوم.
الاعتراض المعتاد وجيه: ليس لديك سلطة على مستضيف العميل، ولا يمكنك تنفيذ أوامر SSH في كل مكان، ويجب ألا تضع ملف تشخيص على موقع في الإنتاج. والجواب فكرة واحدة: قِس بما لديك، وسجّل بأمانة ما يثبته كل قياس. الموقع المقروء من الخارج مفترض، والموقع المقروء من الخادم مؤكد. يحتفظ السجل بالاثنين ويُظهر أين بقي عمل.
سياق مؤرخ: PHP2Shell
في 21 أكتوبر 2026 أصدر مشروع PHP الإصدارات 8.5.12 و8.4.27 و8.3.36 و8.2.35 التي تعالج CVE-2026-109618 وCVE-2026-109619 (تنفيذ تعليمات برمجية عن بُعد دون مصادقة). لم يعد PHP 8.1 والفروع الأقدم تتلقى تحديثات من المشروع، ونُشرت تصحيحات مرتجعة دنيا للشيفرة المصدرية للإصدارات 7.4 و8.0 و8.1. أما إدراجها في كتالوج CISA للثغرات المستغلة فيعود إلى 26 أكتوبر 2026، بمهلة اتحادية حتى 29 أكتوبر 2026. نتناول الثغرتين وتحديث خادم واحد في المقال المخصص لذلك؛ وهنا نعالج المحفظة.
مستويات القياس الأربعة
مرّر الجدول أفقيًا
| المستوى والوصول | ما يثبته | ما لا يثبته |
|---|---|---|
| 1. مراقبة خارجية دون وصول | ترويسة X-Powered-By أو Server، إن وُجدت، توحي بمنظومة وإصدار | لا شيء مؤكد: كثيرًا ما تكون الترويسة مخفية أو محذوفة أو خاطئة. إنها افتراض |
| 2. wp-cli أو SSH | إصدار ملف PHP التنفيذي لسطر الأوامر، مقروءًا على الجهاز | الإصدار المقدَّم على الويب: قد يختلف ملف CLI عن PHP-FPM أو Apache |
| 3. لوحة cPanel أو WHM أو Plesk | الإصدار المعيَّن لكل نطاق مع معالجه | التصحيح المطبق فعلًا: قد يكون الرقم نفسه مصححًا أو لا بحسب الحزمة |
| 4. Docker | الإصدار في الصورة وفي الحاوية قيد التشغيل | أن الصورة المنشورة هي الصحيحة: قارن الصورة بالحاوية الحية |
| قراءة سجل تغييرات الحزمة | أن التصحيح موجود رغم ثبات الرقم (تصحيح مرتجع) | أن الموقع لم يتعرض للاختراق قبل التحديث |
| لا مستوى ممكن | لا شيء: ينتقل الموقع إلى الدفعة 4، ويُطلب من العميل أو المستضيف | لا تصنّفه أبدًا مصححًا افتراضيًا |
القياس مستوى بعد مستوى
المستوى 1: قراءة الترويسات دون وصول
جهّز الملف
sites.txtبعنوان URL في كل سطر، ثم نفّذwhile read -r u; do printf '%s,%s\n' "$u" "$(curl -sI --max-time 10 "$u" | tr -d '\r' | grep -iE '^(server|x-powered-by):' | tr '\n' ' ')"; done < sites.txt > externe.csv. يعطي كل سطر العنوان والترويستين المعثور عليهما. السطر الفارغ معلومة: الترويسة مخفية. صنّف هذه المواقع «مفترضة» وانتقل إلى المستوى التالي في أقرب فرصة.المستوى 2: استعلام WordPress عبر wp-cli
في موقع WordPress مثبّت عليه wp-cli، يعرض الأمر
wp cli infoسطرًا باسمPHP binaryوسطرًا باسمPHP versionضمن غيرهما. لاستخراج الثاني:wp cli info | grep 'PHP version'. لاحظ أن هذه القيمة تصف الملف التنفيذي المستخدم في سطر الأوامر. وقد يعمل خادم الويب بإصدار آخر، خصوصًا حين يتيح المستضيف عدة إصدارات لكل نطاق. وللتحقق الموثوق قارن بالمستوى 3.المستوى 2 مكرر: سكربت SSH دفعي
باستخدام
hotes.txt(اسم SSH مستعار في كل سطر):while read -r h; do printf '%s,%s\n' "$h" "$(timeout 20 ssh -n -o BatchMode=yes -o ConnectTimeout=8 "$h" "php -r 'echo PHP_VERSION;'" 2>/dev/null || echo inconnue)"; done < hotes.txt > ssh.csv. الخيار-nيمنع ssh من ابتلاع القائمة، وBatchModeيمنع مضيفًا من طلب كلمة مرور فيعطّل الحلقة، وtimeoutيحدّ كل محاولة. تظهر المضيفات الفاشلة باسم "inconnue" بدل أن تختفي: جُرّب السكربت مع مضيف فاشل ومضيف لا يستجيب، وكلاهما ظهر في ملف CSV.المستوى 3: قراءة اللوحات
في cPanel، يسرد MultiPHP Manager كل نطاق مع إصدار PHP الخاص به، أو بعلامة Inherited حين يتبع قيمة النظام. وفي WHM تعطي الأداة نفسها العرض بحسب الحساب. وفي Plesk يُضبط الإصدار والمعالج لكل نطاق ضمن المواقع والنطاقات، في قسم إعدادات PHP، بحسب إصدار Plesk. دوّن الإصدار المعروض ثم انتقل إلى الخطوة التالية لمعرفة هل التصحيح موجود.
التصحيحات المرتجعة: اقرأ سجل التغييرات لا الرقم وحده
كثيرًا ما تصحح التوزيعات والمستضيفون على CloudLinux دون تغيير الرقم الأصلي. تقول AlmaLinux ذلك صراحة في إشعارها: لا تعتمد على
php -v، بل قارن الحزمة المثبتة بالإصدار المصحح المنشور، مثلًا عبرrpm -q php-common. وللبحث عن ثغرة CVE في تاريخ الحزمة:rpm -q --changelog php-common | grep CVE-2026-109618في عائلة RHEL، وapt changelogمتبوعًا باسم الحزمة في Debian وUbuntu. إن غابت الثغرة عن التاريخ فهي غير مصححة في تلك الحزمة.المستوى 4: الحاويات
الصورة الحديثة لا تثبت أن الحاوية العاملة حديثة أيضًا. قارن الإصدار في الصورة بإصدار الحاوية قيد التشغيل، ثم أعد البناء عند الحاجة. الإجراء الكامل في مقال إعادة بناء صور PHP، ونكتفي بالإحالة إليه بدل نسخه.
لماذا لا phpinfo، وبالأخص ليس علنًا
الغريزة هي وضع ملف phpinfo() في الموقع. إنه يعرض كل شيء، لكنه يكشف أيضًا المسارات والوحدات وإعدادات الخادم لكل من يعرف العنوان، ويصبح الملف المنسي نقطة دخول للاستطلاع. وفي موقع العميل مشكلة ثانية: تعديل الموقع دون تفويض كتابي خطأ، حتى لمجرد قراءة إصدار.
استبعده افتراضيًا. وإن فرضه ظرف ما، فيجب أن يستوفي الملف المؤقت أربعة شروط: موافقة العميل كتابةً، واسمًا لا يمكن تخمينه، وحذفًا فوريًا بعد القراءة، وتسجيلًا للعملية في السجل. وفي معظم الحالات يغني قياس من المستوى 2 أو 3 عن هذا الملف.
السجل: سطر لكل موقع
يكفي جدول بيانات مشترك، شرط أن يلتزم الجميع بالأعمدة نفسها. الهدف أن يستأنف زميل الجرد دون أن يسألك، وأن يتسلم العميل سطره كما هو.
أعمدة السجل
- الموقع والعميل والمستضيف — هوية السطر مع العنوان الأساسي وجهة الاتصال التقنية.
- نوع الوصول — لا شيء، أو wp-cli، أو SSH، أو لوحة، أو Docker: ما يحدد المستوى الممكن بلوغه.
- طريقة القياس — الأمر أو الشاشة المستخدمة، ليمكن إعادة القياس بالطريقة نفسها.
- الإصدار المقروء وSAPI — الرقم ونمط التنفيذ (FPM أو وحدة Apache أو CLI)، فالخطر يختلف بحسب النمط.
- تاريخ القياس — إصدار بلا تاريخ مجرد رأي.
- مستوى الثقة — مفترض (المستوى 1) أو مؤكد (المستويات 2 إلى 4)، مع إشارة التصحيح المرتجع إذا أكدها سجل التغييرات.
- دفعة الأولوية والحالة — من 1 إلى 4، ثم للإنجاز، أو تم الإبلاغ، أو قيد التنفيذ، أو مصحح، أو مرفوض من العميل.
- تاريخ التصحيح وإثباته — اللقطة ومخرجات الأمر واسم المنفِّذ.
التصنيف في دفعات لا في قائمة مشتريات
عندما يمتلئ السجل، لا يعود السؤال «هل كل شيء محدَّث؟» بل «من أين نبدأ؟». تجيب أربع دفعات. الدفعة 1 تجمع المواقع المكشوفة على فرع لم يعد يتلقى تصحيحات من مشروع PHP (8.1 وما قبله)، إلا إذا أكد سجل التغييرات تصحيحًا من المورّد. الدفعة 2: فرع ما زال مدعومًا لكن بإصدار أقدم من التصحيح. الدفعة 3: فرع مصحح يلزم تأكيده بقياس من المستوى 2 أو 3. الدفعة 4: موقع لا يمكن بلوغه أو إصدار مجهول.
ثلاثة معايير ترفع الموقع دفعة: نموذج عام، أو متجر، أو بيانات شخصية، أو إضافة تقبل ملفات مرفوعة. موقع عرض ثابت في الدفعة 2 يأتي بعد متجر في الدفعة 3.
شبكة الأولويات
مرّر الجدول أفقيًا
| الدفعة | المعيار | الإجراء |
|---|---|---|
| الدفعة 1 | مكشوف، فرع بلا تصحيح من المشروع (8.1 وما قبله) | الترحيل أو طلب حزمة مصححة من المورّد، وإبلاغ العميل في اليوم نفسه |
| الدفعة 2 | فرع مدعوم، إصدار أقدم من التصحيح | التحديث إلى الإصدار المصحح للفرع خلال الأسبوع |
| الدفعة 3 | فرع مصحح، قياس يلزم تأكيده | قياس من المستوى 2 أو 3 ثم رفع الثقة إلى مؤكد |
| الدفعة 4 | لا يمكن بلوغه أو وصول مرفوض أو إصدار مجهول | طلب الوصول أو الإصدار من العميل، والمتابعة وتأريخ كل طلب |
| عامل مشدد | نموذج، متجر، بيانات شخصية، رفع ملفات | يرفع الموقع دفعة واحدة في ترتيب المعالجة |
إبلاغ العملاء دون إفزاعهم
لا يحتاج العميل إلى تفاصيل الثغرتين. يحتاج إلى معرفة هل موقعه متأثر، وماذا تفعل، وماذا يتغير بالنسبة إليه. تكفي رسالتان قصيرتان قابلتان للتكييف. حافظ على النبرة الوقائعية نفسها: الإصدار المقروء، والتاريخ، والخطوة التالية. لا تكتب أن الموقع محمي أو مؤمَّن: الإصدار المقروء ليس دليلًا على غياب الاختراق.
رسالتان نموذجيتان
عميل مطّلع على حالة موقعه
«مرحبًا، قرأنا إصدار PHP لموقعكم بتاريخ [التاريخ]. كان [الإصدار]، أقدم من التصحيح الذي نشره مشروع PHP لخللين حرجين. سنحدّثه بتاريخ [التاريخ] دون انقطاع متوقع. ثم نرسل لكم إثباتًا مؤرخًا للإصدار العامل. لا يلزمكم أي إجراء. إن كانت لديكم أسئلة فأجيبوا على هذه الرسالة.»
عميل لا يمكن ترحيل موقعه فورًا
«مرحبًا، يعمل موقعكم بإصدار PHP لم يعد يتلقى تصحيحات من المشروع. يتطلب الترحيل [الأعمال]، ونقترحه بتاريخ [التاريخ]. وفي الأثناء نطبّق [الإجراء: حزمة مصححة من المستضيف، أو إزالة نموذج رفع الملفات، أو التصفية]. تخفف هذه الإجراءات الخطر دون أن تزيله. نرجو تأكيد التاريخ المعتمد قبل [التاريخ].»
إثبات التصحيح ثم إعادة الجرد
إثبات التصحيح سجل لكل موقع: القياس قبل التدخل، والتدخل، والقياس نفسه بعده، واللقطة أو مخرجات الأمر، ورقم الإصدار، والتاريخ، واسم المنفِّذ. إعادة القياس نفسه بالطريقة نفسها هي ما يجعل الإثبات قابلًا للمقارنة. احتفظ بالسجل الزمني مع السجل.
تذكّر الحدّ: الإصدار المقروء يثبت الإصدار المقدَّم لحظة القياس، لا غياب اختراق سبق التحديث. وإذا بقي موقع مكشوفًا بعد 21 أكتوبر 2026 فالبحث عن آثار الاستغلال عمل ثانٍ يصفه مقال PHP2Shell.
الإيقاع: جرد كل فصل وعند كل محفّز
أعد الجرد كل فصل، وعند كل ثغرة CVE حرجة جديدة وعند نهاية عمر كل فرع. قارن القياسين: الانحراف هو موقع انخفض إصداره أو عاد مستوى ثقته إلى مفترض. دوّن في السجل تواريخ نهاية العمر المهمة. بالنسبة إلى PHP 8.2 يحدد المشروع 31 ديسمبر 2026؛ وقائمة الترحيل إلى 8.3 أو 8.4 في المقال المخصص. الدفعة الأولى من الجرد التالي معروفة سلفًا: كل ما بقي على 8.2 في الأول من يناير.
الوثائق الرسمية
- إشعار PHP بتاريخ 21 أكتوبر 2026 — https://www.php.net/archive/2026.php#2026-10-21-5
- إصدارات PHP المدعومة — https://www.php.net/supported-versions.php
- تنبيه CISA بتاريخ 26 أكتوبر 2026 — https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog
- مستودع php2shell لدى NCSC-NL — https://github.com/NCSC-NL/php2shell
- إشعار AlmaLinux عن الحزم المصححة — https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/
- MultiPHP Manager (cPanel) — https://docs.cpanel.net/cpanel/software/multiphp-manager-for-cpanel/
- wp cli info — https://developer.wordpress.org/cli/commands/cli/info/
