تجربتي مع ثغرات PHP الخطيرة في 22 أكتوبر 2026: فحص السيرفر وتحديث إصدارات PHP وتأمين المواقع

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

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

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

ما قصة ثغرات PHP التي ظهرت في أكتوبر 2026؟

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

CVE-2026-109618: ثغرة مرتبطة بفساد البيانات الداخلية أثناء التعامل مع نفاد الذاكرة.
CVE-2026-109619: ثغرة مرتبطة ببقاء حالة داخلية قديمة بعد تحرير الذاكرة المستخدمة فيها.

تكمن خطورة الثغرتين في إمكانية استغلالهما لتنفيذ تعليمات برمجية عن بُعد دون مصادقة في ظروف معينة. وأوضح فريق PHP أن الخطر لا يقتصر على طريقة واحدة لتشغيل PHP، بل يشمل بيئات متعددة تستقبل طلبات الويب، مثل PHP-FPM وApache مع mod_php وphp-cgi وغيرها.

وأكد التحذير الرسمي ضرورة تثبيت التحديثات الأمنية، موضحًا أن التدابير المؤقتة لا تمثل بديلًا كاملًا عن التحديث.

أولًا: الثغرة CVE-2026-109618

ترتبط هذه الثغرة بطريقة تعامل PHP مع حالات نفاد الذاكرة (Out-of-Memory).

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

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

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

ثانيًا: الثغرة CVE-2026-109619

تتعلق هذه الثغرة ببقاء حالة داخلية مرتبطة بطلب سابق بعد تحرير الذاكرة التي كانت تحتوي عليها.

في بعض ظروف التشغيل، قد يتعامل عامل PHP مع طلب جديد باستخدام بيانات داخلية قديمة قبل إعادة تهيئتها بالشكل الصحيح. ويُعرف أحد الأنماط المرتبطة بهذه المشكلات باسم Use-After-Free، أي استخدام الذاكرة أو البيانات بعد تحريرها.

وقد تؤدي هذه المشكلة إلى فساد الذاكرة، وتتيح في ظروف معينة إمكانية تنفيذ تعليمات برمجية عن بُعد.

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

هل تعني هذه الثغرات أن المواقع تعرضت للاختراق؟

هذا السؤال كان من أهم النقاط التي يجب التعامل معها بهدوء.

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

هناك فرق بين ثلاثة أمور:

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

لذلك لا يصح الجزم بأن جميع المواقع التي تستخدم إصدارًا متأثرًا قد اختُرقت، ولا يصح أيضًا تجاهل التحذير لمجرد أن المواقع ما زالت تعمل.

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

بداية التعامل مع الأزمة: الدخول إلى السيرفر وفحص PHP

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

يمكن تنفيذ الأوامر التالية من جهاز يعمل بنظام Windows باستخدام CMD أو Windows Terminal، بشرط توفر عميل SSH.

الخطوة الأولى: الاتصال بالسيرفر

ssh root@SERVER_IP

يجب استبدال SERVER_IP بعنوان IP الحقيقي للسيرفر.

بعد نجاح الاتصال، ستظهر لك واجهة سطر الأوامر الخاصة بالسيرفر، ويمكنك بدء عمليات الفحص.

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

الخطوة الثانية: معرفة إصدار PHP الافتراضي

نفذت عملية الفحص من خلال الأمر التالي:

php -v

يعرض هذا الأمر إصدار PHP المرتبط بالأمر php في سطر الأوامر.

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

الخطوة الثالثة: فحص إصدار PHP-FPM

إذا كان السيرفر يستخدم PHP-FPM بإصدار 8.1، فيمكن التحقق منه باستخدام:

php-fpm8.1 -v

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

يمكن أيضًا البحث عن عمليات PHP-FPM النشطة باستخدام:

ps aux | grep '[p]hp-fpm'

يساعد هذا الأمر في معرفة العمليات الظاهرة حاليًا، لكنه لا يكفي وحده لتحديد الإصدار المستخدم بواسطة كل موقع. يجب ربط النتائج بإعدادات المواقع ومجموعات PHP-FPM.

الخطوة الرابعة: مراجعة إصدار الحزمة المثبتة والتحديث المتاح

في أنظمة Debian وUbuntu التي تستخدم مدير الحزم APT، يمكن تنفيذ:

apt-cache policy php8.1-common

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

ومن المهم فهم أن رقم الإصدار قد يتضمن لاحقة خاصة بالتوزيعة أو بمزود الحزم. لذلك لا ينبغي مقارنة الرقم الظاهر بصورة سطحية مع رقم PHP الرسمي فقط؛ فقد تتضمن الحزمة إصلاحًا أمنيًا أُعيد دمجه في إصدار خاص بالتوزيعة.

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

مراجعة التحديثات الأمنية قبل تنفيذها

بعد تحديد إصدار PHP، تأتي مرحلة مراجعة التحديثات التي يوفرها مستودع الحزم المستخدم.

يمكن تحديث بيانات المستودعات باستخدام:

apt update

ثم مراجعة سياسة الحزمة مرة أخرى:

apt-cache policy php8.1-common

إذا كان هناك إصدار أحدث متاح، يمكن معاينة التحديثات المرشحة باستخدام:

apt list --upgradable

ولمعرفة ما إذا كانت الحزمة تتضمن تحديثًا أمنيًا محددًا، يمكن مراجعة سجل التغييرات، إذا كان متاحًا ضمن مستودعات النظام:

apt changelog php8.1-common

لا يُفترض أن كل مستودع سيحتوي على سجل يذكر أرقام CVE نفسها حرفيًا. لذلك ينبغي الرجوع أيضًا إلى إشعارات مزود الحزم والتوزيعة، ومقارنة المعلومات مع التحذير الأمني الرسمي.

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

ما إصدارات PHP التي صدرت لمعالجة الثغرتين؟

أعلن فريق PHP في 21 أكتوبر 2026 عن الإصدارات الأمنية التالية لمعالجة الثغرتين:

فرع PHP	الإصدار الأمني
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

هذه هي الإصدارات التي أعلنها المشروع رسميًا ضمن التحديث الأمني المذكور.

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

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

يمكن مراجعة الإعلانات والإصدارات من خلال الموقع الرسمي لـ PHP وصفحة تنزيلات PHP.

تحديث PHP على السيرفر: ما الخطوات الصحيحة؟

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

الأفضل تنفيذ التحديث بطريقة منظمة.

1. أخذ نسخة احتياطية

قبل أي تغيير، يجب التأكد من وجود نسخة احتياطية حديثة تشمل:

ملفات المواقع.
قواعد البيانات.
ملفات إعدادات PHP والخادم.
إعدادات المواقع ومجموعات PHP-FPM.
أي إعدادات خاصة أو مهام مجدولة تعتمد على إصدار PHP معين.

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

2. التأكد من مصدر الحزم

يجب معرفة مصدر تثبيت PHP، وهل يعتمد السيرفر على مستودعات التوزيعة أم مستودع إضافي أم حزم يوفرها مزود الاستضافة.

لا ينبغي إضافة مستودعات غير موثوقة أو تثبيت حزم من مصادر عشوائية لمجرد الحصول على رقم إصدار أحدث.

3. مراجعة الحزم المراد تحديثها

يمكن استخدام:

apt list --upgradable

ولمعاينة التغييرات التي قد ينفذها APT قبل تثبيت تحديثات الحزم، يمكن استخدام:

apt-get -s upgrade

هذا الأمر يعرض محاكاة لعملية الترقية ولا ينفذها فعليًا.

بعد مراجعة النتيجة والتأكد من أن التحديثات مناسبة، يمكن تثبيت الحزم الأمنية بالطريقة التي يدعمها نظام التشغيل ومصدر الحزم. ويجب الانتباه إلى أن أسماء الحزم تختلف بحسب الإصدار وطريقة التثبيت، فلا يكفي تحديث حزمة php-common وحدها إذا كانت مكونات PHP الأخرى المستخدمة ما زالت قديمة.

4. التأكد من إعادة تشغيل الخدمات عند الحاجة

بعد تحديث PHP، يجب التأكد من أن عمليات PHP-FPM تستخدم الملفات الجديدة، وأن الخدمات أعيد تشغيلها أو تحميلها حسب متطلبات الحزم.

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

systemctl --type=service --state=running | grep -i php

بعد ذلك تُراجع حالة الخدمة المناسبة وفق اسمها الحقيقي، مثل:

systemctl status php8.1-fpm

هذا المثال ينطبق فقط إذا كان اسم الخدمة في السيرفر هو php8.1-fpm. قد يختلف الاسم في بيئات أخرى.

تحديث إصدارات PHP المستخدمة بواسطة المواقع

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

قد يستخدم السيرفر إصدارًا في سطر الأوامر، بينما يعمل أحد المواقع على PHP-FPM بإصدار آخر. وقد تكون هناك عدة إصدارات مثبتة لخدمة مواقع مختلفة.

لذلك يجب إعداد قائمة بالمواقع والإصدار الذي يستخدمه كل موقع، ثم مراجعة كل إصدار على حدة.

على سبيل المثال:

الموقع	إصدار PHP الحالي	الإجراء المطلوب
الموقع الأول	يُحدد بعد الفحص	التحقق من التحديث الأمني
الموقع الثاني	يُحدد بعد الفحص	مراجعة التوافق ثم التحديث
الموقع الثالث	يُحدد بعد الفحص	التأكد من إصدار PHP-FPM الفعلي

هذه القائمة نموذج لتنظيم العمل، وليست تقريرًا عن إصدارات مواقعي الفعلية.

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

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

كيف أتحقق من نجاح تحديث PHP؟

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

التحقق من إصدار PHP

php -v

ثم التحقق من إصدار PHP-FPM المناسب، مثل:

php-fpm8.1 -v

مع تعديل الأمر بحسب الإصدار المستخدم.

التحقق من الحزم المثبتة

apt-cache policy php8.1-common

يجب التأكد من أن الإصدار المثبت يتضمن الإصلاح الأمني المطلوب، سواء من خلال الإصدار الرسمي أو من خلال تحديث معتمد من مزود التوزيعة.

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

يجب فتح كل موقع والتأكد من:

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

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

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

هل تحديث PHP وحده يكفي لتأمين السيرفر؟

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

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

ومن الإجراءات المهمة أيضًا:

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

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

ولا يجوز اعتبار عدم ظهور أخطاء في السجلات دليلًا قاطعًا على عدم حدوث اختراق.

هل توجد حلول مؤقتة إذا تعذر التحديث الفوري؟

أوضح فريق PHP أن التحديث هو الحل الكامل، وأن التدابير المؤقتة لا تجعل النظام آمنًا بصورة مضمونة.

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

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

ولا أنصح بنسخ إعدادات أمنية عشوائية من الإنترنت إلى ملف PHP الرئيسي؛ فقد تؤثر في مواقع متعددة، أو تتعارض مع إعدادات التطبيقات، أو لا تعالج مسار الثغرة الموجود بالفعل.

ماذا عن السيرفر الذي يستخدم PHP 8.1؟

في فحص سابق لبيئة السيرفر، ظهر لدي ناتج يشير إلى أن الحزمة php8.1-common كانت مثبتة بالإصدار:

8.1.34-1+clp-noble

وظهر الإصدار المرشح من مستودع الحزم بالشكل التالي:

8.1.34-1

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

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

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

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

الخلاصة: ماذا تعلمت من أزمة ثغرات PHP؟

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

وأهم الدروس التي خرجت بها هي:

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

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