رقّعت PHP2Shell وارتحت؟ PHP حذّرت من ثغرة جديدة بتتسكّر بسطر واحد

بعد يومين من رقع PHP2Shell، نزّلت PHP تحذير معلوماتي عن CVE-2026-115560: مسار RCE جديد ما بتسكّره تحديثات 21 تشرين الأول. المتأثرين قلال، والحل سطر واحد بالإعدادات.

نُشر في 3 دقائق قراءة#تحديثات أمنية#أمن التطبيقات

يوم 21 تشرين الأول رقّعنا PHP من ثغرتين خطيرتين والكل ارتاح. ويوم 23 تشرين الأول 2026، بعد يومين بس، نزّلت PHP تحذير معلوماتي عن مسار جديد لتنفيذ كود عن بعد (RCE)، برقم CVE جديد، وتحديثات 21 تشرين الأول ما بتسكّره. PHP نفسها بتقول إنو الاحتمال ضعيف، والحل سطر واحد بالإعدادات.

شو هي CVE-2026-115560؟

CVE-2026-115560 ثغرة تنفيذ كود عن بعد بـ PHP، بس مش وحدة من ثغرتين PHP2Shell، وتحديثات 21 تشرين الأول ما بتسكّرها.

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

إمتى بتكون متأثر فعلاً؟

PHP حاطة تلات شروط، ولازم التلاتة يجتمعوا مع بعض:

  1. إعداداتك حاطة session.serialize_handler على php_binary أو php_serialize.

  2. تطبيقك بيبدّلها لـ php أثناء التشغيل بـ ini_set()، قبل ما ينادي session_start().

  3. ميزة session upload progress لسا شغالة.

إذا تطبيقك ما بيبدّل الـ serialize handler أثناء التشغيل أبداً، فيك تخلي الميزة شغالة وما عليك شي من هالطريق. ولهيك PHP بتوصف الإعداد المطلوب إنو «غير محتمل عملياً».

كيف بتتأكد إذا إعداداتك متأثرة؟

بتتأكد بأمرين: الأول بيورجيك قيمة الـ handler الحالية، والتاني بيدوّر بكودك على أي ini_set() بيبدّلها.

# شو قيمة الـ handler الحالية؟
php -i | grep session.serialize_handler

# هل في شي كود بيبدّلها أثناء التشغيل؟
grep -rn "ini_set.*serialize_handler" --include='*.php' .

إذا الأول طلع php (القيمة الافتراضية) وما لقيت شي بالتاني، فإنت برّا دائرة الخطر من هالثغرة.

شو لازم تعمل؟ سطر واحد

إذا الشروط بتنطبق عليك، أو إذا ما بدك توجع راسك بالفحص، حط هالسطر:

session.upload_progress.enabled=0

مكانه php.ini أو الـ FPM pool أو إعدادات السيرفر، حسب تحذير PHP يوم 21 تشرين الأول، يعني أي مكان بيتطبّق قبل ما يبلّش تحليل الطلب. لا تعتمد على ini_set() ولا على .user.ini، لأنهن بيتطبّقوا متأخر وما بيلحقوا يسدّوا الطريق. وبعدين اعمل restart لكل الـ PHP workers لحتى يمشي التغيير.

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

ليش ما في رقعة طارئة؟

PHP ما نزّلت رقعة طارئة لأنو الإعداد المطلوب نادر عملياً، فرح تصلّحها بالدورة العادية. وتحذيرها ما ذكر أي استغلال.

هاد غير وضع ثغرتين PHP2Shell: كل تثبيت PHP بيخدم طلبات ويب كان معرّض إلهن، وPHP نزّلت إلهن تحديث طارئ يوم 21 تشرين الأول.

طيب، التحديثات لسا لازمة؟

إي. هالسطر ما بيغني عن تحديثات 21 تشرين الأول. ثغرتين PHP2Shell كانوا بتقييم 9.2 من 10 على CVSS v4.0، وبيسمحوا بتنفيذ كود بلا تسجيل دخول، وما إلهم حل كامل غير التحديث. إذا لسا ما حدّثت، حدّث قبل أي شي تاني.

وPHP مش لحالها هالأسبوع: GitLab انجبرت ترقّع مرتين بأقل من أسبوعين، وكل مرة لثغرة بعلامة 10.

وتحديثات Node.js لتشرين الأول سكّرت 10 ثغرات. فإذا عم تفحص إعدادات الجلسات اليوم، شوف نسخ هالأدوات على سيرفراتك معها.

إمتى آخر مرة راجعت إعدادات السيرفر تبعك سطر سطر؟

أسئلة شائعة

أنا حدّثت PHP يوم 21 تشرين الأول، لسا لازم أعمل شي؟

بس إذا تطبيقك بيبدّل session.serialize_handler أثناء التشغيل وميزة session upload progress لسا شغالة: وقتها طفّيها بـ session.upload_progress.enabled=0. وإذا طفيتها يوم 21 تشرين الأول، خلّيها مطفية وما عليك شي زيادة.

هالثغرة بتأثر على مواقع WordPress؟

بس إذا الموقع أو شي إضافة بيبدّلوا session.serialize_handler أثناء التشغيل، وهاد نادر. وتحديثات 21 تشرين الأول لازمة للكل بكل الأحوال.

في استغلال فعلي مرصود لهالثغرة؟

لأ، لحد 24 تشرين الأول ما في تقارير عن استغلال، وتحذير PHP ما ذكر أي استغلال. PHP عم تعالجها بالدورة العادية لأنو الإعداد المطلوب غير محتمل عملياً.

وين بحط إعداد التعطيل بالضبط؟

بـ php.ini أو FPM pool أو إعدادات السيرفر، يعني بمكان بيتطبّق قبل تحليل الطلب، وبعدين اعمل restart لكل PHP workers. لا تعتمد على ini_set() ولا .user.ini لأنهن بيتطبّقوا متأخر.

شارك المقال

مقالات أخرى