العودة

PHP تحذر من خطر RCE غير مُعالج في إعداد ضيق بعد تصحيحات PHP2Shell الطارئة
SiTech AI Team3 دقيقة قراءة

PHP تحذر من خطر RCE غير مُعالج في إعداد ضيق بعد تصحيحات PHP2Shell الطارئة

تحذر PHP من CVE-2026-115560، وهو خطر منفصل غير مُعالج لتنفيذ تعليمات برمجية يقتصر على تغييرات غير معتادة في معالج الجلسات، وتوصي بتعطيل session upload progress حتى الإصدار الروتيني التالي.

حذرت PHP من طريقة أخرى يمكن لمهاجم أن ينفذ بها تعليمات برمجية على خادم ويب، بعد يومين من إصدارها تصحيحات طارئة للثغرات الحرجة في PHP2Shell. تُتابع المشكلة الجديدة تحت CVE-2026-115560 وتؤثر فقط في تطبيقات ويب مضبوطة بطريقة غير معتادة، وفقًا للمشروع. وتعتبر PHP أنها خطر غير مرجح ولا تصدر إصلاحًا طارئًا لها.

تنبيه جديد وتخفيف موصى به

ورد التحذير في تنبيه إعلامي قصير نُشر في 23 أكتوبر. وتوصي PHP بتعطيل ميزة تسمى session upload progress حتى يتوفر إصلاح في الإصدار الروتيني التالي. الإجراء سطر واحد: اضبط session.upload_progress.enabled=0 حتى إصدار إصلاح الأخطاء الروتيني التالي.

هذا هو الإعداد نفسه الذي أدرجته PHP بالفعل كتخفيف في تنبيه 21 أكتوبر الخاص بـ CVE-2026-109619. ومن طبّقه حينها وتركه في مكانه لا يحتاج إلى فعل المزيد للمشكلة الجديدة. ميزة session upload progress مفعّلة افتراضيًا وتتيح للتطبيق تتبع تقدم رفع ملف.

إعداد ضيق معرض للخطر

تقول PHP إن المشكلة يمكن أن تحدث عندما يفعل تطبيق ويب كل ما يلي: يضبط خيار session.serialize_handler على php_binary أو php_serialize في إعداداته، ثم يغيّر ذلك الخيار إلى php أثناء التشغيل عبر استدعاء ini_set()، ويجري ذلك التغيير قبل استدعاء session_start(). ويجب أيضًا أن تظل ميزة session upload progress مفعّلة.

التطبيق الذي لا يغيّر معالج serialize أثناء التشغيل يمكنه إبقاء الميزة مفعّلة ولا يكون مكشوفًا عبر هذا المسار، وفقًا لـ PHP. ويقول المشروع إن هذا الإعداد غير مرجح عمليًا. ولأن الإعداد غير شائع، تتعامل PHP مع الإصلاح كجزء من دورة إصداراتها العادية بدلًا من كونه إصلاحًا طارئًا، وستنشر تنبيهًا كاملًا لـ CVE-2026-115560 مع الإصدار التالي.

لم تذكر PHP أي الإصدارات متأثرة، أو أي الإصدارات ستتضمن الإصلاح، أو درجة خطورة. ولم تقل أيضًا ما إذا كانت المشكلة الجديدة تشترك في سبب جذري مع CVE-2026-109619. ولم يُبلَّغ عن أي استغلال لـ CVE-2026-115560.

ثغرات PHP2Shell السابقة ونشاط الهجمات

تأتي المشكلة الجديدة بعد الإصدار الطارئ في 21 أكتوبر الذي أصلح ثغرتين حرجتين في PHP2Shell، هما CVE-2026-109618 و CVE-2026-109619، اللتين سمحتا لمهاجم دون حساب بتشغيل تعليمات برمجية على خادم. جرى تصحيحهما في PHP 8.5.12، و8.4.27، و8.3.36، و8.2.35. والمشكلة الجديدة منفصلة وليست مصححة بهذه الإصدارات.

تستهدف الهجمات المبلّغ عنها منذ 21 أكتوبر الثغرتين السابقتين في PHP2Shell. تصاعدت محاولات استغلال تلك الثغرات. قالت Amazon إن مصائد العسل لديها سجلت محاولة استغلال ضد CVE-2026-109618 و CVE-2026-109619 في 17 أكتوبر، أي قبل أربعة أيام من الكشف عن الثغرتين. وقالت Cloudflare إن المحاولات ارتفعت من عشرات الآلاف خلال 45 دقيقة من الكشف في 21 أكتوبر إلى ملايين بحلول وقت مبكر من 22 أكتوبر.

حاول المهاجمون استخدام الثغرات لتثبيت نسخة من بوتنت Mirai، وفقًا لـ Sophos و Arctic Wolf. فشلت تلك المحاولات حتى الآن: يبلغ Previdian و Wordfence وآخرون عن فحص واستكشاف لكن دون تنفيذ تعليمات برمجية مؤكد، ويقول باحثون إن بناء استغلال موثوق يثبت أنه أصعب من المتوقع. يستهدف ذلك النشاط الثغرتين المصححتين في 21 أكتوبر، وليس CVE-2026-115560، الذي لم يُبلَّغ عنه تحت الهجوم.

تغطية سابقة: تصحيحات PHP2Shell صدرت: ما المعرض للخطر وكيف تحمي مواقع PHP · VulnCheck تطوّر استغلالًا لـ PHP2Shell يتجاوز ASLR على أنظمة الإنتاج

المصادر: The Hacker News · PHP · CERT-EU

SiTech

SiTech — تطوير ويب مدعوم بالذكاء الاصطناعي

نبني مواقع سريعة وعصرية وندمج الذكاء الاصطناعي في سير عمل الشركات. لديك مشروع أو سؤال؟ يسعدنا مساعدتك.