العودة إلى المدونة

ثغرة PHP2Shell في PHP: كيف تحدّث سيرفرك وتستعيد موقعك بعد الاختراق

فريق تحرير IM Host22 أكتوبر 202612 دقائق قراءة
ثغرة PHP2Shell في PHP: كيف تحدّث سيرفرك وتستعيد موقعك بعد الاختراق

في 21 أكتوبر 2026 أصدر مشروع PHP تحديثات أمنية عاجلة لسد ثغرتين تسمحان لمهاجم بتشغيل أوامر على سيرفر الموقع دون تسجيل دخول. الثغرتان مسجلتان برقمي CVE-2026-109618 وCVE-2026-109619، وتُعرفان معًا باسم PHP2Shell، ودرجة خطورتهما 9.2 على مقياس CVSS. ورُصدت محاولات لاستغلالهما منذ 17 أكتوبر، أي قبل إعلان الإصلاح بأربعة أيام.

يشرح هذا الدليل الثغرتين، وكيف تعرف إن كان موقعك متأثرًا، وكيف تحدّث PHP على أشهر بيئات التشغيل، وماذا تفعل إن لم تستطع التحديث اليوم، وكيف تستعيد موقعك بطريقة آمنة إن كان قد اختُرق قبل التحديث.

الخلاصة في سطور

  • حدّث PHP الآن إلى 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35 (أو الحزمة المُصلحة من توزيعة لينكس التي تستخدمها)، ثم أعد تشغيل كل عمليات PHP.

  • كل طرق تشغيل PHP على الويب متأثرة: PHP-FPM وmod_php على Apache وphp-cgi وFrankenPHP وLiteSpeed.

  • الإصدارات من 7.4 إلى 8.1 حصلت على تعديلات محدودة في الكود المصدري فقط، والإصدارات من 5.4 إلى 7.3 انتهى دعمها ولن يصلها أي إصلاح.

  • الإعدادات المؤقتة تقلل الخطر لكنها ليست علاجًا. التحديث هو الحل الكامل الوحيد.

  • إذا ظل موقعك بلا تحديث بعد 17 أكتوبر، فافحصه بحثًا عن آثار اختراق. وإن وجدت أي أثر، فاسترجعه من نسخة احتياطية أُخذت قبل هذا التاريخ، وبعد تحديث PHP فقط.

ما الذي حدث: التسلسل الزمني

  • 17 أكتوبر: رصدت Amazon Threat Intelligence محاولة استغلال على أنظمة المراقبة الخاصة بها، قبل أي إعلان رسمي.

  • 20 أكتوبر: بدأ تداول أرقام الثغرات، وأعلن مشروع PHP عن موعد مبكر للإصدار.

  • 21 أكتوبر، الساعة 14:00 بتوقيت UTC: صدرت النسخ المُصلحة والنشرة الأمنية. وفي اليوم نفسه أعلنت Amazon وCloudflare وwatchTowr عن محاولات استغلال إضافية، بعضها من جهات مختلفة.

تتحدث بعض التقارير عن كود استغلال منشور، لكن لم يتأكد أحد من أنه يعمل حتى وقت كتابة هذا المقال. هذا يتغير بسرعة مع برنامج منتشر بحجم PHP، لذلك الافتراض الآمن هو أن استغلالًا فعّالًا موجود أو سيظهر قريبًا.

الثغرتان بلغة بسيطة

CVE-2026-109618: تلف في الذاكرة عند نفادها

عندما تنفد الذاكرة المتاحة لـ PHP وهو ما زال يجهّز الطلب، قد يتوقف في منتصف الطريق. بعدها تتعامل خطوة التنظيف مع بيانات لم تكتمل كأنها سليمة. ويستطيع المهاجم إحداث ذلك بطلب multipart معدّ خصيصًا (النوع المستخدم في النماذج ورفع الملفات)، حتى لو بدا الطلب ملتزمًا بالحدود المضبوطة للحجم.

على Apache مع mod_php تعمل خطوة التنظيف حتى عندما يفشل بدء الطلب، فينجح الهجوم قبل أن يعمل كود موقعك أصلًا. ولهذا يعتبر فريق PHP أن mod_php هو الإعداد الأعلى خطورة.

CVE-2026-109619: بقايا طلب سابق

هذه ثغرة من نوع use-after-free: قد تظل بيانات داخلية من طلب سابق تشير إلى ذاكرة تم تحريرها بعد انتهائه، ثم يستخدمها طلب لاحق يعالجه نفس الـ worker. وقد أكد فريق PHP أنها تسمح بتشغيل أوامر وبكشف محتوى من الذاكرة. والمساران المُثبتان هما:

  • متابعة تقدم رفع الملفات في الجلسات (session upload progress)، وهي مفعّلة افتراضيًا ولا تحتاج أن يستدعي موقعك session_start(). تم إثباتها على mod_php وعلى PHP-FPM.

  • تتبع الأخطاء القاتلة في PHP 8.5 (fatal_error_backtraces، المفعّل افتراضيًا أيضًا)، وتم إثباتها على mod_php.

ويقول الباحثون الذين اكتشفوا الثغرتين إنهم نجحوا في تشغيل أوامر دون تسجيل دخول على إصدارات معينة من ووردبريس وDrupal وJoomla وMagento. وإخفاء الأخطاء عبر display_errors أو error_reporting أو العلامة @ لا يمنع أيًا من الثغرتين.

الخطوة 1: اعرف كل نسخ PHP التي تشغّلها

كثير من السيرفرات تشغّل أكثر من إصدار: إصدار لسطر الأوامر، وإصدارات أخرى للمواقع المختلفة. والإصدار المهم هو الذي يخدم طلبات الويب، لذلك افحصها كلها.

# إصدار سطر الأوامر
php -v

# حزم PHP المثبتة (Debian / Ubuntu)
dpkg -l | grep -E '^ii +php[0-9.]+-(fpm|cli|common)'

# حزم PHP المثبتة (AlmaLinux / Rocky / RHEL)
rpm -qa | grep -i php

# ما يعمل فعليًا الآن
ps aux | grep -E 'php-fpm|php-cgi|lsphp|frankenphp' | grep -v grep

# هل يحمّل Apache وحدة mod_php؟
apache2ctl -M 2>/dev/null | grep -i php || httpd -M 2>/dev/null | grep -i php

على سيرفرات cPanel تعرض أداة MultiPHP Manager الإصدار المستخدم لكل دومين. ومع Docker افحص كل حاوية بالأمر docker exec <container> php -v.

لا تحكم من رقم الإصدار وحده. توزيعات مثل Ubuntu وDebian وRHEL كثيرًا ما تضيف الإصلاحات الأمنية مع الإبقاء على رقم إصدار قديم. حزمة تظهر 8.3.6 قد تكون مُصلحة، وحزمة برقم أحدث قد تظل معرضة للخطر. راجع النشرة الأمنية للتوزيعة أو سجل تغييرات الحزمة وابحث عن رقم الثغرة.

الخطوة 2: حدّث، ثم أعد التشغيل، ثم تأكد

Ubuntu وDebian

sudo apt update
sudo apt upgrade

# تأكد أن الإصلاح موجود في الحزمة المثبتة (غيّر رقم الإصدار حسب سيرفرك)
apt changelog php8.3-common | grep -m3 'CVE-2026-10961'

# أعد تشغيل PHP وسيرفر الويب
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # أو nginx

إذا كنت تستخدم مستودع Ondřej Surý أو أي مستودع خارجي آخر، فهو يتحدث بشكل منفصل عن التوزيعة، فتأكد أنه نشر النسخة المُصلحة قبل أن تعتبر نفسك في أمان.

AlmaLinux وRocky Linux وRHEL

sudo dnf update 'php*'
rpm -q --changelog php-common | grep -m3 'CVE-2026-10961'
sudo systemctl restart php-fpm httpd

أشارت نشرة PHP إلى أن مستودع Remi لن يحتوي على التحديثات يوم الإصدار، وأوصت بحزم التوزيعة أو البناء من الكود المصدري في الوقت الحالي. إذا كنت تعتمد على Remi فتأكد من وجود حزمة مُصلحة قبل أن تكمل.

cPanel / WHM

يأتي PHP على cPanel في حزم باسم ea-php. حدّثها ثم راجع MultiPHP Manager:

sudo dnf update 'ea-php*'

بعدها أعد تشغيل PHP-FPM من WHM، أو أعد تشغيل Apache إذا كان أحد الدومينات يستخدم معالجًا غير FPM.

Docker

الحاوية التي تعمل لا تحدّث نفسها. اسحب صورة الأساس المُصلحة، وأعد بناء صورتك عليها، واستبدل الحاوية العاملة:

docker compose build --pull
docker compose up -d
docker compose exec app php -v

LiteSpeed وFrankenPHP

على LiteSpeed حدّث حزم lsphp ثم أعد تشغيل سيرفر الويب حتى تتوقف عمليات lsphp القديمة. وعلى FrankenPHP حدّث إلى إصدار مبني على PHP المُصلح ثم أعد تشغيله.

لماذا إعادة التشغيل ضرورية

التحديث يستبدل الملفات على القرص، لكن عمليات PHP-FPM وApache الموجودة في الذاكرة تستمر في تشغيل الكود القديم حتى يُعاد تشغيلها. ملفات مُصلحة مع عمليات قديمة تعني أنك ما زلت مكشوفًا. وبعد إعادة التشغيل افحص الإصدار العامل مرة أخرى.

الخطوة 3: إذا لم تستطع التحديث اليوم

إذا لم تصدر حزمة مُصلحة لبيئتك بعد، أو كنت تحتاج نافذة صيانة، فهذه الإعدادات تقلل الخطر. كل إعداد منها يغطي جزءًا من المشكلة فقط وله آثار جانبية، فاعتبرها حلًا مؤقتًا إلى أن تحدّث.

ويجب ضبطها على مستوى الإدارة بحيث لا يستطيع التطبيق تغييرها. ضبطها عبر ini_set() أو في ملف .user.ini يأتي متأخرًا ولا يفيد.

في إعداد PHP-FPM pool (مثلًا /etc/php/8.3/fpm/pool.d/www.conf):

php_admin_value[memory_limit] = -1
php_admin_flag[session.upload_progress.enabled] = off
; لـ PHP 8.5 فقط:
php_admin_flag[fatal_error_backtraces] = off

على Apache مع mod_php (في إعداد الـ virtual host أو السيرفر):

php_admin_value memory_limit -1
php_admin_flag session.upload_progress.enabled off
# لـ PHP 8.5 فقط:
php_admin_flag fatal_error_backtraces off

ثم أعد تشغيل كل عمليات PHP.

ماذا يفعل كل إعداد، وما ثمنه:

  • memory_limit = -1 يزيل نقطة نفاد الذاكرة المتوقعة التي يعتمد عليها الاستغلال المعروف للثغرة CVE-2026-109618. والثمن أن سكربتًا واحدًا خرج عن السيطرة يستطيع استهلاك كل ذاكرة السيرفر. حد الذاكرة على مستوى الحاوية أو الـ cgroup يحمي استمرارية الخدمة لكنه لا يجعلك في أمان، ويحذّر فريق PHP من استخدام RLIMIT_AS أو RLIMIT_DATA لأنهما قد يفتحان المسار المعرض للخطر بأنفسهما.

  • session.upload_progress.enabled = 0 يغلق مسار الجلسات المُثبت في الثغرة CVE-2026-109619. قليل من المواقع يستخدم شريط تقدم الرفع، فالثمن غالبًا بسيط.

  • fatal_error_backtraces = 0 (في PHP 8.5 فقط) يغلق مسار تتبع الأخطاء المُثبت.

  • حدود الطلبات. يقترح فريق PHP ضبط post_max_size = 8M إذا لم تكن تحتاج رفع ملفات، أو 32M إذا كنت تحتاجه، مع جعل upload_max_filesize أقل منه. وعلى مستوى الـ reverse proxy أو الـ WAF حدّد حجم الطلب وعدد أجزاء multipart. وإذا كان التطبيق لا يستقبل نماذج بملفات أصلًا، فامنع طلبات multipart قبل أن تصل إلى PHP.

  • جدار حماية تطبيقات الويب (WAF)، مثل القواعد الطارئة من Cloudflare، يحمي فقط الزيارات التي تمر من خلاله. أي شخص يصل إلى عنوان IP الخاص بالسيرفر مباشرة يتخطاه.

الخطوة 4: هل دخل أحد قبل أن تحدّث؟

التحديث يغلق الثغرة، لكنه لا يخبرك إن كان أحد قد استغلها بين 17 أكتوبر ولحظة التحديث. ينصح المحققون ببدء المراجعة من 17 أكتوبر، وكل النشرات الأمنية تكرر التحذير نفسه: عدم وجود سجلات مريبة لا يثبت أن السيرفر سليم.

أين تبحث:

# ملفات PHP أُنشئت أو عُدّلت منذ 17 أكتوبر
find /var/www /home -type f -name '*.php' -newermt '2026-10-17' -ls 2>/dev/null

# ملفات PHP داخل مجلدات الرفع (المفترض ألا يوجد أي منها)
find /var/www /home -path '*/uploads/*' -name '*.php' 2>/dev/null

# حسابات المدير في ووردبريس وتاريخ إنشائها
wp user list --role=administrator --fields=ID,user_login,user_registered

# المهام المجدولة لمستخدم الويب وللنظام
sudo crontab -l -u www-data
ls -la /etc/cron.d /var/spool/cron

# مفاتيح SSH غير معروفة
sudo cat /root/.ssh/authorized_keys

# توقف متكرر لعمليات PHP منذ 17 أكتوبر
journalctl -u php8.3-fpm --since '2026-10-17' | grep -iE 'signal|segfault'

# عمليات غير مألوفة لديها اتصالات شبكة
sudo ss -tupn

من العلامات المقلقة: حسابات مدير لم ينشئها أحد من فريقك، وملفات PHP بأسماء عشوائية أو محتوى مشفّر، ومهام cron جديدة، ومفاتيح SSH غير معروفة، واتصالات خارجية غير متوقعة، وروابط سبام أو تحويلات لا تظهر إلا لمحركات البحث أو لزوار الموبايل. ويستطيع المهاجم تغيير تواريخ الملفات، لذلك النتيجة النظيفة من أمر find مطمئنة لكنها ليست دليلًا قاطعًا.

الخطوة 5: التعافي بعد الاختراق

إذا وجدت آثار اختراق، أو كان موقعك يتعامل مع بيانات حساسة وظل بلا تحديث لأيام، فتعامل مع الأمر كحادث أمني. الترتيب هنا مهم، والخطأ الأكثر شيوعًا هو الاسترجاع قبل التحديث.

  1. احتوِ المشكلة. ضع الموقع في وضع الصيانة أو امنع الزيارات العامة. وإذا كان على السيرفر مواقع أخرى، فافترض أنها قد تكون متأثرة أيضًا.

  2. احفظ الأدلة. خذ snapshot أو نسخة كاملة من الوضع الحالي قبل أي تغيير. ستحتاجها لتعرف ما حدث وما البيانات التي تعرضت للكشف.

  3. حدّث أولًا. حدّث PHP وأعد تشغيله قبل استرجاع أي شيء. استرجاع موقع نظيف على PHP معرض للخطر يعيده مباشرة في متناول الهجوم نفسه.

  4. استرجع من نقطة سليمة. استخدم نسخة احتياطية أُخذت قبل 17 أكتوبر. وإذا لم تكن متأكدًا من سلامة السيرفر نفسه (مستخدمو نظام جدد، أو مفاتيح SSH غير معروفة، أو ملفات نظام معدّلة)، فالبناء على سيرفر جديد أكثر أمانًا من تنظيف القديم.

  5. أعد تثبيت الكود من مصادره الرسمية. حمّل نسخًا جديدة من نواة الـ CMS والإضافات والقوالب بدلًا من الوثوق بملفات السيرفر المخترق.

  6. غيّر كل الأسرار التي يستطيع التطبيق قراءتها. هذا يشمل كلمات مرور قاعدة البيانات، ومفاتيح الـ API، ومفاتيح بوابات الدفع، وبيانات SMTP، ومفاتيح salts في ملف wp-config.php، والمفتاح APP_KEY في Laravel، ومفاتيح SSH. وألزم المديرين بتغيير كلمات مرورهم. الثغرة CVE-2026-109619 قد تكشف محتوى من الذاكرة، لذلك قد تكون قيم لم يكتبها المهاجم على القرص قد تسربت أيضًا.

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

  8. راقب عن قرب لعدة أسابيع. تابع ظهور حسابات مدير جديدة، وتغيّر الملفات، والاتصالات الخارجية. المهاجم الذي احتفظ بموطئ قدم كثيرًا ما يعود.

  9. راجع التزامات الإبلاغ. إذا كان هناك احتمال للوصول إلى بيانات شخصية، فقد تُلزمك قوانين حماية البيانات، مثل القانون المصري رقم 151 لسنة 2020 أو اللائحة الأوروبية GDPR، بإبلاغ الجهة المختصة أو المستخدمين المتأثرين خلال مدة محددة. استشر مستشارك القانوني مبكرًا.

ولخطوات الاسترجاع نفسها، راجع دليلنا للنسخ الاحتياطي والاسترجاع في ووردبريس.

دروس تستحق الاحتفاظ بها بعد التحديث

  • احتفظ بنسخ احتياطية قديمة بما يكفي. في هذه الأزمة كانت هناك أربعة أيام قبل الإعلان. ما ينقذك هو وجود نقطة استرجاع من قبل بداية المشكلة، وهذا يعتمد على مدة الاحتفاظ بالنسخ وليس فقط على عدد مرات أخذها. ووجود نسخة خارج السيرفر نفسه مهم أيضًا. يشرح دليلنا عن استراتيجية 3-2-1 للنسخ الاحتياطي على VPS هذه النقطة.

  • جرّب الاسترجاع قبل أن تحتاجه. النسخة الاحتياطية التي لم تسترجعها من قبل أمنية، وليست خطة.

  • احتفظ بقائمة بإصدارات PHP. معرفة أي سيرفر يشغّل أي إصدار تحوّل يومًا عصيبًا إلى قائمة مهام قصيرة.

  • تخلص من إصدارات PHP المنتهية. المواقع على PHP 7.3 أو أقدم لن تحصل على إصلاح رسمي لهذه الثغرة ولا لأي ثغرة قادمة.

  • اكتب خطوات التعافي الآن، بما في ذلك من يقرر إيقاف الموقع ومن يتواصل مع العملاء. ووجود سيرفر احتياطي في موقع ثانٍ، كما في دليلنا للتعافي من الكوارث، يقلل مدة التوقف أكثر.

  • أمّن السيرفر حول PHP. استخدم مفاتيح SSH وجدار حماية وfail2ban، كما في دليلنا لـ تأمين Linux VPS.

إذا كنت تستضيف موقعك لدى IM HOST

حدّثنا PHP على سيرفرات الاستضافة لدى IM HOST فور الإعلان عن الإصلاح، ولم يتأثر أي عميل من عملائنا. وهذا ما تقدمه كل خدمة إذا احتجت إلى استرجاع أو مساعدة:

  • الاستضافة المشتركة واستضافة ووردبريس واستضافة التطبيقات تشمل نسخًا احتياطيًا يوميًا مجانيًا طوال مدة الاشتراك. والاسترجاع يتم عن طريق فريق الدعم عند الطلب: أخبرنا بالموقع والتاريخ الذي تريد الرجوع إليه، وسنؤكد لك نقاط الاسترجاع المتاحة.

  • Cloud VPS يشمل نسخة احتياطية تلقائية مجانية كل 72 ساعة طوال مدة الاشتراك.

  • Linux VPS غير مُدار افتراضيًا: لديك صلاحيات root كاملة، فتحديث PHP ونظام التشغيل مسؤوليتك، والخطوات أعلاه تنطبق عليه مباشرة. وتتوفر إضافتا Daily Backups وManaged Support إذا كنت تفضّل ألا تتولى ذلك وحدك.

تحتاج مساعدة في فحص موقع، أو استرجاع نسخة احتياطية، أو الانتقال من إصدار PHP قديم؟ تواصل مع الدعم الفني لـ IM HOST.

أسئلة شائعة

هل ووردبريس متأثر؟

نعم. الثغرتان في PHP نفسه، لذلك يمكن الوصول إلى أي تطبيق PHP، بما فيه ووردبريس وWooCommerce وDrupal وJoomla وMagento وLaravel. تحديث ووردبريس أو إضافاته لا يحل المشكلة، المطلوب هو تحديث PHP.

موقعي خلف Cloudflare، هل ما زلت أحتاج التحديث؟

نعم. قواعد الـ WAF تغطي أنماط الهجوم المعروفة فقط، وللزيارات التي تمر عبر Cloudflare فقط. إذا كان عنوان IP الخاص بسيرفرك يمكن الوصول إليه مباشرة، فالحماية يمكن تخطيها. استخدم الـ WAF لكسب الوقت، لا كبديل عن التحديث.

سيرفري يظهر PHP 8.3.6، هل أنا معرض للخطر؟

ليس بالضرورة. حزم التوزيعات كثيرًا ما تحتفظ برقم إصدار قديم وتضيف إليه الإصلاحات الأمنية. راجع النشرة الأمنية لتوزيعتك، أو ابحث في سجل تغييرات الحزمة عن CVE-2026-109618 وCVE-2026-109619.

هل يكفي ضبط memory_limit على ‎-1؟

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

أنا على PHP 7.4، ماذا أفعل؟

الإصدارات من 7.4 إلى 8.1 حصلت على تعديلات محدودة في الكود المصدري فقط، والإصدارات الأقدم لن تحصل على شيء. الخيارات العملية هي توزيعة أو مزود دعم طويل الأمد أصدر حزمة مُصلحة، أو الترقية إلى PHP 8.2 أو أحدث. وإذا لم يكن أي منهما ممكنًا فورًا، فطبّق الإعدادات المؤقتة أعلاه وأبقِ الموقع خلف WAF حتى تتمكن من الترقية.

حدّثت يوم 21 أكتوبر، هل أنا في أمان؟

أنت في أمان من المحاولات الجديدة عبر هاتين الثغرتين. لكن المحاولات رُصدت منذ 17 أكتوبر، لذلك يستحق الأمر تنفيذ فحوصات الخطوة 4 للأيام التي سبقت التحديث.

المصادر

المزيد من مدونتنا

اكتشف المزيد من الأدلة العملية ورؤى الخدمات من فريق IM Host.

عرض كل المقالات