تحديث أمني لـ PHP عام 2026: دليل إصلاح ثغرة PHP2Shell بتصنيف CVSS 9.2

كان الإفصاح نفسه حدثًا غير معتاد. ففي 20 أكتوبر نشر فريق أمن PHP إشعارًا مسبقًا، وحدَّد موعد الإصدار في 21 أكتوبر الساعة 14:00 بتوقيت UTC، محتفظًا بحق الإصدار في وقت أبكر. وقد تسرَّبت معرِّفات CVE قبل يوم كامل من الإفصاح، مصحوبةً بمزاعم مبالغ فيها بشأن الخطورة والإصدارات المتأثرة. كانت مزوِّدو التوزيعات قد استلموا الرقع الخاصة بتوزيعاتهم مسبقًا، وبدأت مراكز CERT الوطنية تنشر إرشاداتها قبل أن تصبح الشيفرة علنية أصلًا. بعبارة أخرى: لم يعد لأحد عذر مشروع للتأخر لحظة صدور الإصدار.

ثغرتان وإصدار طارئ واحد

ليست أيٌّ من الثغرتين خطأً منطقيًا في تطبيق ما؛ فكلتاهما تكمنان في طريقة PHP تجهيز الطلب وإنهاءه، ولهذا لا يغني تحديث إطار العمل أو تحديث الإضافات أو قاعدة WAF عن ترقية المفسِّر نفسه.

CVE-2026-109618 — تنفيذ الشيفرة عن بُعد عبر تلف ناتج عن نفاد الذاكرة. حين تنفد ذاكرة PHP فإنها تُجهض الطلب بدلًا من متابعته. تصف النشرة مسارًا يقطع فيه هذا الإجهاض عمل PHP بينما بيانات الطلب الداخلية مهيَّأة جزئيًا فقط، فيتعامل خطوة تنظيف الطلب لاحقًا مع بيانات غير صالحة بوصفها صالحة. ومن يستطيع دفع استخدام الذاكرة إلى حدِّه يستطيع بالتالي توجيه ما يحدث بعده. وهذه هي الثغرة التي تجعل إرشاد التخفيف مضادًا للحدس إلى هذا الحد: يطلب مزوِّد البرمجيات من المسؤولين منع PHP من بلوغ سقف ذاكرتها الخاص، لا تشديد ذلك السقف.

CVE-2026-109619 — تنفيذ الشيفرة عن بُعد عبر حالة عامة قديمة. قد تبقى حالة داخلية يملكها طلبٌ ما بعد تحرير الذاكرة الكامنة خلفها، فيستهلك الطلب التالي الذي تعالجه عمليةُ العامل (worker) نفسُها تلك الحالة القديمة قبل أن تُعيد التهيئة الطبيعية ضبطها. وفي العمليات العاملة طويلة العمر — وهي بالضبط طبيعة كل من PHP-FPM وmod_php وLiteSpeed — تُعدّ إعادة استخدام الذاكرة وضعًا اعتياديًا دائمًا، ولهذا ليست هذه حالة هامشية تخص إعدادات نادرة.

اسم PHP2Shell ليس تسمية رسمية صادرة عن مشروع PHP؛ فقد أطلقه الباحثون وبائعو حلول الأمن وثبُت في الاستخدام، لذلك ستراه في مخرجات أدوات الفحص ونشرات الاستضافة وتحذيرات CERT، وهو يشير تحديدًا إلى هذين المعرِّفين.

من هو المعرَّض للخطر فعلًا

النشرة صريحة: كل تثبيتات PHP التي تخدم طلبات ويب معرضة للخطر، بما في ذلك PHP-FPM خلف nginx أو Apache، وApache مع mod_php، وphp-cgi، وLiteSpeed، وFrankenPHP. والفرق بينها هو حجم الجهد المطلوب من المهاجم.

إذا كنت تستضيف WordPress أو WooCommerce أو Laravel أو Magento أو أنظمة ERP المشابهة لـ Magento أو أي بوابة حجز تعمل بـ PHP لأعمالك التجارية، فأنت داخل الصفوف الثلاثة الأولى حتى لو كانت شيفرة تطبيقك مثالية. ولنظرة أوسع على الجهة التي ينبغي أن تمتلك بيئة التشغيل من الأساس، اطّلع على دليلنا عن التعاقد الخارجي على خدمات تقنية المعلومات في تركيا.

تحقَّق من إصدارك خلال دقيقتين

المصيدة هنا هي حساب الإصدارات. تشحن التوزيعات PHP 8.3.6 أو 8.2.x لسنوات وتُدمج الإصلاحات الأمنية في رقم الإصدار الظاهر نفسه، لذلك لا يخبرك php -v وحده إن كنت محميًا. قارن بين ثلاثة أمور.

1. إصدار PHP الظاهر، وواجهة SAPI التي تخدم حركة المرور.

2. إصدار حزمة التوزيعة، لا الإصدار الأصلي من المنبع (upstream). في Debian وUbuntu يكون سجل التغييرات هو الجواب الصادق؛ وفي أنظمة RPM استعلم عن سجل تغييرات الحزمة.

إذا ذكر سجل التغييرات الثغرتين معًا في الإصدار المثبَّت، فأنت محمي حتى لو ظل php -v يعرض 8.3.6. هذا هو الفرق بين جواب أمني حقيقي ووهم أرقام الإصدارات.

3. هل أعادت العملية الجارية تحميل الملف الثنائي المرقَّع. تحديث الحزمة الذي لا تتبعه إعادة تشغيل يترك الشيفرة القديمة في الذاكرة. قارن وقت بدء الخدمة بوقت تثبيت الحزمة:

على cPanel أو Plesk أو DirectAdmin أو أي منصة مُدارة، المقابل هو منتقي PHP مع نشرة الأمن الخاصة بمزوِّد الاستضافة نفسه: حدِّد الإصدار المدمج المسنَد إلى موقعك فعلًا، لا الأحدث المعروض في اللوحة. وإذا عجز مزوِّد الاستضافة عن ذكر تاريخ للرقعة، فاعتبر الموقع غير مرقَّع. تغطي خدماتنا للبنية التحتية الرقمية هذا التدقيق والترقية نفسها؛ ويمكنك أيضًا ببساطة التواصل معنا بتفاصيل حزمتك التقنية وسنخبرك بما كنا سنتحقق منه نحن.

الإصدارات المُصلِحة وحافة نهاية الدعم

يدعم مشروع PHP كل فرع مدَّة سنتين من التطوير النشط وسنتين إضافيتين من الإصلاحات الأمنية. هذه السياسة هي ما أنتج أربعة إصلاحات متزامنة في 21 أكتوبر — وهي أيضًا ما يترك الفروع الأقدم وحدها.

تحذيران عمليان من النشرة. أولًا، إذا كنت تثبِّت PHP من مستودع مجتمعي بدلًا من توزيعتك، فقد يتأخر هذا المستودع عن نافذة الأمان: فقد صرَّح المشرفون على حزم Remi الشائعة أنه لن تتوفر لديهم تحديثات في اليوم نفسه، لذلك فالمسار الآمن هو حزم توزيعتك أو البناء من المصدر. ثانيًا، إذا كنت على PHP 8.1 أو أقدم، فإن «انتظار مزوِّد الاستضافة» قرار أمني تتخذه نيابةً عن عملائك — فوَّثه أو غيِّره.

رقِّع خادمًا إنتاجيًا دون وقوع حادثة

قلَّما تعطِّل التحديثات الأمنية داخل الفرع الثانوي نفسه تطبيقًا؛ الذي يعطِّلها هو عمليات إعادة التشغيل غير المختبرة. الترتيب أدناه هو ما نستخدمه على منصات تجارية حيَّة، وهو يُبقي نافذة الخطر قصيرة دون المقامرة بالموقع.

1. ابدأ بلقطة للنظام. لقطة من hypervisor أو من وحدة تخزين اختبرتَ استعادتها فعلًا تعيد الأمور إلى طبيعتها خلال دقائق، وتجعل قرار الترقيع منخفض الكلفة.
2. أعد إنتاج الإصدار في بيئة الاختبار. الفرع نفسه، والامتدادات نفسها، وملفات تهيئة PHP نفسها، ونسخة من بيانات الإنتاج. اختبر مسارات إتمام الشراء وطلب عرض السعر والدفع، لا الصفحة الرئيسة وحدها.
3. ارتقِ بمجموعة الحزم بوصفها وحدة واحدة. الخلط بين واجهة سطر أوامر مرقَّعة وملف FPM ثنائي قديم هو ما يقع فيه الناس فينتهون إلى php -v مرقَّع ومسار ويب غير مرقَّع: apt-get update && apt-get install --only-upgrade 'php8.3-*'، أو dnf update --security 'php*' على خوادم RPM.
4. أعد تشغيل العملية الخادمة للطلبات، ثم تحقق أنها أُعيد تشغيلها فعلًا. systemctl restart php8.3-fpm (أو أعد تحميل Apache / أعد تشغيل LiteSpeed)، ثم تحقق مجددًا من وقت بدء الخدمة وأعد تنفيذ استعلامي الإصدار وسجل التغييرات.
5. راقب سجل الأخطاء مدة ساعة. رسائل OOM، وبصمات الأخطاء الفادحة الجديدة، ومعدلات 5xx غير المعتادة، هي إشارات إلى أن إعدادات التخفيف أدناه قد تحتاج ضبطًا — وليست أسبابًا لتأجيل الترقية.
6. وثِّق الدليل. إصدار الحزمة، وسطر سجل التغييرات الذي يذكر الثغرتين، وطابع الوقت لإعادة التشغيل. العملاء والمدققون ومراجعات الضوابط على نمط ISO 27001 يطلبون هذا تحديدًا، وحفظه لا يكلف سوى عشر ثوانٍ.

وحيثما وجب انتظار الترقية — تكامل ERP معتمد مسبقًا، أو تقويم إصدارات مقيَّد بحظر النشر، أو دورة موافقة لدى عميل — ضع ضابطًا تعويضيًا أمامها في اليوم نفسه بدل ترك المنفذ مفتوحًا على الأمل. وهذا ما أوصى به تحذير مراكز CERT الوطنية لهذا الموقف تحديدًا: عزل تطبيقات PHP المواجهة للإنترنت عن الشبكة العامة حين يتعذر الترقيع الفوري.

تدابير التخفيف المؤقتة: ضيِّق النافذة ولا تغلقها

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

ضد CVE-2026-109618 (مسار نفاد الذاكرة)

• اترك PHP تستهلك ذاكرة الجهاز بدلًا من أن تتوقف عند حدِّها الخاص: memory_limit = -1، ويُفضَّل بصيغة php_admin_value memory_limit = -1 حتى لا تستطيع شيفرة التطبيق إعادة السقف.
• أبقِ متون الطلبات صغيرة عند المفسِّر: إرشاد النشرة هو نحو 8 MB حين لا توجد ملفات مرفوعة، ونحو 32 MB حين توجد، على أن يكون upload_max_filesize أدنى من post_max_size.
• فرض الحدود الأكثر كلفةً عند الوكيل (proxy)، لأن الضرر يقع في الطلب بعد فك ترميزه لا في حجمه على الشبكة: الحجم الإجمالي للمتن بعد فك الترميز، وعدد حقول الإدخال، وعدد أجزاء multipart، وعدد الترويسات، وعمق التعشيش — مع تغطية الطلبات التي تصل من دون Content-Length صالح للاستخدام.
• احصر دائرة الضرر بحدِّ ذاكرة من حاوية (container) أو cgroup مضبوط الحجم بحيث يكون إنهاء عملية عاملة حدثًا يخصّ التوافر لا الخادم بأكمله. ولا تستعوض عنه بـ RLIMIT_AS أو RLIMIT_DATA: فهذان الخياران يُطلقان فشل التخصيص نفسَه الكائن في المسار المعرَّض للثغرة.

ضد CVE-2026-109619 (مسار الحالة القديمة)

• عطِّل ميزة تتبع تقدُّم الرفع في الجلسات عبر session.upload_progress.enabled = 0، مضبوطًا في php.ini أو في مجمَّع FPM أو في تهيئة الخادم — أي في موضع يُطبَّق قبل تحليل الطلب. ثم أعد تشغيل كل عملية عاملة، لأن FPM تشارك حالة الوحدات المهيَّأة سلفًا بين الطلبات. أما ini_set() و.user.ini فيأتيان متأخرين عن أن ينفعا.
• على PHP 8.5، اضبط fatal_error_backtraces = 0 وأعد التشغيل.
• احذف الإعدادات الفردية لكل طلب غير الصالحة أو المتقادمة، والتي تُصدر لذلك تشخيصات أثناء التهيئة المبكرة. فكتمُ الرسالة عبر error_reporting أو display_errors أو @ لا يحذف مسار الشيفرة نفسه.
• تعقَّب الأخطاء الفادحة التي يستطيع المهاجم بلوغها والمهلات طويلة الأمد في معالجات الرفع والاستيراد، وفي شيفرة الاستدعاءات الرجعية (callbacks)، وفي إجراءات التنظيف — فهي الأماكن ذاتها التي تسكنها الثغرتان.

لا تزال CDN أو WAF أمام الخادم الأصلي تؤدي دورها بجدارة: تقييد المعدل، وحجب أشكال الطلبات الشاذة، والرقع الافتراضية تخفض الضجيج وتبطئ المسح الانتهازي. لكنها في وجه مهاجم موجَّه لمجرد مطبّ يبطئه، وليست إجراءً يمكنك إقفال ملف المعالجة عليه.

أسئلة يجب أن توجهها إلى مزوِّد الاستضافة اليوم

تجيب ردود الدعم الجاهزة عن هذا السؤال بعبارة «نحن محدَّثون دائمًا». اطلب بدلًا من ذلك دليلًا يمكنك أرشفته:

• إصدار PHP المدمج المسنَد إلى حسابنا نحن، وهل هو حزمة من التوزيعة أم بناء من مزوِّد خارجي
• تاريخ وصول إصلاحَي CVE-2026-109618 وCVE-2026-109619 إلى أسطولكم من الخوادم، مع سلسلة نص إصدار الحزمة الداخلية
• هل ينسحب الإصلاح على واجهة SAPI التي تخدم موقعنا (FPM أو LiteSpeed أو mod_php) وعلى أي عقدة staging أو نسخة احتياطية قد نستعيدها
• إن لم تكن المنصة قد رُقِّعت بعد: ما الضابط التعويضي القائم، وإلى متى
• سياستكم الثابتة تجاه الفروع منتهية الدعم — ماذا يحدث لموقعي في 1 يناير 2027 حين يتوقف الدعم الأمني لـ PHP 8.2

المزوِّد الذي يجيب عن هذه الأسئلة الخمسة في رسالة بريد واحدة هو مزوِّد يستحق البقاء معه. أما الذي يعود إليك بمحتوى تسويقي فذلك حديث ترحيل؛ والاجتهاد نفسه المطلوب هنا هو المطبَّق في أعمال تقييم فجوات ISO 27001 التي ننفذها، حيث يكون التسليم دليلًا موثقًا لا طمأنة.

هل يجب أن تفترض وقوع اختراق؟

ليس تلقائيًا — لكن تحقق بدل أن تخمِّن، خصوصًا إذا كان الخادم مكشوفًا على الإنترنت العام خلال النافذة السابقة لترقيعك.

• ابحث عن عمليات ومنافذ استماع (listeners) وإدخالات cron لم تُنشئها أنت، وعن اتصالات صادرة من مستخدم عامل PHP.
• قارن أدلة التطبيق القابلة للكتابة بمصدر النشر المرجعي: ملفات PHP جديدة، أو أدلة رفع عُدِّلت، أو مجلدات مؤقتة صارت قابلة للتنفيذ على نحو غير متوقع.
• ابحث في سجلات الويب عن عواصف طلبات في ساعات الإفصاح تقريبًا، أو متون multipart ضخمة على نحو غير معتاد، أو طلبات أُعيد عليها الخطأ 500 مع بصمات OOM في سجل أخطاء PHP.
• تحقق من أن الملف الثنائي المرقَّع هو الذي يعمل فعلًا — فمقارنة وقت إعادة التشغيل أعلاه تجيب عن ذلك.
• إذا بدا أي شيء غير سليم فتعامل معه بوصفه حادثة أمنية: احفظ القرص والسجلات، وبدِّل كل بيانات اعتماد يستطيع التطبيق قراءتها، وأعد البناء من صورة سليمة معروفة. فإعادة تثبيت حزمة PHP فوق خادم مخترق ليست معالجة.

مثال تطبيقي من بنيتنا التحتية

نُشغِّل worldwidetradex.com على Ubuntu 24.04 LTS مع nginx وPHP-FPM، لذا طبَّقنا الفحوص أعلاه على أنفسنا يوم 22 أكتوبر. والنتائج توضيح جيد لسبب أهمية حساب الإصدارات:

والدرس ينتقل إلى أي حزمة تقنية: وضعك الأمني هو إصدار الحزمة زائد سطر سجل التغييرات زائد إعادة التشغيل، وليس سلسلة الإصدار التسويقية في لوحة الاستضافة.

اجعل الترقيع روتينًا لا بطولة

لم يبقَ اسم PHP2Shell في الذاكرة لأنه غريب، بل لأن المفسِّر الذي يعمل عليه معظم الويب حمل ثغرة حرجة تسبق المصادقة، فاضطرت آلاف الاستضافات إلى الاستجابة خلال ساعات. والفرق التي نامت خلال الأزمة لم تكن محظوظة — بل كانت تمتلك الأتمتة.

• ترقيات أمنية تلقائية للمفسِّر دون تدخل يدوي، مع تسجيل الإصدار ووقت إعادة التشغيل آليًا.
• جردٌ يعرف أي واجهة SAPI وأي فرع PHP يستخدمه كل موقع، شاملًا بيئات الاختبار والنسخ الاحتياطية وذاك الموقع WordPress العائد إلى عام 2019.
• مسار استعادة مُجرَّب سلفًا، حتى لا تُوازن أبدًا بين «رقِّع الآن» و«لا نستطيع التراجع».
• خطة فروع: لا شيء يعمل على إصدار PHP ينتهي دعمه الأمني خلال الأشهر الاثني عشر المقبلة.
• مسؤول واحد باسم معلوم لكل خادم، ومسار تصعيد مكتوب للأيام التي تصل فيها الرقعة الساعة 14:00 بتوقيت UTC يوم أربعاء.

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

الأسئلة الشائعة

المصادر

• PHP — النشرة الأمنية «ثغرات حرجة لتنفيذ الشيفرة عن بُعد، حدِّثوا الآن» وإعلانات الإصدار بتاريخ 21 أكتوبر 2026، بما فيها إرشادات التخفيف وجدول الدعم في صفحة الإصدارات المدعومة.
• نشرات GitHub Security Advisories الخاصة بمستودع PHP: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) وGHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — النشرة الأمنية 2026-018 بعنوان «ثغرات حرجة في PHP»، وتذكر المعرِّفين معًا.
• Infosecurity Magazine — «ثغرات PHP الحرجة تسرَّبت قبل رقع الأمان المجدولة» (21 أكتوبر 2026) و«رصدت Amazon محاولة استغلال PHP2Shell قبل أربعة أيام من الإفصاح عن الثغرة» (22 أكتوبر 2026).

تريد من يتولى الترقية نيابةً عنك؟ لمناقشة الترقيع، أو تدقيق الإصدارات، أو الانتقال إلى منصة PHP مُدارة ومرقَّعة، أو البنية التحتية المحيطة بذلك كله، تواصل معنا أو اتصل على +90 505 679 78 03.