إصلاح ثغرتي PHP يصدر بعد تأخر منذ 2024، والذكاء الاصطناعي خفّض كلفة استغلالهما
صدر في 21 أكتوبر 2026 الإصلاح الذي أعلن فريق أمان PHP موعده دون تفاصيل، ومعه ظهرت القصة كاملة. فأول علامة على الخلل اكتُشفت في 2024، وافترض الفريق حينها أنه قد يُستغل، لكنه لم يجد طريقًا فعليًا لذلك. وكان لكل حل مقترح ثمن: توافق ينكسر، أو إضافات كثيرة يجب أن تتغير. فبقي الإصلاح يتوقف ويعود لشهور.
وتصف PHP Foundation هذا التأخير بأنه “فشل بنيوي”، سببه طريقة اتخاذ القرار داخل فريق الأمان ونقص موارده، وتقول إنها تغيّر الاثنين.
أما الآلية فواضحة. إذا وصل طلب إلى حد memory_limit في لحظة غير مناسبة، يتوقف PHP وبعض بياناته الداخلية لم يكتمل تجهيزها. وقد يتعامل معها بعد ذلك كأنها سليمة، أحيانًا في طلب آخر تمامًا على الـ worker نفسه. ومن هنا يمكن أن يصل الهجوم إلى تشغيل كود على الخادم دون تسجيل دخول.
والذي تغيّر هذا العام هو كلفة بناء الاستغلال. فقد كتب فريق Wiz أن الموديلات المتقدمة مكّنته من تطوير استغلال يعمل وتكييفه على تطبيقات متعددة في ساعات، وجرّبه على WordPress وDrupal وJoomla. وبذلك تفقد حجة “صعوبة الاستغلال” كثيرًا من وزنها، لأن ما كان يحتاج أسابيع من خبير صار ممكنًا بسرعة أكبر بكثير.
والنسخ التي تحمل الإصلاح هي 8.5.12 و8.4.27 و8.3.36 و8.2.35. ولمن ما زال على 7.4 أو 8.0 أو 8.1، نشر الفريق backports بسيطة لمن يبني PHP من المصدر. كما فعّلت Cloudflare قواعد WAF تلقائيًا على كل الخطط التي تستخدم الـ WAF، ومنها الخطة المجانية، وهي تخفيف لا يغني عن التحديث. ونشرت OpenAI أداة مفتوحة تكشف نسخة PHP على موقع أو خادم دون إرسال أي استغلال.
وفي المنطقة مواقع كثيرة قائمة على WordPress في استضافات مشتركة، وتوقيت وصول الإصلاح إليها يحدده مزوّد الاستضافة لا صاحب الموقع.