21 أكتوبر 2026 | PHP | أمن المعلومات
في 21 أكتوبر 2026 نشر فريق أمان PHP تحديثات لـجميع إصدارات PHP التي لا تزال مدعومة. وهي تسدّ ثغرتين حرجتين اشتهرتا باسم PHP2Shell. وقد أصدر BSI تحذيرًا بشأنهما ويطالب بتحديث الأنظمة المتأثرة فورًا. ومن يشغّل خادم ويب بـ PHP ينبغي أن يتحرك اليوم نفسه. وينطبق ذلك أيضًا على كل من يشغّل «فقط» WordPress أو Nextcloud أو Joomla، لأن هذه التطبيقات تعمل على PHP.
يلخّص هذا المقال ما حدث، وأي إصدارات PHP متأثرة، وأي إصدار تحتاجه الآن، وكيف تفحص في دقائق ما إذا كان خادمك مؤمَّنًا.
ما الذي حدث؟ التسلسل الزمني
أعلن فريق أمان PHP عن نشر الإصلاحات مسبقًا، كي يتوفر لمزوّدي الاستضافة والمسؤولين وقت للاستعداد. أما النشر نفسه فقد جرى في 21 أكتوبر 2026. وأصدر BSI تحذيره (الإصدار 1.1) في اليوم نفسه.
- 20 أكتوبر 2026: إنذار مسبق من فريق أمان PHP بأن تحديثات أمنية ستصدر في اليوم التالي.
- 21 أكتوبر 2026، 14:00 UTC (الساعة 16:00 بتوقيت وسط أوروبا الصيفي MESZ): نشر التصحيحات لـ PHP 8.5 و8.4 و8.3 و8.2.
- 21 أكتوبر 2026: يحذّر BSI من «الثغرات الحرجة التي تهدد تطبيقات الويب في أنحاء العالم»، ويوصي بالتحديث فورًا. وبحسب BSI فقد أخرجت شركات استضافة كبرى بعض الخوادم من الخدمة احترازيًا.
نظرة عامة على ثغرتي PHP
يتعلق الأمر بخطأين منفصلين في نواة PHP: CVE-2026-109618 وCVE-2026-109619. وبحسب فريق أمان PHP يمكن لكل منهما أن يتيح للمهاجم تنفيذ شيفرة برمجية على الخادم دون تسجيل الدخول (unauthenticated Remote Code Execution). وقد قُيِّمت الثغرتان بدرجة CVSS v4.0: 9,2 (حرجة).
| الخاصية | المعنى |
|---|---|
| المعرّفات | CVE-2026-109618 وCVE-2026-109619 |
| التقييم | CVSS v4.0: 9,2 — حرجة |
| التأثير | تنفيذ شيفرة على الخادم (Remote Code Execution) دون تسجيل دخول |
| السبب 1 | ذاكرة تالفة عندما لا يحصل PHP أثناء المعالجة على ذاكرة عاملة كافية (Out-of-Memory) |
| السبب 2 | حالة عامة قديمة تبقى في الذاكرة بين الطلبات |
| الأكثر عرضة للخطر | Apache مع mod_php |
بحسب تقدير BSI لم تكن هناك وقت النشر هجمات مؤكدة، لكن كانت هناك إشارات غير مؤكدة إلى محاولات استغلال. وفي الثغرات الحرجة في برنامج واسع الانتشار كهذا، تُظهر التجربة أنه ينبغي توقع أن يحلل المهاجمون الإصلاحات ويعدّوا هجمات آلية. ولذلك فإن النافذة الزمنية للتحديث قصيرة.
من المتأثر؟
يتأثر من حيث المبدأ كل خادم يعمل عليه PHP، بصرف النظر عن كيفية ربط PHP: PHP-FPM أو mod_php في Apache أو php-cgi أو FrankenPHP أو LiteSpeed. وبحسب فريق أمان PHP فإن الخطر أعلى ما يكون مع Apache مع mod_php.
يذكر BSI صراحةً تطبيقات مبنية على PHP يمكن أن تتأثر تبعًا لذلك:
- أنظمة إدارة المحتوى: WordPress وDrupal وTYPO3 وJoomla
- أنظمة المتاجر: Magento
- التخزين السحابي وتخزين الملفات: Nextcloud
- واجهات جدران الحماية: pfSense وOPNsense
لا يلزم أن يكون التطبيق نفسه معيبًا لذلك. فالثغرة في PHP، ولهذا لا يكفي تحديث WordPress أو Nextcloud & Co. وحده. بل يجب تحديث إصدار PHP على الخادم. وفي جدران الحماية مثل pfSense وOPNsense يأتي إصدار PHP المصحَّح عبر تحديث البرنامج الثابت (Firmware) الخاص بالشركة المصنِّعة.
إصدارات PHP هذه آمنة
أُصلحت الثغرتان في الإصدارات التالية. وكل ما دونها يُعدّ عرضة للاختراق.
| فرع PHP | الحد الأدنى المطلوب | ملاحظة |
|---|---|---|
| PHP 8.5 | 8.5.12 | الفرع الحالي |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | ينتهي الدعم في 31 ديسمبر 2026 |
| PHP 8.1 وما قبله | لا تحديث رسمي، انظر أسفل | |
هكذا تفحص خادمك وتحدّثه
1. تحديد إصدار PHP المثبّت
في سطر أوامر الخادم يُظهر الأمر php -v إصدار PHP الخاص بسطر الأوامر. وقد يستخدم خادم الويب إصدار PHP مختلفًا. ولذلك افحص أيضًا إصدار PHP-FPM أو وحدة Apache، مثلًا بالأمر php-fpm8.3 -v أو عبر صفحة تعرض phpinfo() (ثم أزلها فورًا بعد ذلك).
2. تثبيت التحديث عبر إدارة الحزم
في Debian وUbuntu وRHEL وما يتصل بها يأتي الإصدار المصحَّح عبر إدارة الحزم المعتادة، مثلًا apt update && apt upgrade أو dnf upgrade. وفي المصادر الخارجية مثل Sury-PPA أو مستودع Remi تظهر الحزم الجديدة غالبًا في وقت قريب.
apt changelog php8.3-fpm أو rpm -q --changelog php | grep CVE-2026-1096).
3. إعادة تشغيل خدمة PHP
تحديث الحزمة وحده لا يكفي: عمليات PHP الجارية تحتفظ بالشيفرة القديمة في الذاكرة. أعد تشغيل PHP-FPM (systemctl restart php8.3-fpm) أو Apache (systemctl restart apache2)، ثم تحقق بعد ذلك مما إذا كانت العمليات قد بدأت بعد التحديث.
4. المواقع المستضافة
في الاستضافة المشتركة يتولى المزوّد التحديث في العادة. وفي قائمة العميل يمكن غالبًا ضبط إصدار PHP لكل موقع. اختر هناك أحد الإصدارات الآمنة المذكورة أعلاه، أو اسأل المزوّد عن حالة التصحيحات. وبحسب BSI فقد أخرج بعض المزوّدين خوادم من الشبكة احترازيًا. وإذا تعذّر الوصول إلى موقعك لفترة قصيرة فقد يكون هذا هو السبب.
PHP 8.1 وما قبله: لا تحديث رسمي
لإصدار PHP 8.1 وما قبله لم تعد هناك تحديثات أمنية رسمية. ولمشغّلي هذه الأنظمة خياران:
- الانتقال إلى إصدار مدعوم (موصى به). وكلما كان الإصدار أقدم زاد جهد تكييف التطبيق والإضافات، ولذلك ينبغي اختبار الانتقال قبل ذلك.
- نقل الإصلاحات إلى إصدارات أقدم (Backport). وقد أتاح فريق أمان PHP الإصلاحات في فروع التطوير على GitHub. ومن يُجمّع PHP بنفسه يمكنه نقل هذه التغييرات إلى إصدارات أقدم. وهذا حل انتقالي ويتطلب خبرة فنية.
كما أن PHP 8.2 مدعوم حتى 31 ديسمبر 2026 فقط. ولذلك خطّط للانتقال إلى PHP 8.4 أو 8.5 الآن، ولا تؤجله إلى مطلع العام.
إجراءات انتقالية وسؤال «هل نُخرج الخادم من الخدمة؟»
وقد وصف فريق أمان PHP مع الإعلان أيضًا إجراءات حماية مؤقتة. وهي تخفف الخطر لكنها لا تسدّ الثغرات بالكامل. فهي لا تحل محل التحديث، وهي مخصصة فقط لسد الفترة حتى التحديث.
وهل ينبغي إخراج الخادم من الشبكة إلى حين التحديث فذلك يتوقف على أهميته وعلى إمكانية الوصول إليه. ويذكر BSI أن مزوّدين كبارًا اتخذوا هذه الخطوة. وكقاعدة عامة:
- خادم متاح للعموم، والتحديث ممكن الآن: حدّث فورًا، ولا حاجة إلى الإيقاف.
- خادم متاح للعموم، والتحديث غير ممكن في وقت قريب: قيّد الوصول (مثلًا عبر جدار الحماية لعناوين معروفة فقط) أو أوقف الخدمة مؤقتًا، ولا سيما مع
mod_php. - خادم متاح داخليًا فقط: حدّث في وقت قريب، فالاستعجال أقل.
الأسئلة الشائعة
هل يجب عليّ تحديث WordPress أو Joomla أو Nextcloud؟
ليس بسبب هذه الثغرة. فهي موجودة في PHP وليست في التطبيق. قوموا بتحديث إصدار PHP على الخادم. ومع ذلك يبقى تحديث التطبيق مفيداً بصورة مستقلة عن ذلك.
كيف أعرف ما إذا كان أحدهم قد استغل الثغرة بالفعل؟
من الصعب الجزم بذلك. ومن العلامات اللافتة وجود ملفات PHP غير معروفة في مجلد الويب، وعمليات غير معتادة تعمل تحت مستخدم خادم الويب، وحسابات مستخدمين أو مهام Cron جديدة، وحركة بيانات صادرة غير معتادة. وعند وجود اشتباه محدد ينبغي فحص النظام جنائياً رقمياً، وإعادة بنائه من جديد عند الشك.
هل يكفي جدار حماية تطبيقات الويب (Web Application Firewall)؟
يمكن لجدار الحماية أن يعترض أنماط الهجوم المعروفة، لكنه ليس بديلاً عن التحديث. يمكنكم الاطلاع على المزيد حول تكامل عدة طبقات حماية في مقالنا تأمين Odoo 19: جدار الحماية والمصادقة الثنائية 2FA & Web RBL. وتنطبق هذه المبادئ على كل تطبيق ويب.
هل يتأثر Odoo؟
لا. فـ Odoo مكتوب بلغة Python ولا يعمل على PHP. والمتأثر فقط هو تطبيقات PHP التي تعمل على الخادم نفسه.
أين أجد المعلومات الرسمية؟
تجدون إعلان فريق الأمان في PHP في أرشيف الأخبار على php.net (مدخل بتاريخ 20 أكتوبر 2026)، وتجدون الإصدارات في php.net/downloads. ويحمل تحذير BSI الرقم 2026-297981-1032 وقد نُشر على bsi.bund.de .
الدعم من Biricon IT Services
إذا لم تكونوا متأكدين من إصدار PHP الذي يعمل على خادمكم، أو احتجتم إلى مساعدة في تطبيق التحديثات، فيسعدنا دعمكم: في جرد جميع أنظمة PHP، وفي تثبيت التحديثات، وفي الانتقال إلى إصدار PHP مدعوم، وفي الفحص بحثاً عن اختراق. وبصفتنا مزوّد خدمات تقنية المعلومات، نتولى رعاية الخوادم وجدران الحماية وتطبيقات الويب للشركات الصغيرة والمتوسطة.
الحالة بتاريخ: 21 أكتوبر 2026. قد يتغير الوضع في وقت قصير؛ والمرجع هو ما ينشره فريق الأمان في PHP و BSI.