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 بتوقيت وسط أوروبا الصيفي): إصدار تصحيحات PHP 8.5 و8.4 و8.3 و8.2.
- 21 أكتوبر 2026: يحذّر BSI من «ثغرات حرجة تهدّد تطبيقات الويب في جميع أنحاء العالم»، ويوصي بتثبيت التصحيحات فورًا. ووفقًا للمكتب، فصل بعض كبار مزوّدي الاستضافة خوادم عن الشبكة احترازيًا.
نظرة عامة على ثغرتَي PHP
يتعلق الأمر بخللين منفصلين في نواة PHP: CVE-2026-109618 وCVE-2026-109619. ووفقًا لفريق أمان PHP، قد يتيح كلاهما للمهاجم تنفيذ شيفرة برمجية على الخادم دون تسجيل الدخول (تنفيذ شيفرة برمجية عن بُعد دون مصادقة). وقد حصلت الثغرتان على تقييم CVSS v4.0: 9,2 (حرج).
| الخاصية | المعنى |
|---|---|
| المعرّفات | CVE-2026-109618 وCVE-2026-109619 |
| التقييم | CVSS v4.0: 9,2 — حرج |
| الأثر | تنفيذ شيفرة برمجية على الخادم عن بُعد، دون تسجيل الدخول |
| السبب الأول | فساد الذاكرة عند تعذّر تخصيص مزيد من ذاكرة الوصول العشوائي لـ PHP أثناء المعالجة (نفاد الذاكرة) |
| السبب الثاني | بقاء حالة عامة قديمة في الذاكرة بين الطلبات |
| الأكثر عرضة للخطر | Apache مع mod_php |
بحسب تقدير BSI لم تكن هناك وقت النشر هجمات مؤكدة، لكن كانت هناك إشارات غير مؤكدة إلى محاولات استغلال. وفي الثغرات الحرجة في برنامج واسع الانتشار كهذا، تُظهر التجربة أنه ينبغي توقع أن يحلل المهاجمون الإصلاحات ويعدّوا هجمات آلية. ولذلك فإن النافذة الزمنية للتحديث قصيرة.
من المتأثر؟
من حيث المبدأ، يتأثر كل خادم يشغّل 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 & غيرهما وحده. يجب تحديث إصدار PHP على الخادم. أما في جدران الحماية مثل pfSense وOPNsense، فيصل إصدار PHP المصحّح ضمن تحديث البرنامج الثابت الذي تصدره الشركة المصنّعة.
إصدارات 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-Repository، تتوفر الحزم الجديدة عادةً خلال وقت قصير.
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 والإصدارات الأقدم. وأمام مشغّلي هذه الأنظمة خياران:
- الانتقال إلى إصدار مدعوم (موصى به). كلما كان الإصدار أقدم، زاد العمل اللازم لتكييف التطبيق والإضافات، لذا ينبغي اختبار الانتقال مسبقًا.
- نقل الإصلاحات إلى الإصدارات الأقدم. أتاح فريق أمان PHP الإصلاحات في فروع التطوير على GitHub. ويمكن لمن يبني PHP من الشيفرة المصدرية إدماج هذه التغييرات في الإصدارات الأقدم. وهذا حل مؤقت يتطلب خبرة متخصصة.
كما أن دعم PHP 8.2 سيستمر حتى 31 ديسمبر 2026 فقط. لذا خطّط الآن للانتقال إلى PHP 8.4 أو 8.5، ولا تؤجله إلى نهاية العام.
التدابير المؤقتة وسؤال «هل ينبغي فصل الخادم عن الشبكة؟»
ضمّن فريق أمان PHP إعلانه وصفًا لتدابير حماية مؤقتة. وهي تخفّف المخاطر، لكنها لا تعالج الثغرات بالكامل. ولا تغني عن التحديث، وإنما تهدف فقط إلى توفير حماية مؤقتة إلى حين تثبيته.
يعتمد قرار فصل الخادم عن الشبكة حتى تثبيت التحديث على أهميته ومدى إمكانية الوصول إليه. ويذكر BSI أن مزوّدين كبارًا اتخذوا هذه الخطوة. وكقاعدة عامة:
- خادم متاح للعامة ويمكن تحديثه الآن: ثبّت التصحيحات فورًا، ولا حاجة إلى إيقافه.
- خادم متاح للعامة ويتعذّر تحديثه قريبًا: قيّد الوصول إليه (مثلًا بالسماح للعناوين المعروفة فقط عبر جدار الحماية) أو أوقف الخدمة مؤقتًا، لا سيما عند استخدام
mod_php. - خادم لا يمكن الوصول إليه إلا داخليًا: ثبّت التصحيحات قريبًا، فدرجة الاستعجال أقل.
الأسئلة الشائعة
هل يجب عليّ تحديث WordPress أو Joomla أو Nextcloud؟
ليس بسبب هذه الثغرة، فهي موجودة في PHP وليست في التطبيق. حدّث إصدار PHP على الخادم. ومع ذلك، يبقى تحديث التطبيق مفيدًا بصورة مستقلة عن هذه الثغرة.
كيف أعرف ما إذا كان أحد قد استغل الثغرة بالفعل؟
يصعب الجزم بذلك. ومن العلامات المثيرة للريبة وجود ملفات PHP غير معروفة في مجلد الويب، أو عمليات غير معتادة تعمل بحساب مستخدم خادم الويب، أو حسابات مستخدمين أو مهام Cron جديدة، أو حركة بيانات صادرة غير معتادة. وعند وجود اشتباه محدد، ينبغي إخضاع النظام لفحص جنائي رقمي، وإعادة تثبيته من الصفر إذا تعذّر التأكد من سلامته.
هل يكفي جدار حماية تطبيقات الويب؟
يمكن لجدار الحماية اعتراض أنماط الهجوم المعروفة، لكنه لا يغني عن التحديث. تعرّف على كيفية تكامل طبقات الحماية المتعددة في مقالنا تأمين Odoo 19: جدار الحماية والمصادقة الثنائية & 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 بوصفها المصادر المعتمدة.