ثغرات PHP الحرجة: ملايين المواقع في خطر وماذا يجب أن تفعل الآن

هل تعلم أن موقعك قد يكون معرّضًا للاختراق دون أن تلمس فيه شيئًا؟ هذا ما حدث هذا الأسبوع مع ثغرتين حرجتين في PHP، بخطورة 9.2 من 10، تسمحان لأي مهاجم بتنفيذ أكواد على السيرفر دون تسجيل دخول. في هذا المقال أشرح لك ما جرى بلغة بسيطة، وكيف تتأكد أن موقعك محمي، وماذا تفعل إن لم يكن كذلك.

ماذا حدث بالضبط؟

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

صدرت التحديثات الطارئة يوم الأربعاء 21 أكتوبر 2026. وقالت كلاودفلير إنها بدأت تحجب محاولات الاستغلال منذ الساعة 3:02 فجرًا بتوقيت UTC، أي قبل الإعلان الرسمي بساعات.

وكان رد الفعل عالميًا: طالبت وكالات الأمن السيبراني في الولايات المتحدة وبريطانيا والاتحاد الأوروبي وكندا وأستراليا واليابان المؤسسات بتحديث أنظمتها فورًا. وأُوقفت مواقع حكومية في فنلندا وهولندا وبلجيكا وفرنسا أو تعطلت جزئيًا، وبعضها احترازيًا. وأوصت FBI وNSA بفصل الأنظمة عن الإنترنت إذا تعذّر تحديثها سريعًا.

الثغرتان في سطور

الثغرتان تحملان الرمزين CVE-2026-109618 وCVE-2026-109619، وتُعرفان إعلاميًا باسم PHP2Shell. كل واحدة حصلت على درجة خطورة 9.2 من 10.

المعلومة	التفصيل
نوع الخطر	تنفيذ أكواد عن بُعد (RCE) بدون تسجيل دخول
الإصدارات المصححة	8.5.12 ، 8.4.27 ، 8.3.36 ، 8.2.35
الإصدارات المتأثرة	أي إصدار أقدم من الإصدارات المصححة، بدءًا من الإصدار 5.4، حسب كلاودفلير
8.1 وما قبله	لا تحديثات رسمية، وتحتاج ترقية

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

لماذا الأمر بهذه الخطورة؟

تُستخدم هذه اللغة في نحو 70% من المواقع التي يُعرف لغة السيرفر الخاصة بها، وهي أساس وردبريس. وقد تكون موجودة داخل منتجات وأنظمة دون أن يعرف أصحابها.

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

وحسب Palo Alto Networks، هناك أكثر من 22.6 مليون نسخة متصلة بالإنترنت قد تكون معرضة. هذا الرقم لا يعني مواقع مخترقة فعلًا، وإنما حجم ما يمكن أن يتأثر.

دور كلاودفلير: حماية مؤقتة وليست حلًا

فعّلت كلاودفلير قواعد جدار حماية طارئة (WAF) لكل عملائها، حتى أصحاب الخطة المجانية. وقالت إنها رصدت هجمات مبكرة، وإن المهاجمين يغيّرون أنماطهم باستمرار لتجاوز الفلاتر.

لكن المدير التقني للشركة وصف هذه الحماية بأنها حل مؤقت فقط، وطالب أصحاب المواقع بتثبيت التحديث الرسمي. فإن كان موقعك خلف كلاودفلير فهذا يمنحك وقتًا، لكنه لا يغني عن التحديث.

وللدقة: رصد محاولات الاستغلال لا يعني نجاحها، ولم تؤكد المصادر التي راجعتُها حجم الاختراقات الفعلية حتى الآن.

والذكاء الاصطناعي دخل على الخط

وأكثر ما لفت انتباهي في القصة أن الثغرتين اكتُشفتا بمساعدة الذكاء الاصطناعي. حسب Wall Street Journal، كان الباحث Ryan Austin من شركة Calif يراجع كود اللغة باستخدام نموذج من OpenAI، وتم إبلاغ المطورين في أغسطس.

وقالت المؤسسة الراعية للغة إن مطوريها لاحظوا علامات المشكلة الأساسية في إحدى الثغرتين منذ 2024.

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

مستجد اليوم من موقع PHP الرسمي

راجعتُ الموقع الرسمي للغة قبل النشر لأتأكد من آخر التطورات، وهذه خلاصتها بلغة بسيطة:

نصيحة جديدة اليوم (23 أكتوبر 2026): يقترح الفريق إيقاف ميزة صغيرة اسمها “تتبع تقدّم رفع الملفات” مؤقتًا، وذلك بضبط الخيار session.upload_progress.enabled=0. السبب أنها قد تُستغل في إحدى الثغرتين، والحل مؤقت إلى أن يصدر الإصدار القادم. وغالبًا لا يحتاج الموقع العادي إلى هذه الميزة. وذكر الفريق أيضًا مشكلة أخرى منفصلة (CVE-2026-115560) وعدت بشرحها الكامل لاحقًا.
كيف تحدث الثغرتان؟ بتشبيه بسيط: تخيّل أن اللغة موظف استقبال يخدم زوار الموقع واحدًا بعد الآخر. في الثغرة الأولى (CVE-2026-109618) تمتلئ ذاكرته فجأة وهو يجهّز ملف زائر، فيترك الملف ناقصًا ثم يتعامل معه لاحقًا كأنه سليم. وفي الثانية (CVE-2026-109619) يترك على مكتبه أوراق زائر سابق ولا يتخلص منها، فيستعملها الزائر التالي بالخطأ. وفي الحالتين قد يستغل المهاجم هذه الفوضى ليشغّل أوامره على السيرفر.
لماذا mod_php أخطر؟ هي طريقة لتشغيل اللغة داخل خادم Apache مباشرة. وفيها يستطيع زائر مجهول، دون تسجيل دخول، أن يبدأ الهجوم قبل أن يعمل كود موقعك أصلًا. وإن لم تعرف الطريقة التي تستعملها استضافتك فاسألهم، والتحديث ضروري في كل الأحوال.
PHP 8.2: لكل إصدار عمر دعم محدد، وينتهي دعم 8.2 يوم 31 ديسمبر 2026، أي بعد نحو شهرين ونصف، فلن تصله إصلاحات بعدها. الأفضل الانتقال إلى 8.3 أو أحدث.
الإصدارات القديمة (8.1 وما قبلها): لا تصدر لها تحديثات رسمية. وفي مستودع php-src ترقيعات مصغّرة لها، لكنها تناسب المطورين الذين يبنون اللغة بأنفسهم فقط. أما أنت فحلّك الترقية إلى إصدار مدعوم.

إن لم تستطع التحديث فورًا

يقول الفريق إن هذه الإجراءات تخفف الخطر فقط ولا تجعل موقعك آمنًا، فلا تغني عن التحديث:

أوقف ميزة تتبع رفع الملفات بضبط session.upload_progress.enabled=0 من إعدادات PHP في الاستضافة أو من ملف php.ini. وإن كنت على PHP 8.5 فاضبط أيضًا fatal_error_backtraces=0. وبعد التغيير يجب إعادة تشغيل الخدمة، أو اطلب ذلك من الاستضافة.
إجراءات الثغرة الأولى أدق وقد تؤثر على موقعك، فارجع إليها في الإعلان الأمني على php.net أو اطلب من الاستضافة تطبيقها.

للتحقق من حالة هذا الخيار، افتح صفحة المعلومات كما في الخطوات أدناه وابحث عن session.upload_progress.enabled. وفي موقعي وجدتُه Off أصلًا، فلم أحتج إلى أي تعديل. فإن كانت قيمته Off عندك فلا تحتاج إلى فعل شيء، وإن كانت On فاضبطه على 0 من إعدادات الاستضافة أو اطلب ذلك من الدعم.

كيف تحدّث PHP خطوة بخطوة؟

الخبر الجيد أن التحديث أسهل مما تتخيل، وغالبًا لا يستغرق سوى دقائق. والنقطة الأهم: الإصدار لا يُحدَّث من داخل وردبريس، وإنما من لوحة تحكم الاستضافة.

1. اعرف إصدارك الحالي

من لوحة وردبريس: الأدوات ← صحة الموقع ← الحالة، وستجد رقم الإصدار هناك.

2. خذ نسخة احتياطية

انسخ ملفات الموقع وقاعدة البيانات قبل أي شيء. وإن كانت استضافتك تتيح بيئة تجريبية (Staging) فجرّب التحديث عليها أولًا.

3. افتح إعدادات PHP في الاستضافة

Hostinger: لوحة hPanel ← المواقع ← إدارة ← متقدم ← تكوين PHP ← إصدار PHP.
cPanel: ابحث عن Select PHP Version أو MultiPHP Manager.

قد تختلف التسميات قليلًا بين استضافة وأخرى.

4. اختر الفرع المصحح

اختر أحد الفروع المصححة: 8.2 أو 8.3 أو 8.4 أو 8.5، وأنصح بفرع حديث مثل 8.3 أو 8.4 إن كانت إضافاتك تدعمه. الإصدارات المصححة هي 8.5.12 ، 8.4.27 ، 8.3.36 ، 8.2.35.

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

وبما أن دعم الإصدار 8.2 يتوقف في 31 ديسمبر 2026، فاختيار 8.3 أو أحدث أفضل على المدى الطويل.

كيف تتأكد أن التصحيح مطبّق فعلًا؟ رقم الإصدار وحده قد لا يكفي، فبعض الاستضافات تضيف الإصلاح الأمني إلى الإصدار الحالي دون تغيير رقمه (فقد يبقى مثلًا 8.3.35). كما أن صفحة صحة الموقع في وردبريس لا تعرض تاريخ البناء. لذلك افحص تاريخ البناء (Build Date) من الاستضافة:

افتح hPanel ثم المواقع (Websites) واختر موقعك.
من القائمة الجانبية افتح متقدم (Advanced) ← معلومات PHP (PHP Info).
ابحث عن السطر Build Date.
إن كان التاريخ 21 أكتوبر 2026 أو أحدث، فالإصلاح مطبّق على الأرجح. وإن كان أقدم، فاطلب من الدعم الفني تطبيقه.

قد تختلف أسماء القوائم قليلًا، وإن لم تكن متأكدًا فاسأل الدعم الفني صراحة: هل طبّقتم إصلاح CVE-2026-109618 وCVE-2026-109619؟

وقد فعلتُ ذلك مع Hostinger، فأفادني الدعم الفني أن التحديث الأمني طُبّق صباح 23 أكتوبر 2026 على جميع خطط الاستضافة باستثناء VPS، وأن الإصلاح يُدمج داخل الإصدار نفسه، فقد يبقى رقم الإصدار كما هو (مثل 8.3.35) رغم تطبيقه. وإن كنت على VPS فالتحديث مسؤوليتك أنت.

مرحبًا، تم تطبيق التحديث الأمني على موقعك، لكن رقم إصدار PHP قد يبقى كما هو لأن الإصلاح يُدمج داخل الإصدار الذي يعمل عليه موقعك بالفعل — مثل أن يظهر 8.5.11 بدل 8.5.12.
اكتمل التحديث صباح اليوم على جميع خطط الاستضافة باستثناء VPS، لأنك هناك تدير PHP بنفسك. للتأكد من موقعك، افتح PHP Info في hPanel عبر Websites → Dashboard → PHP Info. إذا كان Build Date هو 21 أكتوبر 2026 أو أحدث، فهذا يعني أن الإصلاح مطبّق.
إذا ظهر لك شيء مختلف، أرسل لنا رسالة وسنراجعه معك.

Jenevie متخصصة في الاستضافة

وتحققتُ بنفسي من PHP Info فوجدتُ أن Build Date هو Oct 21 2026، وهو تاريخ صدور الإصلاح، وهذا يتوافق مع تطبيقه على موقعي.

5. إن كنت على 8.1 أو أقدم

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

6. اختبر الموقع

بعد التحديث افتح الصفحة الرئيسية ولوحة التحكم وصفحات الدفع والنماذج. وإن ظهرت شاشة بيضاء أو أخطاء فعطّل الإضافة المتسببة أو ارجع مؤقتًا للإصدار السابق ريثما تُصلحها، ثم حدّث مجددًا.

7. إن كان عندك VPS

على سيرفر أوبونتو مثلًا يمكنك التحديث من الطرفية، ثم التحقق من الإصدار وإعادة تشغيل الخدمة:

sudo apt update && sudo apt upgrade
php -v
sudo systemctl restart php8.3-fpm

غيّر رقم الفرع في اسم الخدمة حسب إصدارك. وتأكد من أن الحزم لدى توزيعتك وصلتها التصحيحات.

8. راقب الموقع بعد التحديث

التحديث يغلق الباب مستقبلًا، لكنه لا يثبت أن أحدًا لم يدخل قبله. تفقّد الملفات الغريبة والمستخدمين الجدد وسجلات الدخول، وأبقِ كلاودفلير مفعّلة كطبقة إضافية فقط.