This article is available in English — Read in English
تحديث 21 أكتوبر 2026، الساعة 5:40 مساء بتوقيت القاهرة: صدر الإصلاح. أطلق فريق PHP يوم 21 أكتوبر الإصدارات 8.5.12 و8.4.27 و8.3.36 و8.2.35، ونشر نشرة أمنية رسمية. وبحسب PHP فإن كل الإصدارات السابقة لها متأثرة، في كل بيئة تخدم طلبات ويب، ومنها PHP-FPM وApache مع mod_php وphp-cgi وFrankenPHP وLiteSpeed. حدث الآن.
تحديث 21 أكتوبر 2026، الساعة 2:55 مساء بتوقيت القاهرة: بدأت الهجمات بالفعل. تلقت Patchstack بلاغات عن استغلال فعلي من عدة شركات استضافة شريكة الساعة 07:34 UTC (10:34 صباحا بتوقيت القاهرة)، وأعلن المدير التقني لشركة Cloudflare رصد هجمات مبكرة الساعة 07:43 UTC (10:43 صباحا بتوقيت القاهرة). أضفنا بالأسفل الإصدارات المتوقع أن تحمل الإصلاح، والحلول المؤقتة الجزئية، والخطوات الاحتياطية.
تنبيه بالتحديث: نشر هذا المقال أول مرة قبل صدور الإصلاح الرسمي لثغرات php2shell الخطيرة في PHP، وهي CVE-2026-109618 وCVE-2026-109619. أصدر فريق PHP الإصلاح الآن، والإصدارات المتأثرة والمصلحة المذكورة بالأسفل مأخوذة من php.net.
تسربت يوم 20 أكتوبر تفاصيل ثغرتين خطيرتين في لغة PHP نفسها تسمحان بتنفيذ أوامر عن بعد، وهما CVE-2026-109618 وCVE-2026-109619، وذلك قبل موعد الإفصاح المنسق وقبل وجود أي تصحيح. يطلق الباحثون على الثغرتين اسم php2shell. فريق أمان PHP أكد المشكلة في إشعار رسمي مسبق، وقيم الثغرتين بدرجة 9.2 على مقياس CVSS v4.0، وقدم موعد الإصدار الأمني. لو عندك موقع ووردبريس أو متجر WooCommerce أو أي موقع شركة يعمل على PHP، فهذا هو الأسبوع الذي لازم تعرف فيه بالضبط إصدار PHP على السيرفر، ومن المسؤول عن تحديثه.
نلتزم في هذا المقال بما نشره فريق PHP وباحثون أمنيون معروفون بالاسم. نشر فريق PHP الآن الإصدارات المتأثرة والمصلحة، ونذكرها كما وردت على php.net بالضبط. لكن نقدر نوضح المعروف، وماذا يعني لموقعك، والخطوات العملية قبل الإصلاح وبعده.
ماذا حدث؟
بحسب تقرير الاستجابة السريعة من Huntress، ظهر صباح 20 أكتوبر منشور على موقع Hacker News يقول إن ثغرتين خطيرتين في PHP في طريقهما للإفصاح العلني. حذف المنشور، لكن لقطات الشاشة انتشرت على مواقع التواصل. وخلال ساعات أكد فريق الأبحاث في watchTowr أن الثغرات حقيقية، وأنه أعاد إنتاج الثغرة CVE-2026-109618، وأن الجميع كان من المفترض أن ينتظر حتى يوم الخميس الساعة 11 صباحا بتوقيت شرق أمريكا موعد الإفصاح المنسق.
بعدها بقليل نشر فريق أمان PHP إشعارا مسبقا على موقع php.net. يقول الإشعار إن الإصدار مقرر يوم الأربعاء 21 أكتوبر 2026 الساعة 14:00 بتوقيت UTC، وإنه يعالج ثغرتين خطيرتين بدرجة 9.2 على CVSS v4.0، ويدعو كل مستخدمي PHP إلى الاستعداد من الآن للتحديث فور توفر الإصدار. وأضاف الفريق أنه يحتفظ بحق إصدار التحديث مبكرا إذا خرجت تفاصيل أي من الثغرتين للعلن أو ظهرت أدلة على استغلال فعلي. التفاصيل الكاملة والإصدارات المتأثرة والمصلحة ستنشر مع الإصدار نفسه.
وذكرت Huntress أيضا أن فيديو قصيرا يعرض الاستغلال نشر لفترة قصيرة ثم حذف، وأنها حتى وقت نشر تقريرها لم ترصد أي استغلال فعلي في بيئات شركائها.
المعروف وغير المعروف حتى الآن
| السؤال | الإجابة الحالية | المصدر |
|---|---|---|
| هل الثغرات حقيقية؟ | نعم. أكد فريق PHP وجود ثغرتين خطيرتين، وأعادت watchTowr إنتاج CVE-2026-109618. | php.net، وHuntress نقلا عن watchTowr |
| ما مدى خطورتها؟ | الثغرتان بدرجة 9.2 على CVSS v4.0، أي خطيرة. | php.net |
| ما نوع الثغرة؟ | التقارير العلنية تصفها بتنفيذ أوامر عن بعد في نواة PHP. | Huntress |
| متى الإصلاح؟ | صدر يوم 21 أكتوبر 2026: PHP 8.5.12 و8.4.27 و8.3.36 و8.2.35. | php.net |
| ما الإصدارات المتأثرة؟ | رسميا: كل إصدارات PHP قبل 8.5.12 و8.4.27 و8.3.36 و8.2.35، بحسب نشرتي PHP. أما PHP 8.1 وما قبلها فلم تعد تحصل على تحديثات من مشروع PHP. | php.net |
| هل ستحصل الإصدارات القديمة على إصلاح؟ | لا يوجد إصدار رسمي. PHP 8.1 وما قبلها لا تحصل على تحديثات من مشروع PHP، لكن فريق أمان PHP نشر تصحيحات مصدرية مختصرة للإصدارات 7.4 و8.0 و8.1، وبعض التوزيعات وشركات الدعم الطويل توفر إصلاحات منقولة. | php.net |
| هل يوجد كود استغلال منشور؟ | يتداول كود يزعم استغلال الثغرات، لكن Tenable لم تتحقق من أنه يعمل وتحذر من أنه قد يحتوي على برمجيات خبيثة. | Tenable |
| هل رصد استغلال فعلي؟ | نعم. أبلغت عدة شركات استضافة Patchstack باستغلال فعلي (07:34 UTC)، وأعلن المدير التقني لـ Cloudflare رصد هجمات مبكرة (07:43 UTC). | Patchstack |
توضح Huntress أنه لم ينشر أي سبب تقني حتى الآن. لا أحد خارج دائرة الإفصاح المنسق يعرف علنا أي جزء من PHP فيه المشكلة، ولا هل يمكن الوصول إليها بطلب ويب عادي، ولا هل تعتمد على إعدادات معينة. الاسم php2shell يلمح لأسوأ سيناريو، أن يرسل شخص طلبا لموقعك فيحصل على تحكم في السيرفر، لكنه في النهاية اسم وليس طريقة هجوم مؤكدة.
لماذا هذه الثغرة أخطر من ثغرة إضافة عادية؟
أغلب أخبار أمان ووردبريس تخص إضافة واحدة أو قالبا واحدا. تحدث الإضافة وينتهي الأمر. هنا الوضع مختلف، لأن الخلل في PHP نفسها، اللغة التي يعمل عليها كل موقع ووردبريس. وكما تقول Huntress، تشغل PHP بهدوء مواقع ووردبريس ودروبال وجوملا وماجنتو، ومنصات الاستضافة المشتركة، ولوحات التحكم، وبرامج كثيرة لا تذكر أصلا أنها تعمل بها.
وهذا له نتيجتان عمليتان. الأولى أن إضافة الحماية وقواعد الجدار الناري الخاصة بووردبريس والتحديث التلقائي للإضافات لا تصلح PHP، لأنها جزء من السيرفر، والإصلاح يأتي ممن يدير السيرفر. والثانية أن ثغرة تنفيذ أوامر على مستوى اللغة، لو ثبت أنها قابلة للوصول من الويب، ستكون تحت كل تطبيق على السيرفر وليس ووردبريس وحده.
ماذا تعني ثغرات php2shell لمواقع ووردبريس؟
المطلوب من أغلب أصحاب المواقع بسيط لكنه عاجل: اعرف إصدار PHP عندك، واعرف من يحدثه، وتأكد أن التحديث سيتم يوم 21 أكتوبر.
الاستضافة المشتركة أو المدارة
لو موقعك على استضافة مشتركة أو استضافة ووردبريس مدارة، فشركة الاستضافة هي التي تتحكم في PHP. الشركات الجيدة تحدث بسرعة، وغالبا بحزم فيها الإصلاح منقولا للإصدارات القائمة. دورك أن تتأكد أن موقعك على فرع PHP مدعوم، وأن تسأل الاستضافة مباشرة: متى ستطبقون الإصلاح؟ ولو لوحة التحكم تسمح لك باختيار إصدار PHP، لا تبق على إصدار قديم.
سيرفر VPS أو سيرفر خاص
لو تدير سيرفرك بنفسك، فأنت الاستضافة. خطط لنافذة صيانة يوم 21 أكتوبر بعد الساعة 14:00 UTC. تابع إعلان PHP الرسمي لمعرفة أرقام الإصدارات المصلحة، وراجع تحديثات الأمان في توزيعة لينكس عندك، كما توصي Huntress. وابدأ بالسيرفرات المكشوفة على الإنترنت.
الوكالات والشركات التي تدير مواقع كثيرة
لو مسؤول عن مواقع عدة لعملاء، اعمل حصرا اليوم: كل موقع، واستضافته، وإصدار PHP، ومن عنده صلاحية التحديث. وتنصح Huntress أيضا بالبحث عن نسخ PHP غير الظاهرة، مثل برامج الموردين التي تأتي معها PHP، ولوحات التحكم مثل cPanel وPlesk.
كيف تعرف إصدار PHP على موقعك؟
توجد ثلاث طرق سهلة حسب الصلاحيات المتاحة لك. ولخطوات الترقية كاملة راجع دليلنا لتحديث PHP في ووردبريس.
- من داخل ووردبريس: ادخل على أدوات، ثم صحة الموقع، ثم تبويب المعلومات، وافتح قسم الخادم. ستجد إصدار PHP الذي يعمل عليه موقعك.
- من لوحة الاستضافة: أغلب اللوحات مثل cPanel وPlesk تعرض إصدار PHP لكل دومين، غالبا في صفحة اختيار إصدار PHP أو إعداداتها.
- من السيرفر مباشرة: لو عندك وصول SSH، شغل الأمر التالي. وانتبه أن PHP في سطر الأوامر قد تختلف عن PHP التي يستخدمها خادم الويب (php-fpm)، فراجع الاثنين لو عندك أكثر من إصدار.
php -vوللتوضيح، آخر التحديثات الأمنية المعلنة على php.net قبل هذا الإشعار كانت للفروع 8.2 و8.3 و8.4 و8.5. لو إصدارك يبدأ بـ 5 أو 7 أو 8.0 أو 8.1، فإن Huntress تحذر من أنك قد لا تحصل على إصلاح أصلا.
لماذا الإصدارات المنتهية الدعم هي الخطر الحقيقي؟
المقلق في التقارير الأولى ليس الخطورة وحدها، بل الإشارة إلى أن إصدارات PHP من 5 إلى 8 قد تكون متأثرة، بينما الإصلاح سيصل للفروع المدعومة فقط. لو تأكد ذلك، فكل موقع ما زال على إصدار منتهي الدعم سيبقى مكشوفا بثغرة خطيرة معروفة للجميع بلا تصحيح رسمي.
مواقع ووردبريس كثيرة ما زالت على PHP قديمة، إما لأن قالبا أو إضافة قديمة تتعطل مع الإصدارات الأحدث، أو ببساطة لأن أحدا لم يغير الإعداد الافتراضي وقت بناء الموقع. ونصيحة Huntress لهذه الحالات واضحة: حدث، أو افصل النظام عن الإنترنت، أو ضعه خلف VPN أو جدار حماية لتطبيقات الويب حتى تتمكن من التحديث. وبما أن الموقع العام لا يصح أن يتوقف غالبا، فالطريق الواقعي هو ترقية PHP وإصلاح ما يتعطل.
لو قلقان من مشاكل التوافق، جرب الترقية على نسخة تجريبية من الموقع أولا، وحدث الإضافات والقالب، وراجع سجل الأخطاء. وهذا بالضبط نوع الشغل الذي نقدمه في خدمة تطوير ووردبريس.
الإصدارات التي تحمل الإصلاح رسميا
أصدر فريق PHP الإصلاح يوم 21 أكتوبر 2026. وبحسب النشرة الأمنية على php.net هذه هي الإصدارات المصلحة، وكل إصدار أقدم منها في نفس الفرع متأثر:
- PHP 8.5.12 (يصلح كل إصدارات 8.5 السابقة له)
- PHP 8.4.27 (يصلح كل إصدارات 8.4 السابقة له)
- PHP 8.3.36 (يصلح كل إصدارات 8.3 السابقة له)
- PHP 8.2.35 (يصلح كل إصدارات 8.2 السابقة له). ويذكر فريق PHP أن دعم 8.2 ينتهي يوم 31 ديسمبر 2026.
- PHP 8.1 وما قبلها: لا يوجد إصدار رسمي لأن هذه الفروع لم تعد تحصل على تحديثات. نشر فريق PHP تصحيحات مصدرية مختصرة للإصدارات 7.4 و8.0 و8.1، ويمكنك سؤال توزيعة لينكس أو شركة الدعم الطويل عن حزم مصلحة، لكن الأضمن هو الانتقال إلى فرع مدعوم.
حلول مؤقتة جزئية وليست إصلاحا
بحسب Patchstack يشير التحليل الأولي إلى خاصية تتبع تقدم رفع الملفات في جلسات PHP وإلى طلبات رفع الملفات من نوع multipart. ويقترح بعض الباحثين الخطوات التالية لحين التحديث، لكن Patchstack توضح أنها تقلل الخطر ولا توقف الاستغلال، وأن مطوري PHP أكدوا أن الحل الكامل الوحيد هو الترقية للإصدار المصحح.
- أوقف تتبع تقدم الرفع وفعل الوضع الصارم للجلسات. أضف السطرين التاليين إلى php.ini أو .user.ini أو إعدادات PHP في لوحة الاستضافة، ثم أعد تشغيل PHP. شريط تقدم الرفع سيتوقف، لكن الرفع نفسه سيعمل عادي.
- امنع طلبات multipart في الأماكن التي لا تحتاجها. من جدار الحماية أو الـ reverse proxy ارفض أو افحص طلبات POST من نوع multipart على الصفحات التي لا تستقبل ملفات. جرب أولا، لأن تطبيقها بشكل واسع يعطل مكتبة الوسائط ونماذج التواصل التي فيها مرفقات وصفحات الدفع والحساب.
- قواعد Cloudflare تفيد في حالة واحدة فقط. نشرت Cloudflare قواعد للجدار الناري ضد طرق الاستغلال المعروفة لكل العملاء حتى الخطة المجانية، لكنها لا تفيد إلا لو كان السيرفر يقبل الزيارات من Cloudflare فقط.
- ابتعد عن إضافات الإصلاح غير الرسمية والأكواد المنسوخة. تحذر Patchstack من أنها غير موثقة وقد تعطل موقعك.
session.upload_progress.enabled = Off
session.use_strict_mode = 1مواقع تتوقف احتياطيا
بعض الجهات لم تنتظر الإصلاح. تقول Patchstack إن خدمات حكومية هولندية مثل DigiD وMijnOverheid، وموقع مجلس النواب الهولندي، وموقع Tweakers، وموقع المركز الوطني الهولندي للأمن السيبراني نفسه، توقفت احتياطيا. ويقدم المركز الوطني البريطاني للأمن السيبراني NCSC نصيحة مشابهة، كما توصي CERT-EU بالتفكير في عزل التطبيقات المكشوفة على الإنترنت إذا تعذر التحديث فورا. ولو موقعك عالي الخطورة ولا تقدر تحدثه بسرعة، فوضع الصيانة لحين صدور التحديث قرار منطقي.
ماذا تفعل الآن؟ قائمة مراجعة
- اعرف إصدار PHP في كل موقع تملكه، من صحة الموقع أو لوحة الاستضافة.
- تواصل مع الاستضافة واسأل متى ستطبق التحديث الأمني الصادر يوم 21 أكتوبر.
- خذ نسخة احتياطية كاملة من الملفات وقاعدة البيانات قبل أي ترقية.
- حدد موعد الترقية يوم 21 أكتوبر بعد 14:00 UTC (الخامسة مساء بتوقيت القاهرة)، وابدأ بالمواقع المكشوفة للعامة.
- انتقل من الإصدارات المنتهية الدعم (5.x و7.x و8.0 و8.1) إلى فرع مدعوم، بعد تجربة على نسخة تجريبية.
- حدث نواة ووردبريس والإضافات والقوالب لتكون جاهزة لإصدار PHP أحدث.
- تابع php.net لمعرفة القائمة الرسمية للإصدارات المتأثرة والمصلحة.
علامات تستحق الانتباه
تتوقع Huntress، بالاتفاق مع الباحث Florian Roth، أن يظهر الاستغلال في صورة عمليات مشبوهة تطلقها PHP. ببساطة، عملية PHP التي تخدم صفحات موقعك (php-fpm أو php-cgi أو Apache أو httpd) لا يجب أن تبدأ فجأة في تشغيل أوامر shell أو مفسرات برمجية أو أدوات تحميل. ومن الأمثلة التي تذكرها Huntress:
- تشغيل shell مثل sh أو bash أو cmd.exe أو powershell.exe من خادم الويب.
- تشغيل مفسرات مثل python أو perl من PHP.
- تشغيل أدوات تحميل أو شبكات مثل curl أو wget أو nc أو certutil.exe.
- أوامر استطلاع سريعة مثل whoami أو id أو uname تعمل مباشرة من خادم الويب.
أما صاحب موقع ووردبريس الذي لا يملك أدوات مراقبة للسيرفر، فالعلامات العملية هي التي يقدر يشوفها بنفسه: ملفات PHP جديدة مجهولة في مجلد الموقع أو مجلد الرفع، ومستخدمون بصلاحية مدير لم تضفهم، ومهام مجدولة جديدة، وتغييرات غير متوقعة في ملفات النواة. ولو وجدت شيئا، تنصح Huntress بعزل السيرفر، والاحتفاظ بسجلات خادم الويب وPHP، والبحث عن ملفات webshell والملفات الجديدة والمهام المجدولة والحسابات الجديدة.
لم تؤكد أي مؤشرات اختراق حتى الآن، وتقول Huntress إنها ستنشر قواعد الرصد بعد إتاحة التفاصيل التقنية.
الإيجابيات والسلبيات في طريقة التعامل مع الأزمة
هذا ليس إطلاق منتج، لكن الاستجابة لها نقاط قوة وضعف واضحة بالنسبة لأصحاب المواقع.
- إيجابي: أصدر فريق PHP إشعارا علنيا بسرعة، وحدد يوما وساعة واضحين، وقدم الموعد عن الإفصاح الأصلي.
- إيجابي: باحثون معروفون أكدوا المشكلة ونشروا إرشادات دفاعية دون كشف تفاصيل الاستغلال.
- سلبي: التسريب يعني أن المهاجمين يعرفون بوجود ثغرة خطيرة قبل التصحيح، وهذا يقصر المسافة بين الإصلاح والهجوم.
- سلبي: الإصدارات المتأثرة مجهولة حتى يوم الإصدار، فلازم تستعد دون صورة كاملة.
- سلبي: لو اقتصر الإصلاح على الفروع المدعومة، ستبقى المواقع على PHP القديمة بلا تصحيح رسمي.
مقارنة مع ثغرات إضافات ووردبريس
| النقطة | ثغرة إضافة ووردبريس المعتادة | php2shell |
|---|---|---|
| مكان الخلل | إضافة أو قالب واحد | PHP نفسها، تحت كل تطبيق على السيرفر |
| من يصدر الإصلاح؟ | مطور الإضافة | مشروع PHP، ثم الاستضافة أو توزيعة لينكس |
| طريقة التطبيق | تحديث من لوحة ووردبريس | ترقية PHP على مستوى السيرفر |
| هل تحلها إضافة الحماية؟ | أحيانا تمنع الهجوم | لا، لازم ترقية PHP نفسها |
| الإصدارات القديمة | غالبا تصلح في آخر إصدار للإضافة | الفروع المنتهية الدعم قد لا تحصل على إصلاح |
كيف تستفيد شركتك من هذا الأسبوع؟
اعتبر php2shell فرصة لترتيب إعدادات الاستضافة عندك. اكتب أين يستضاف كل موقع، وما إصدار PHP عليه، ومن عنده صلاحية الوصول للسيرفر، وما سرعة الاستضافة في تطبيق التحديثات الأمنية. الشركة التي تجيب عن هذه الأسئلة في خمس دقائق تقدر تحدث في نفس اليوم الذي يصدر فيه الإصلاح. ولو استضافتك لا تقدر تقول لك متى ستحدث، أو تبقيك على PHP قديمة، فهذه إشارة للانتقال.
لو مش متأكد تبدأ منين، احجز استشارة مجانية وسنساعدك في معرفة إصدار PHP، وتخطيط الترقية، وتجربة موقعك على فرع أحدث.
الأسئلة الشائعة
هل موقعي على ووردبريس معرض لثغرات php2shell؟
نعم، ما لم يكن يعمل بالفعل على PHP 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35. يقول فريق PHP إن كل الإصدارات الأقدم متأثرة في كل بيئة تخدم طلبات ويب. راجع إصدارك الآن وحدثه.
هل تحميني إضافة الحماية؟
ليس وحدها. الثغرات في PHP وليست في ووردبريس، فالإصلاح الحقيقي هو ترقية PHP على السيرفر. وجدار حماية تطبيقات الويب قد يقلل الخطر مؤقتا.
متى يصدر الإصلاح؟
صدر بالفعل. أطلق فريق PHP الإصدارات 8.5.12 و8.4.27 و8.3.36 و8.2.35 يوم 21 أكتوبر 2026.
موقعي على PHP 7.4، ماذا أفعل؟
خطط للانتقال إلى فرع PHP 8 مدعوم. تحذر Huntress من أن الإصدارات المنتهية الدعم مثل PHP 5 و7 و8.0 و8.1 قد لا تحصل على إصلاح. جرب على نسخة تجريبية قبل تغيير الموقع الفعلي.
هل تعرض أحد للهجوم بالفعل؟
نعم. تلقت Patchstack يوم 21 أكتوبر بلاغات عن استغلال فعلي من عدة شركات استضافة، وقال المدير التقني لـ Cloudflare إن الشركة ترصد هجمات مبكرة. اعتبر التحديث أمرا عاجلا.
هل سيحدث هذا المقال؟
تم التحديث. الإصدارات المتأثرة والمصلحة في هذا المقال مأخوذة الآن من النشرة الرسمية على php.net.
