معظم مواقع الشركات في الإمارات تعمل بلغة PHP سواء عرف المالك ذلك أم لا: WordPress وWooCommerce وLaravel وMagento وJoomla ومعظم لوحات تحكّم الاستضافة تعتمد عليها. في 21 أكتوبر 2026 أصدر مشروع PHP تحديثاً أمنياً طارئاً لثغرتين حرجتين تتيحان للمهاجم تنفيذ أوامر على خادم الويب من دون تسجيل دخول. وعالم الاستضافة ما زال يلحق بالخبر: حزم التوزيعات ولوحات التحكّم تصل بسرعات متفاوتة، ومحاولات الاستغلال أُبلغ عنها فعلاً. يشرح هذا المقال ما الثغرتان، وأي الخوادم أكثر تعرّضاً، وما على شركة في الإمارات فعله اليوم، بلغة واضحة ومن دون تفاصيل استغلال.
الإجابة المختصرة
إصدارات PHP 8.5.12 و8.4.27 و8.3.36 و8.2.35 الصادرة في 21 أكتوبر 2026 تصلح ثغرتين حرجتين، CVE-2026-109618 وCVE-2026-109619، وكلتاهما بدرجة CVSS v4.0 تساوي 9.2. كلتاهما قد تتيح تنفيذ أوامر عن بُعد بلا مصادقة، وفريق PHP يصرّح بأنه لا توجد تخفيفات كاملة سوى التحديث. كل تثبيت PHP يخدم طلبات الويب معرّض للخطر، وApache مع mod_php هو الأعلى خطراً. PHP 8.1 وما قبله خارج الدعم ويحتاج ترقيعاً من المورّد أو ترحيلاً. إن كنت على استضافتنا المشتركة فنحن نتولّى الأمر. وإن كنت تدير VPS أو خادماً مخصّصاً بنفسك، فرقّعه اليوم أو اطلب منّا ذلك.
ما الثغرتان
CVE-2026-109618، «تنفيذ أوامر عبر تلف ذاكرة عند نفادها» (GHSA-w8hw-w9fx-j79w). حين تنفد ذاكرة PHP، تُلغي الطلب الحالي بالقفز فوراً خارج ما كانت تفعله. في بعض الحالات يقع هذا القفز بينما الذاكرة الداخلية للطلب غير مكتملة التهيئة. ثم تشغّل PHP تنظيفها المعتاد على تلك الحالة نصف المبنية، ويمكن توجيه هذا التنظيف نحو تنفيذ أوامر. المحفّز العملي طلب رفع من نوع multipart مصمّم بعناية يدفع PHP إلى حدّ ذاكرتها مع بقائه ضمن post_max_size المعتاد. على Apache مع mod_php يحدث ذلك قبل تشغيل أي شيفرة تطبيق، فلا تحميك أي إضافة أو قالب أو إطار عمل. تؤكّد النشرة تنفيذ أوامر كاملاً بلا مصادقة على mod_php بالحدود الافتراضية؛ وPHP-FPM قابل للإصابة بتحليل الشيفرة المصدرية، وFrankenPHP وLSAPI الخاص بـLiteSpeed مرجّح تأثّرهما.
CVE-2026-109619، «تنفيذ أوامر عبر حالة عامة بائتة» (GHSA-6wmf-4rv5-p3rp). عملية PHP العاملة تخدم طلبات كثيرة متتالية. بعض الحالة الداخلية التابعة لطلب واحد (تفاصيل الأخطاء، بيانات تقدّم رفع الجلسة، حالة الامتدادات) يُفترض أن تُصفَّر قبل تحرير ذاكرة ذلك الطلب. فإذا قُطع الطلب بخطأ فادح أو انتهاء مهلة أو نفاد ذاكرة، تُتخطّى عملية التصفير. ويمكن للطلب التالي على العامل نفسه أن يلمس تلك الذاكرة المحرَّرة قبل أن تستبدلها التهيئة الطبيعية، وهو ما يُعرف بـ«الاستخدام بعد التحرير». «مستهلكان» مبكّران مؤكّدان: تحذيرات الإعدادات التي تُرفع قبل بدء الطلب (مثل أسطر php_value في .htaccess على mod_php)، وميزة تقدّم رفع الجلسة المفعّلة افتراضياً. تنفيذ الأوامر مؤكّد على mod_php (عبر تتبّع الأخطاء الفادحة في PHP 8.5) وعلى PHP-FPM (عبر تقدّم رفع الجلسة).
ما يجمع بينهما. كلتاهما ثغرة في نواة PHP لا في أي تطبيق، وكلتاهما تصيبان كل إصدار أدنى من 8.2.35 و8.3.36 و8.4.27 و8.5.12. ويسجّل سجلّ التغييرات إصلاحاً واحداً في النواة لكلتيهما بعنوان «تجنّب تلف الحالة عبر الإنقاذ». وتصرّح النشرتان بأن إخفاء الأخطاء عبر error_reporting أو display_errors أو العامل @ لا يفيد، لأن الحالة الخطرة تُلمس قبل أن تقرّر PHP عرض الخطأ من عدمه.
من المعرّض
نشرة PHP نفسها تعدّ كل التثبيتات التي تخدم طلبات الويب معرّضة للخطر: PHP-FPM وApache مع mod_php وphp-cgi وFrankenPHP وLiteSpeed. والخطر ليس متساوياً بينها.
الاستضافة المشتركة مقابل خادمك الخاص. في الباقة المشتركة المُدارة، شركة الاستضافة تملك بناء PHP وعليها ترقيعه. أما على VPS أو خادم مخصّص فالمسؤولية مسؤوليتك، حتى لو ثبّت اللوحة شخص آخر. وإن لم تكن متأكداً أيّهما لديك، فدليلنا عن استضافة WordPress مقابل استضافة cPanel يشرح الفرق.
PHP 8.1 وما قبله. بلغ PHP 8.1 نهاية عمره في 31 ديسمبر 2025، و8.0 و7.4 انتهيا قبل ذلك بسنوات. قدّم مشروع PHP ترقيعات مصدرية محدودة للإصدارات 7.4 و8.0 و8.1 بسبب الخطورة، لكنها موجّهة لمن يبني من الشيفرة المصدرية. إن كان موقعك ما زال يعمل عليها، فاطلب من مورّدك حزمة مرقّعة اليوم وخطّط للترحيل هذا الربع. وPHP 8.2 نفسه يبلغ نهاية عمره في 31 ديسمبر 2026، لذا 8.3 أو 8.4 هو الهدف المعقول.
هل يجري استغلالها؟ تذكر Qualys أن Amazon Threat Intelligence وCloudflare رصدتا حركة هجومية تستهدف هاتين الثغرتين، وأن Patchstack تلقّت بلاغات استغلال من شركاء استضافة. تعامل مع الأمر على أنه نشط لا نظري.
ما عليك فعله اليوم
- اعثر على كل PHP يخدم طلبات الويب. تشغيل php -v في سطر الأوامر يُظهر غالباً ملفاً تنفيذياً مختلفاً عمّا يستخدمه خادم الويب. افحص المعالج في لوحتك (MultiPHP Manager في cPanel، إعدادات PHP في Plesk) أو صفحة phpinfo، وتذكّر أن الخادم قد يشغّل عدّة إصدارات PHP في آن واحد. احسب كل واحد منها.
- حدّث إلى الإصدار المصلَح أو ترقيع المورّد. الأهداف هي 8.5.12 و8.4.27 و8.3.36 و8.2.35. تلقّى مورّدو التوزيعات والدعم الطويل الترقيعات مسبقاً، لذا قد تحمل الحزمة المرقّعة رقم إصدار أقدم؛ راجع نشرة مورّدك لا الرقم وحده. على خوادم cPanel وCloudLinux مثلاً صدر الإصلاح في 21–22 أكتوبر على هيئة ترقيع يحتفظ برقم الإصدار القديم (نشرة CloudLinux)، فتحقّق من سجلّ تغييرات الحزمة (الأمر rpm -q –changelog على حزمة PHP بحثاً عن معرّفَي CVE) لا من php -v؛ كما دفعت CloudLinux مجموعات قواعد Imunify360 8.83–8.85 التي تحجب حركة الاستغلال العلنية كترقيع افتراضي لا يغني عن التحديث. ويطلب فريق PHP أيضاً من مستخدمي حزم remirepo التطوّعية الانتقال إلى حزم التوزيعة أو البناء من المصدر، لأن ذلك المستودع لم تتوفّر له تحديثات يوم الإصدار.
- أعد تشغيل كل عامل PHP. الملف التنفيذي الجديد على القرص لا يغيّر شيئاً حتى يُعاد تشغيل Apache أو PHP-FPM أو LiteSpeed. أعد تشغيل كل التجمّعات لا موقعاً واحداً.
- إن لم تستطع الترقيع بعد، طبّق التخفيفات المؤقّتة. هي تقلّل التعرّض لكنها لا تجعل الخادم آمناً. للثغرة CVE-2026-109618: اضبط memory_limit=-1 إدارياً (php_admin_value في تجمّع FPM أو إعدادات Apache) كي لا يستطيع أي موقع إعادة حدّ محدود؛ وأبقِ post_max_size منخفضاً (8M حيث لا حاجة للرفع، و32M حيث الحاجة) مع upload_max_filesize أدنى منه؛ وحدّد حجم الطلب وعدد الحقول وأجزاء multipart والترويسات على مستوى خادم الويب أو الوكيل؛ ولا تستخدم RLIMIT_AS أو RLIMIT_DATA. وللثغرة CVE-2026-109619: اضبط session.upload_progress.enabled=0، وعلى PHP 8.5 اضبط fatal_error_backtraces=0، كليهما في إعدادات بدء التشغيل (لا ini_set ولا .user.ini)، ثم أعد تشغيل العمّال؛ وأزل توجيهات INI غير الصالحة أو المهجورة المطبَّقة لكل طلب؛ واختيارياً اضبط pm.max_requests=1 على FPM إن سمح الأداء.
- تحقّق. افتح صفحة phpinfo أو افحص المعالج لكل موقع وتأكّد أن سلسلة الإصدار واحدة من الإصدارات الأربعة المصلَحة أو بناء المورّد المرقّع. وتأكّد أن العمّال أُعيد تشغيلهم بعد التحديث.
- أعد memory_limit بعد الترقيع. ضبط memory_limit=-1 حلّ مؤقّت. حين يصبح البناء المرقّع فعّالاً، أعد حدّاً معقولاً كي لا يُسقط سكربت جامح الخادم كلّه.
- ابحث عن علامات الاختراق. ملفات مجهولة في مجلّدات الرفع، مستخدمون إداريون جدد، مهام cron لم تنشئها. قائمتنا عن علامات اختراق موقعك تغطّي ما تفحصه وبأي ترتيب.
ما تفعله بيغ بانغ لحلول تقنية المعلومات
تعمل خوادمنا المشتركة والمُدارة على بنى PHP من cPanel EasyApache وCloudLinux. في صباح 22 أكتوبر 2026 لم تكن حزم المورّدَين التي تحمل الإصدارات المصلَحة متاحة بعد، فطبّقنا في 22 أكتوبر إجراءات التخفيف المؤقتة الآمنة على الخوادم المشتركة (تعطيل تتبّع تقدّم الرفع في الجلسات وتعطيل تتبّع الأخطاء الفادحة) على كل بنى PHP وأعدنا تشغيل كل عمليات PHP. وبحلول منتصف النهار وصل الترقيع إلى بنى cPanel EasyApache على خادمنا المشترك الرئيسي (تحقّقنا منه في سجلّ تغييرات الحزمة) وأُعيد تشغيلها؛ وتبقى البنى الأخرى تحت التخفيف المؤقت حتى وصول حزمها، ويفحص فريقنا قنوات المورّدين كل ساعة. عملاء باقاتنا المشتركة والمُدارة لا يحتاجون إلى أي إجراء. أما من يشغّل خادم VPS أو خادماً مخصّصاً خاصاً به فعليه الترقيع بنفسه؛ وإن فضّل أن نتولّى ذلك فإن عقد الصيانة السنوي لدينا يغطّي هذا النوع من الأعمال الطارئة تحديداً، بما فيه خطوة التحقّق.
ثلاثة قرارات تتّخذها هذا الأسبوع
- من يملك PHP على كل موقع من مواقعك؟ دوّنه: يديره المزوّد، أو خادمك الخاص، أو خادم وكالة. أي موقع بلا مالك واضح هو أول ما يجب إصلاحه.
- هل ما زلت تشغّل PHP 8.1 أو أقدم؟ إن كان الجواب نعم، فالترقيع المصدري جسر لا وجهة. جدوِل الترقية إلى 8.3 أو 8.4 قبل نهاية العام.
- هل تستطيع إعادة البناء لو اختُرق خادم الليلة؟ الخادم المرقّع هو الهدف، لكن النسخة الاحتياطية المختبَرة هي شبكة الأمان. خطّة النسخ الاحتياطي واستعادة الموقع لدينا تشرح كيف تبدو النسخة الصالحة للاستخدام.
الأسئلة الشائعة
موقعي على WordPress. هل تحديث WordPress يصلح هذا؟
لا. الثغرتان في محرّك PHP لا في WordPress ولا إضافاته ولا قوالبه. وعلى mod_php يكتمل الهجوم قبل أن يُحمَّل WordPress أصلاً. الإصلاح هو بناء PHP جديد على الخادم يثبّته من يدير ذلك الخادم. تحديث WordPress يبقى ممارسة جيدة، لكنه لا يغلق هاتين الثغرتين.
لوحة الاستضافة تُظهر PHP 8.3.35. هل هذا آمن؟
ليس بحدّ ذاته. الإصدار المصلَح لفرع 8.3 هو 8.3.36. غير أن بعض التوزيعات ومورّدي لوحات التحكّم يشحنون إصلاحات مرقّعة تحت رقم إصدار أقدم، فراجع نشرة المورّد نفسه أو سجلّ تغييرات الحزمة. وإن كانت الحزمة قد بُنيت قبل 21 أكتوبر 2026 فهي لا تحتوي على الإصلاح.
هل يكفي جدار الحماية أو WAF ريثما يصل الترقيع؟
يساعد لكنه لا يكفي. أبلغت Cloudflare عن حركة هجومية تشمل محاولات لتجاوز حمايتها، وفريق PHP يقول إن التحديث وحده هو الإصلاح الكامل. استخدم WAF لحجب طلبات multipart على المواقع التي لا تحتاج إلى الرفع، وطبّق التخفيفات المؤقّتة، ورقّع فور وصول الحزم.
المصادر
- CloudLinux: حالة حزم PHP وقواعد Imunify360 والتحقّق [PHP CVE-2026-109618 and CVE-2026-109619] (اطُّلع عليه في 2026-10-22)
- php.net: إشعار مسبق بإصدار أمني حرج، 20 أكتوبر 2026 [Upcoming Critical PHP Security Release] (اطُّلع عليه في 2026-10-22)
- php.net: نشرة أمنية، ثغرات تنفيذ أوامر عن بُعد حرجة، 21 أكتوبر 2026 [Security advisory: Critical remote code execution vulnerabilities] (اطُّلع عليه في 2026-10-22)
- php.net: الإصدارات النشطة (8.2.35 و8.3.36 و8.4.27 و8.5.12) (اطُّلع عليه في 2026-10-22)
- php.net: سجلّ تغييرات PHP 8 [PHP 8 ChangeLog] (اطُّلع عليه في 2026-10-22)
- php.net: الفروع غير المدعومة [Unsupported Branches] (اطُّلع عليه في 2026-10-22)
- نشرة GitHub GHSA-w8hw-w9fx-j79w: تنفيذ أوامر عبر تلف ذاكرة عند نفادها (CVE-2026-109618) [RCE via OOM corruption] (اطُّلع عليه في 2026-10-22)
- نشرة GitHub GHSA-6wmf-4rv5-p3rp: تنفيذ أوامر عبر حالة عامة بائتة (CVE-2026-109619) [RCE via stale global state] (اطُّلع عليه في 2026-10-22)
- Qualys: PHP تعلن إصداراً أمنياً حرجاً لثغرتين [PHP Announces Critical Security Release for Two Vulnerabilities] (اطُّلع عليه في 2026-10-22)
أين نحن
بيغ بانغ لحلول تقنية المعلومات تخطّط وتدير التقنية لشركات الإمارات منذ 2003، مقرّها في مجمّع الشارقة للبحوث والتكنولوجيا والابتكار وفرعها في الخليج التجاري بدبي. الدعم على مدار الساعة، والمكتب مفتوح من السبت إلى الخميس، 9:00–18:00 بتوقيت الإمارات. إن لم تكن متأكداً أي نسخة PHP تخدم موقعك، تواصل معنا أو راسلنا على واتساب.
تحدّث إلينا مباشرةً — نردّ عادةً خلال دقائق في ساعات العمل.
