PHP2Shell: لما غلطة في الذاكرة تفتح باب السيرفر

خبر عن ثغرة في PHP ممكن يبان بعيد عنك، لحد ما تعرف إن مهاجم يقدر يستغلها وينفّذ أوامر على السيرفر اللي عليه موقعك.

أول سؤال ساعتها: هو إحنا مشغّلين PHP بإصدار إيه؟

آخر مراجعة للمعلومات: ٢٧ أكتوبر ٢٠٢٦.

في تحديثه يوم ٢٧ أكتوبر، أشار المركز الكندي للأمن السيبراني إلى تقارير عن استغلال ثغرتي PHP2Shell فعليًا. وقبلها بيوم، أضافت CISA الثغرتين إلى قاعدة الثغرات المعروفة باستغلالها.

التحديث بقى أولوية عاجلة. راجع سجلات السيرفر كمان، ودور على طلبات أو عمليات مشبوهة. ولو لقيت علامات اختراق، فالتحديث لوحده مش كفاية. لازم تفحص السيرفر وتتعامل مع احتمال إن حد دخل عليه بالفعل.

ثغرتا PHP2Shell

في أكتوبر 2026، أعلن فريق PHP عن ثغرتين خطيرتين في اللغة نفسها: CVE-2026-109618 وCVE-2026-109619.

الخلل في طريقة تعامل محرك PHP مع الذاكرة والطلبات. يعني ممكن يكون التطبيق سليم، لكن الثغرة موجودة في اللغة اللي بتشغّله.

الأولى بتحصل في حالة نفاد الذاكرة. في ظروف معيّنة، PHP يوقف الطلب بعد ما يجهّز جزء من بياناته الداخلية، ويسيب جزء تاني من غير تهيئة. ولما يبدأ التنضيف، ممكن يتعامل مع البيانات الناقصة كأنها جاهزة.

الثانية مرتبطة ببيانات مؤقتة لسه محتفظة بعنوان في الذاكرة بعد ما المكان اتفضّى. لو طلب تاني وصل لنفس عامل PHP، ممكن يقرأ الحالة القديمة قبل ما البرنامج يهيّئها من جديد.

كأنك بتدور على درج في مكانه القديم بعد ما حد نقله. PHP بيتعامل مع عنوان بقى يشاور على مكان فاضي.

الثغرتان ممكن تسمحا لمهاجم ينفّذ أوامر عن بُعد من غير حساب على الموقع. مفيش تسجيل دخول مطلوب.

مين المفروض يقلق؟

لو PHP عندك بيستقبل طلبات ويب، راجع نسخته وحدّثها. ده يشمل PHP-FPM وApache وphp-cgi.

وخلي بالك إن PHP ممكن يكون مستخبي جوه منتج أو حاوية أو لوحة تحكم. مش لازم تكون فاتح مشروع PHP بنفسك عشان الخدمة اللي بتستخدمها تكون معتمدة عليه.

PHP 8.1 والإصدارات الأقدم ما بقتش تتلقى تحديثات أمنية مباشرة من فريق PHP. الفريق ما أصدرش نسخًا جديدة للفروع دي، لكنه نشر ترقيعات مصدرية محدودة لـ7.4 و8.0 و8.1. بعض توزيعات لينكس ومزوّدي الدعم الممتد ممكن يوفروا إصلاحاتهم كمان. لو موقعك على إصدار قديم، اسأل المزوّد عن حالة الإصلاح وخطّط للانتقال لنسخة مدعومة.

طب أعمل إيه؟

الإصدارات اللي أصلحت الثغرتين:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

لو بتاخد PHP من توزيعة لينكس أو شركة الاستضافة، راجع تحديثاتهم. أحيانًا بينزل الإصلاح كحزمة معدّلة، وساعتها رقم PHP الظاهر عندك ممكن يفضل مختلف.

لو لوحة التحكم مش عارضة تحديث، اسأل المزوّد عن الإصلاح. عدم ظهور تحديث عندك مش دليل إن النسخة آمنة.

لو مش قادر تحدّث فورًا، فريق PHP نشر إجراءات مؤقتة تقلل خطر بعض طرق الاستغلال. لمسار نفاد الذاكرة، التوصيات تشمل ضبط memory_limit=-1 من إعداد على السيرفر ما يقدرش التطبيق يغيّره، وخفض post_max_size، وفرض حدود على حجم الطلب ومكوناته.

خد بالك إن memory_limit=-1 بيلغي حد الذاكرة الخاص بـ PHP. لازم تستخدمه مع حد خارجي للموارد، زي cgroup أو حدود ذاكرة الحاوية، ومع إعداد يوقف العامل المتضرر من غير ما يعطل الخدمة كلها. ما تستخدمش RLIMIT_AS أو RLIMIT_DATA بدل الحدود دي، لأنهم ممكن يسببوا فشل تخصيص الذاكرة اللي بيؤدي للمشكلة.

أما لمسار حالة الذاكرة القديمة، فأوصى الفريق بتعطيل session.upload_progress.enabled=0 من إعدادات السيرفر، مثل php.ini أو إعدادات PHP-FPM، وبعدها إعادة تشغيل كل عمال PHP المتأثرين. ما تعتمدش على ini_set() أو .user.ini لتعطيل الإعداد ده.

راجع إعدادات الاستضافة قبل تطبيق الإجراءات دي. هي بتقلل طرق استغلال معيّنة، لكن تحديث PHP للإصدار المصحح هو الحل الكامل.

وفيه تفصيلة زيادة

في ٢٣ أكتوبر، نشر فريق PHP تحذيرًا عن ثغرة تانية مرتبطة برفع الملفات والجلسات: CVE-2026-115560.

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

لحد ما يتوفر الإصلاح، أوصى فريق PHP بتعطيل الإعداد ده:

session.upload_progress.enabled=0

التعطيل ده يقلل خطر طريقة الاستغلال دي. يفضل تحديث PHP أول ما يتوفر الإصلاح.

وفي ٢٦ أكتوبر، أعلن فريق PHP عن تحديث لحزم ويندوز لإصلاح ثغرة منفصلة في Brotli، رقمها CVE-2026-111497. الخلل في فك ضغط بيانات Brotli، والتطبيق ممكن يوصل له عن طريق cURL لو فك الضغط التلقائي لاستجابات HTTP مفعّل. الإعداد ده مقفول افتراضيًا في cURL، لكن التطبيق أو مكتبة الاتصال ممكن يفعّله.

لو رقم الحزمة آخره -1، زي 8.4.27-1، فده معناه إن حزمة ويندوز اتبنت من جديد بمكتبات محدّثة. إصدار PHP نفسه زي ما هو.

أمان الموقع محتاج متابعة

حتى لو كود التطبيق متأمن كويس، خلل في PHP أو في حزمة بيستخدمها ممكن يعرّض السيرفر للخطر. عشان كده لازم تتابع تحديثات PHP والحزم والسيرفر جنب مراجعة كود التطبيق.

عارف إن التحديثات الأمنية مملة، بس تأجيلها ممكن يسيب السيرفر مكشوفًا لمهاجم ينفّذ عليه أوامر.

الخلاصة

لو موقعك أو خدمتك بتستخدم PHP، اعرف الإصدار اللي شغال فعلًا، وشوف تحديث المزوّد، وثبّت الإصلاح المناسب.

ولو السيرفر مش مسؤوليتك، اسأل الشخص اللي بيتابعه: «هو PHP عندنا متحدث؟» أهون من رسالة تيجي لك وتبدأ بـ«لاحظنا نشاطًا غير معتاد».

مصادر وتفاصيل التحديث من فريق PHP، ومتابعة الحالة والتوصيات من المركز الكندي للأمن السيبراني.