الأسئلة الشائعة
ما إصدارات PHP المتأثرة؟
كل الإصدارات السابقة لـ 8.5.12 و8.4.27 و8.3.36 و8.2.35 في الفروع المدعومة. انتهى دعم PHP 8.1 وما قبله ولا يصدر لها مشروع PHP أي إصدار؛ اعتبرها متأثرة ما لم يؤكد المورّد وجود إصلاح منقول.
موقعي لا يُظهر إصدار PHP. هل أنا في أمان؟
ليس بالضرورة. إخفاء الإصدار (expose_php = Off) ممارسة جيدة لكنه لا يُصلح شيئًا. تحقق على الخادم باستخدام php -v أو اسأل مزوّدك.
تُظهر الأداة إصدارًا قديمًا، لكن مزوّد الاستضافة يقول إنه مُصلَح. من المحق؟
ربما كلاهما. كثيرًا ما تنقل توزيعات Linux مثل Debian وUbuntu وRHEL الإصلاحات الأمنية دون تغيير رقم الإصدار. اسأل مزوّد الاستضافة عن بنية الحزمة المثبّتة وهل يذكر سجل تغييراتها CVE-2026-109618 وCVE-2026-109619.
هل يتأثر WordPress أو Laravel أو نظام إدارة المحتوى لدي؟
الخلل في PHP نفسه، لذا فإن أي تطبيق يعمل على إصدار PHP متأثر يكون معرّضًا. عرض الباحثون هجمات لا تتطلب مصادقة على WordPress وDrupal وJoomla، لكنها مجرد أمثلة، إذ تكفي حتى صفحة «Hello World» بسيطة. تحديث WordPress أو الإضافات لا يحل المشكلة، بل يجب تحديث PHP.
هل يمكن أن تتسرّب البيانات حتى لو لم تُنفَّذ أي شفرة؟
نعم. قد يكشف CVE-2026-109619 ذاكرة عملية PHP — كلمات المرور ورموز الجلسات ومفاتيح API والشهادات من طلبات أخرى — دون أن يشغّل المهاجم أي شفرة. لا تترك هذه التسريبات ملفات ويصعب اكتشافها، لذا غيّر أسرار أي موقع عمل بإصدار متأثر على الإنترنت.
هل يُصلح تعطيل session.upload_progress المشكلة؟
لا. يذكر php.net الإعداد session.upload_progress.enabled=0 كتدبير مؤقت جزئي لبعض المسارات المؤكدة في CVE-2026-109619. لا يغطي كل المتغيرات ولا يفيد إطلاقًا ضد CVE-2026-109618.
هل يكفي جدار حماية تطبيقات الويب؟
قد يقلل WAF أو تقييد الطلبات من التعرض ريثما تُحدّث، لكن المشكلات تكمن في طريقة تعامل PHP مع الطلبات والذاكرة. يبقى التحديث ضروريًا.
هل أحتاج إلى إعادة تشغيل أي شيء بعد التحديث؟
نعم. يستمر PHP-FPM وApache وLiteSpeed والعمليات طويلة الأمد في تشغيل الشفرة القديمة حتى تُعاد تشغيلها. ويجب إعادة إنشاء الحاويات من الصورة الجديدة.
ماذا تفعل هذه الأداة فعليًا؟
ترسل طلب HEAD واحدًا (أو GET إن لم يكن HEAD مسموحًا) إلى العنوان الذي تدخله، وتتبع ما يصل إلى ثلاث عمليات إعادة توجيه، وتقرأ ترويسات الاستجابة مثل X-Powered-By وServer. لا ترسل أبدًا حمولات استغلال أو طلبات كبيرة أو ملفات مرفوعة، ولا تفحص مسارات أخرى.
هل فحص أي موقع قانوني؟
افحص فقط المواقع التي تملكها أو المخوّل بتقييمها. الطلب مماثل لزيارة عادية، لكن الاستخدام المسؤول يقع على عاتقك. نحن نحدّ عدد عمليات الفحص لكل شبكة ولكل موقع.
هل أُصلح PHP 8.5.12 بالكامل؟
انتشرت في 22 أكتوبر 2026 تقارير عن عطل في 8.5.12، لكن لم يُؤكَّد أنها ثغرة قابلة للاستغلال عن بُعد. نحن نتابع php.net؛ وإن صدر إصدار جديد فسيُحدَّث هذا الموقع ويتغيّر تاريخ «آخر تحقق».
أين يمكنني قراءة التفاصيل الرسمية؟
على php.net وفي النشرات الأمنية لمشروع PHP على GitHub: GHSA-w8hw-w9fx-j79w وGHSA-6wmf-4rv5-p3rp. ونشر فريق البحث (Wiz Research وOpenAI Codex Security وCalif) نتائجه على php2shell.com.
من اكتشف الثغرات؟
باحثون من Wiz Research وOpenAI Codex Security وCalif، عبر إفصاح منسّق مع فريق أمن PHP الذي أعدّ الإصلاحات. راجع منشور The PHP Foundation عن الإصدار.