ثغرتان بتقييم 9.2 من 10. مفسّر واحد. معظم الويب.
إذا كنت عميلاً لدى aratech أو كان موقعك مستضافاً عندنا، راسلنا فوراً على [email protected]. سنؤكد لك إصدار PHP لديك، وحالة التحديث الأمني، وما نقوم به بشأنه. لا تنتظر نشرة بريدية لتشرح لك الأمر.
هذه ليست مشكلة إضافة. وليست مشكلة قالب. وليست عيباً في ووردبريس أو ماجنتو أو لارافيل.
المشكلة في PHP نفسها.
ثغرتان حرجتان في نواة PHP، تُعرفان بـ CVE-2026-109618 و CVE-2026-109619، تسمحان لمهاجم غير مُصادَق عليه بتنفيذ كود عشوائي على خادم الويب. فريق أمن PHP يقيّم الثغرتين بـ 9.2 من 10 وفق CVSS v4.0. صدرت حزمة التحديثات الطارئة اليوم، 21 أكتوبر 2026، الساعة 14:00 بتوقيت UTC (18:00 بتوقيت دبي). الفروع المُصحَّحة هي PHP 8.5.12 و8.4.27 و8.3.36 و8.2.35.
التفصيل الذي يجب أن ينبّهك: تسرّبت تفاصيل هذه الثغرات علناً في 20 أكتوبر، أي قبل الإفصاح المنسّق بنحو يوم. حمل التسريب معرّفات CVE وتقييماً للخطورة وتاريخاً، وتناقل الناس صورة لأداة استغلال تُسمّى PHP2Shell منسوبة إلى Calif.IO، مع لافتة تزعم أنها تعمل ضد كل إصدار من PHP منذ 5.4.0. وبقيت التفاصيل التقنية تحت الحظر حتى الساعة 14:00 بالتوقيت العالمي اليوم. أي أن الإنترنت كله يتلقى التحديث ومادة الهندسة العكسية في اللحظة نفسها.
ما هما الثغرتان فعلاً
كلتاهما خلل في سلامة الذاكرة داخل دورة حياة الطلب. لا تحتاج أي منهما إلى تسجيل دخول أو إضافة أو صفحة مكتوبة بشكل سيئ.
CVE-2026-109618، تنفيذ كود عبر تلف عند نفاد الذاكرة. عندما تصل PHP إلى حالة نفاد الذاكرة، قد تُقاطَع العملية بينما بيانات الطلب الداخلية مُهيّأة جزئياً فقط. فتعامل مرحلة التنظيف تلك البيانات غير الصالحة كأنها صالحة، ومن يستطيع إحداث فشل التخصيص يحدّد ما يحدث بعد ذلك.
CVE-2026-109619، تنفيذ كود عبر حالة عامة قديمة. يمكن أن تبقى الحالة الداخلية المرتبطة بالطلب بعد تحرير الذاكرة التي كانت تحملها. فيستهلك طلب لاحق يعالجه العامل نفسه تلك الحالة القديمة قبل أن تعيد التهيئة الطبيعية تصفيرها. إعادة استخدام العمال تتحول هنا إلى سطح هجوم.
ينص إشعار PHP على أن الخطر الأعلى مع mod_php، حيث يسمح استغلال مُثبت لطلب غير مُصادَق عليه بإطلاق الهجوم قبل تنفيذ أي كود من التطبيق. وهذه أهم جملة في المقال: إطار العمل وقواعد جدار الحماية ومنطق التطبيق ليست على مسار الهجوم.
من المعرّض للخطر
كل من يقدّم PHP عبر PHP-FPM أو Apache مع mod_php أو php-cgi أو FrankenPHP أو LiteSpeed داخل النطاق. أي الإعداد الافتراضي لجزء هائل من الإنترنت.
تعمل PHP على نحو سبعة من كل عشرة مواقع تستخدم لغة معروفة من جهة الخادم. ووردبريس ودروبال وجوملا وماجنتو ولارافيل وسيمفوني وتطبيقات مخصصة وسلسلة طويلة من الأجهزة والأدوات التي تُضمّن PHP بصمت. وتشير تقارير إلى أن النطاق المتأثر يمتد إلى عصر PHP 5 عام 2004. وسيتضح النطاق الدقيق لكل إصدار مع نشر المزوّدين لإشعاراتهم. أحصت Mallory في 20 أكتوبر نحو 884 ألف مضيف مكشوف على الإنترنت ما زال يعلن عن PHP 8.1 أو أقدم أمام Shodan، أي 59% من كل مضيف أعلن عن إصدار.
وهنا الجزء الذي يتجاوزه معظم الناس: PHP 8.1 وما قبلها لم تعد تتلقى تحديثات من مشروع PHP. نشر الفريق تحديثات مصدرية محدودة لـ 7.4 و8.0 و8.1، لكن إن كنت على فرع منتهي الصلاحية ولا تتحكم في بناء النسخة، فأنت غير مُحدَّث. أنت تنتظر جدول شخص آخر.
لماذا الساعات الـ48 القادمة أهم من الثغرة نفسها
ثغرة معروفة لكن غير علنية هي سباق بين الباحثين والمدافعين. أما ثغرة تحديثها علني فهي سباق بين المهاجمين وكل من عداهم.
بمجرد أن تصبح النسخ المُصحَّحة قابلة للتنزيل، يستطيع أي شخص مقارنتها بالكود المصاب وهندسة المشغّل عكسياً. وهذا ليس قلقاً نظرياً، بل السيناريو المعتاد، ويُقاس بالساعات لا بالأسابيع. تتوقّع Sansec هجمات واسعة بعد نحو خمس عشرة دقيقة من الإصدار. ويبلّغ Patchstack عن استغلال نشط لدى شركاء استضافة، وسجّلت Cloudflare محاولات هجوم مبكرة. وهذه الأسبقية تُستَخدم فعلاً.
وردّ المؤسسات إشارة أخرى. خدمات هولندية مثل DigiD وMijnOverheid وموقع مجلس النواب وTweakers خرجت من الخدمة كإجراء احترازي. ومنصات يابانية كبرى انتقلت إلى صيانة طارئة. وأطفأ فريق The SEO Framework خوادمه. ونشرت CERT-EU الإشعار 2026-018، ودعا المركز البريطاني NCSC إلى التحديث الفوري أو فصل الأنظمة إذا لم يكن الإصلاح ممكناً.
حين تختار الحكومات التوقف عن العمل بدل التعرّض، فهذا هو التقييم الصادق للخطورة.
افعل هذا الآن، بهذا الترتيب
- اجرد قبل أن تُحدّث. كل تثبيتات PHP التي تديرها: الإنتاج والاختبار والحاويات والخوادم المخصصة لمهام cron والأجهزة والأدوات الخارجية التي تُضمّن PHP. لا يمكنك تحديث ما نسيته.
- انتقل إلى إصدار مُصحَّح. 8.5.12 أو 8.4.27 أو 8.3.36 أو 8.2.35. في الاستضافة المُدارة، اطلب النافذة الزمنية الدقيقة كتابةً، وتحقّق من الإصدار الفعلي بعدها. لا تفترض أن إشعار صيانة يعني أن مواقعك انتهت.
- إذا كنت على PHP 8.1 أو أقدم، قرّر اليوم. إما تبني باستخدام تحديثات فريق أمن PHP، أو تنتقل إلى فرع مدعوم. لا يوجد خيار ثالث اسمه "آمن".
- أعد تشغيل كل العمال. PHP-FPM وApache وLiteSpeed وFrankenPHP وأي عمليات CLI طويلة الأمد. تحديث مثبّت وغير مُعاد تحميله هو تحديث لا يعمل.
- طبّق التحصين المؤقت حتى بعد التحديث. تكلفته في
php.iniأو إعداد المسبح منخفضة، ولا ضرر من إبقائه:session.upload_progress.enabled = 0على مستوى المسبح أو الخادم، وليس عبرini_set()أو.user.inimemory_limit = -1مفروضاً حيث لا يستطيع التطبيق تجاوزهpost_max_size = 8Mإن لم تكن تقبل رفع ملفات، و32Mإن كنت تحتاجها، معupload_max_filesizeأصغر منه- على PHP 8.5:
fatal_error_backtraces = 0
- ابحث، لا تكتفِ بالتحديث. إذا كان موقعك متاحاً وغير مُحدَّث، فافحص الملفات غير المتوقعة، وملفات PHP المعدّلة في مجلدات الرفع، وحسابات المدير الجديدة، والاتصالات الصادرة التي لم تُعدّها، ومهام cron التي لم تنشئها. التحديث يغلق الباب لكنه لا يُخرج من دخل سابقاً.
- تجاهل إضافات الحلول السحرية. تنتشر مقاطع منسوخة وإضافات "إصلاح PHP2Shell" غير موثوقة. ليست معتمدة، ولن تعمل، وبعضها هو الهجوم نفسه.
الدرس غير المريح
كل بضع سنوات يذكّرنا الويب بأن بيئة التشغيل التي تحمل كل شيء هي برنامج له عيوبه. والفاتورة عادةً باهظة.
النمط الذي نراه في aratech مراراً: التطبيق تم تحديثه، وأطر العمل بقيت حديثة، وإصدار PHP تحته بقي كما هو لسنوات لأنه كان يعمل. PHP 7.4 خارج الدعم منذ نوفمبر 2022. أي نحو أربع سنوات بلا تحديثات أمنية رسمية، على فرع يحتاج الآن تحديثات من المزوّد لينجو من ثغرة كهذه.
انتهاء الصلاحية ليس تفضيلاً في الصيانة. إنه خطر غير مُدار عليه تاريخ، واليوم حلّ ذلك التاريخ.
إن كنت على فرع قديم، خطّط للترقية كمشروع حقيقي: خادم نظيف، وإصدار حديث من PHP وإطار العمل، واختبار كامل، ثم انتقال مع إبقاء البيئة القديمة كخط رجوع. أيام قليلة من العمل غير المريح، تتكرر كل بضع سنوات، مقابل بديل هو الأمل بأن الثغرة القادمة بتقييم 9.2 لن تصلك.
إن لم تكن متأكداً، اسألنا اليوم
إن كنت عميلاً لدى aratech أو كان موقعك مستضافاً عندنا، راسلنا فوراً على [email protected] وسنخبرك بموقفك بدقة: إصدار PHP لديك، وهل هو مُحدَّث، وهل رأينا شيئاً مريباً في بنيتك التحتية، وما يجب فعله تالياً.
وإن لم تكن عميلاً ولا تعرف أي إصدار PHP يعمل عليه موقعك، فهذه هي إجابتك. راسلنا على أي حال. هذا هو الأسبوع المناسب لمعرفة ذلك.