Morocco Next Technologies (MNT) · 21/10/2026 · PHP2Shell · CVE-2026-109618 · CVE-2026-109619
في 21 أكتوبر 2026، أُعلن عن ثغرتين حرجتين في محرك PHP تحملان المعرفين CVE-2026-109618 وCVE-2026-109619، ونُشرت تحديثات أمنية لمعالجتهما. وقد تسمحان، في ظروف محددة، بتنفيذ تعليمات برمجية عن بُعد دون مصادقة.
في Morocco Next Technologies (MNT)، نوصي باستجابة عملية ومنظمة: تحديد الأنظمة المعرضة للخطر، تثبيت التصحيحات الموثوقة، ثم التأكد من أن الخدمات الفعلية تعمل بإصدارات آمنة. ويشمل هذا الدليل خوادم VPS وبيئات Docker وDocker Swarm وKubernetes.
فهم المخاطر
ترتبط الثغرتان بإدارة الذاكرة داخل محرك PHP. لذلك قد يظل تطبيق Laravel أو Symfony أو WordPress معرضاً للخطر حتى لو كان كوده محدثاً، ما دام محرك PHP المستخدم غير مصحح.
أول الإصدارات المصححة رسمياً هي PHP 8.2.35 و8.3.36 و8.4.27 و8.5.12. وقد توفر توزيعات Linux التصحيحات ضمن حزم تحمل أرقاماً مختلفة، لذا يجب الرجوع إلى النشرات الأمنية الرسمية للمورّد.
1. تصحيح PHP على خادم VPS
على Ubuntu أو Debian، نتحقق أولاً من إصدار PHP في سطر الأوامر، وخدمات PHP-FPM النشطة، وإعدادات خادم الويب. فقد توجد عدة إصدارات من PHP على الجهاز نفسه.
بعد أخذ النسخ الاحتياطية والتأكد من توفر الحزم المصححة في المستودعات، تُحدّث الحزم المعنية ويُعاد تشغيل PHP-FPM. ثم تُراجع الإضافات واستجابة التطبيق والسجلات.
- php -v
- systemctl list-units --type=service --all | grep php
- sudo apt update
- apt-cache policy php8.3-fpm php8.3-cli
- sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
- sudo systemctl restart php8.3-fpm
- sudo systemctl status php8.3-fpm
2. تحديث صور Docker وDocker Compose
محرك PHP داخل الحاوية مستقل عن النظام المضيف؛ لذلك لا يكفي تحديث VPS لإصلاح صورة Docker قديمة. نتحقق من إصدار الحاوية، ونعيد بناء الصورة باستخدام أساس مصحح، ثم نعيد نشر الخدمة.
سطر FROM التالي مثال على صورة أساسية مصححة، وليس ملف Dockerfile كاملاً للإنتاج. يجب التأكد من توفر الصورة وتوافق الإضافات والتطبيق قبل النشر.
- docker ps
- docker exec NOM_CONTENEUR php -v
- FROM php:8.3.36-fpm-alpine
- docker build --pull --no-cache -t mon-application:php2shell-fixed .
- docker run --rm mon-application:php2shell-fixed php -v
- docker compose build --pull
- docker compose up -d
3. نشر الإصلاح عبر Docker Swarm
يجب نشر الصورة المصححة في سجل تستطيع عقد Swarm الوصول إليه، ثم تحديث كل خدمة متأثرة تدريجياً. وقد يساعد النشر المتدرج في تقليل الانقطاع عندما تسمح البنية بذلك.
ينبغي التحقق من جميع النسخ النشطة والسجلات والفحوص الصحية. والعودة إلى صورة قديمة معرضة للخطر لا تُعد حلاً أمنياً.
- docker service ls
- docker service ps NOM_SERVICE --no-trunc
- docker service update --image registry.example.com/app:php2shell-fixed --update-parallelism 1 --update-delay 10s --update-order start-first --update-failure-action rollback NOM_SERVICE
- docker service ps NOM_SERVICE --no-trunc
4. تصحيح تطبيقات Kubernetes
نحدد التطبيقات التي تستخدم PHP، ثم ننشر الصورة المصححة ونحدّث Deployments المعنية. تفترض الأوامر التالية وجود مساحة أسماء production وحاوية اسمها php؛ ويجب تعديلها بحسب إعداداتكم.
إذا كانت Helm أو Argo CD أو Flux تدير النشر، فيجب تحديث ملفات الإعداد الأصلية أيضاً لمنع عودة الصورة القديمة تلقائياً. ثم تُفحص جميع Pods والإصدارات المستخدمة فعلياً.
- kubectl get pods -A
- kubectl -n production set image deployment/mon-application php=registry.example.com/php-app:php2shell-fixed
- kubectl -n production rollout status deployment/mon-application
- kubectl -n production get pods -o wide
التحقق والمراقبة بعد التحديث
نجاح الأمر لا يعني بالضرورة اكتمال المعالجة. يجب فحص الإصدارات الفعلية وتوفر التطبيق وأخطاء HTTP والسجلات وأي نشاط غير معتاد.
عند الاشتباه في اختراق، يجب عزل الأنظمة المتأثرة، والحفاظ على الأدلة، والتحقيق في محاولات الوصول، وتغيير بيانات الاعتماد المكشوفة. ولا تغني إجراءات التصفية المؤقتة عن التصحيح الرسمي.
رؤيتنا في MNT
تؤكد PHP2Shell أهمية جرد محركات التشغيل وصور الحاويات والاعتماديات البرمجية، وربط ذلك بمسارات CI/CD تتضمن فحوصاً أمنية.
توصيتنا هي التدخل السريع والمنظم: تحديد نطاق التعرض، وتثبيت التصحيحات المناسبة، وتوثيق التحقق من كل نسخة تعمل في الإنتاج.
Morocco Next Technologies — حلول رقمية مصممة لتلبية تحدياتكم وبناء ثقة تدوم.