بقلم: صهيب الجراح | Principal Cyber Security Engineer

في 21 أكتوبر 2026، أعلن فريق تطوير PHP عن إصدار تحديثات أمنية عاجلة لمعالجة ثغرتين حرجتين في محرك اللغة نفسه، تحملان المعرّفين CVE-2026-109618 وCVE-2026-109619، وقد تتيحان في ظروف معينة تنفيذ تعليمات برمجية عن بُعد دون الحاجة إلى تسجيل الدخول.

تكمن خطورة هذا الاكتشاف في أن الثغرات لا ترتبط بالضرورة بأخطاء داخل التطبيقات، مثل حقن SQL أو رفع الملفات غير الآمن، وإنما بمكونات داخلية مسؤولة عن إدارة الذاكرة ومعالجة طلبات الويب في PHP.

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

أثارت هذه الثغرات اهتمام الجهات الأمنية، ومنها المركز الوطني للأمن السيبراني في المملكة المتحدة (NCSC) وفريق الاستجابة للحوادث في الاتحاد الأوروبي (CERT-EU)، بسبب احتمال تأثيرها في الخوادم والتطبيقات التي تعتمد على PHP.

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

أولاً: لماذا تمثل ثغرات PHP تهديداً واسع النطاق؟

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

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

قد تُستخدم PHP ضمن معماريات مختلفة، من أبرزها:

• PHP-FPM مع Nginx.

• Apache مع mod_php.

• PHP-CGI.

• LiteSpeed.

• FrankenPHP.

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

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

النقطة الأهم: استخدام Laravel أو WordPress أو نظام PHP مخصص لا يزيل خطر وجود ثغرة داخل محرك PHP الذي يشغّل التطبيق.

ثانياً: الثغرة CVE-2026-109618 — فساد الذاكرة عند نفاد الموارد

ترتبط الثغرة الأولى بآلية تعامل PHP مع حالات نفاد الذاكرة أثناء معالجة الطلبات.

المعرّف: CVE-2026-109618
التصنيف التقني: Memory Corruption during Out-of-Memory Handling
درجة الخطورة المعلنة: 9.2 وفق CVSS v4.0

كيف تحدث المشكلة تقنياً؟

تحتوي PHP على آليات لإدارة الذاكرة وتحديد الموارد التي يستطيع الطلب الواحد استخدامها.

ومن الإعدادات المعروفة:

memory_limit

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

عندما تتجاوز العملية حدود الذاكرة المسموحة، يحاول المحرك إيقاف التنفيذ والتعامل مع حالة نفاد الذاكرة، المعروفة باسم Out-of-Memory أو OOM.

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

وعند بدء عملية تنظيف الموارد، قد يتعامل المحرك مع بيانات غير مهيأة كما لو كانت بيانات صحيحة.

يمكن أن يؤدي ذلك إلى عمليات غير آمنة على الذاكرة، وفي ظروف معينة إلى فساد الذاكرة أو تنفيذ تعليمات برمجية غير مصرح بها.

لماذا هذه المشكلة خطيرة؟

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

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

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

ثالثاً: الثغرة CVE-2026-109619 — استخدام حالة داخلية بعد تحرير الذاكرة

تتعلق الثغرة الثانية بمشكلة مختلفة في إدارة الحالة الداخلية للطلبات.

المعرّف: CVE-2026-109619
التصنيف التقني: Stale Global State / Use-After-Free
درجة الخطورة المعلنة: 9.2 وفق CVSS v4.0

ما المقصود بمشكلة Use-After-Free؟

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

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

يُعرف هذا النمط من الأخطاء باسم Use-After-Free.

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

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

ما خطورة ذلك؟

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

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

تعتمد إمكانية الاستغلال الفعلية على ظروف تشغيل الخادم وطريقة إدارة العمليات والذاكرة.

ولا يعني اكتشاف ثغرة Use-After-Free أن جميع الخوادم يمكن اختراقها بالطريقة نفسها أو بالسهولة نفسها.

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

رابعاً: لماذا تُعد هذه الثغرات مختلفة عن SQL Injection وXSS؟

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

في هجمات SQL Injection، يستغل المهاجم غالباً خللاً في طريقة بناء التطبيق للاستعلامات المرسلة إلى قاعدة البيانات.

أما في Cross-Site Scripting أو XSS، فيستغل المهاجم ضعف معالجة المحتوى الذي يُعرض داخل متصفح المستخدم.

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

أما الثغرات التي نناقشها هنا، فمصدرها مكونات داخل محرك PHP نفسه.

وهذا اختلاف جوهري.

فحتى لو استخدم المطور الاستعلامات المجهزة (Prepared Statements)، وطبّق التحقق من المدخلات، وعالج المخرجات بطريقة آمنة، فإن هذه الضوابط لا تصلح أخطاء إدارة الذاكرة في محرك PHP.

أمن التطبيق وأمن بيئة التشغيل مستويان مختلفان من الحماية، وكلاهما ضروري.

خامساً: هل تؤثر الثغرات في Nginx وApache وPHP-FPM؟

توضح النشرات الأمنية الرسمية أن التطبيقات التي تستقبل طلبات ويب عبر PHP قد تتأثر باستخدام عدة أساليب تشغيل.

ومن المهم هنا التفريق بين خادم الويب ومحرك PHP.

بيئة Nginx مع PHP-FPM

في هذه المعمارية، يستقبل Nginx الطلبات ثم يمرر طلبات PHP إلى خدمة PHP-FPM باستخدام FastCGI.

إذا كانت نسخة PHP-FPM متأثرة، فإن استخدام Nginx لا يعالج الثغرة الموجودة في محرك PHP.

ويمكن أن تتأثر الخدمة إذا توافرت شروط الاستغلال اللازمة.

بيئة Apache مع mod_php

تُشغّل هذه المعمارية PHP ضمن عمليات Apache باستخدام وحدة mod_php.

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

البيئات الأخرى

يجب أيضاً مراجعة خدمات php-cgi وLiteSpeed وFrankenPHP، وكذلك التطبيقات والأجهزة أو المنتجات التي تتضمن PHP ضمن مكوناتها الداخلية.

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

سادساً: ما إصدارات PHP المتأثرة وما الإصدارات المصححة؟

أصدر فريق PHP في 21 أكتوبر 2026 نسخاً أمنية لمعالجة الثغرتين الرئيسيتين.

الإصدارات المصححة هي:

• PHP 8.2.35 لفرع PHP 8.2.

• PHP 8.3.36 لفرع PHP 8.3.

• PHP 8.4.27 لفرع PHP 8.4.

• PHP 8.5.12 لفرع PHP 8.5.

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

أما PHP 8.1 والإصدارات الأقدم، فقد خرجت من الدعم الرسمي لمشروع PHP، ولهذا يُوصى بالانتقال إلى فرع مدعوم.

وقد توفر بعض الجهات تصحيحات أمنية منقولة إلى إصدارات أقدم (Backported Fixes)، لكن لا ينبغي افتراض وجودها دون الرجوع إلى نشرات المورّد.

تنبيه مهم لمسؤولي الخوادم

الأمر:

php -v

يعرض عادة إصدار PHP المستخدم عبر سطر الأوامر (CLI)، ولا يثبت بالضرورة أن الموقع الإلكتروني يستخدم الإصدار نفسه.

ففي الخوادم متعددة الإصدارات، قد يستخدم الموقع PHP 8.2 عبر PHP-FPM، بينما يشير أمر PHP الافتراضي في SSH إلى PHP 8.4.

لهذا ينبغي فحص إعدادات الخادم والـPHP-FPM Pool المسؤول عن الموقع، بالإضافة إلى الحزم المثبتة وإصداراتها.

سابعاً: تحديث أمني إضافي في 23 أكتوبر 2026

بعد إصدار التصحيحات الرئيسية، نشر فريق PHP في 23 أكتوبر 2026 تنبيهاً إضافياً يتعلق بثغرة تحمل المعرّف:

CVE-2026-115560

ترتبط هذه المشكلة بحالة غير معتادة في التعامل مع إعدادات الجلسات وميزة Session Upload Progress.

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

ولهذا لا تُعد جميع تطبيقات PHP معرضة لهذا السيناريو بالدرجة نفسها.

ومن المهم التنبيه إلى أن تحديثات 21 أكتوبر لم تتضمن إصلاحاً لهذه المشكلة الثالثة.

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

ويمكن ضبط الإعداد التالي:

session.upload_progress.enabled=0

لكن يجب التحقق من اعتماد التطبيق على هذه الميزة قبل تغيير الإعداد، ثم إعادة تشغيل عمليات PHP المعنية حتى يُطبّق التغيير بصورة صحيحة.

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

ثامناً: كيف يعرف مدير النظام أن خادمه معرض للخطر؟

يبدأ التقييم الأمني بحصر جميع مواقع الويب والتطبيقات والخدمات التي تستخدم PHP.

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

في بيئات Linux يمكن الاستفادة من أوامر مثل:

php -v

لمعرفة إصدار سطر الأوامر، و:

apt-cache policy php8.4-fpm

لمعرفة النسخة المثبتة والمتاحة من مدير الحزم في الأنظمة المعتمدة على APT.

لكن التقييم يجب أن يشمل أيضاً خدمات PHP-FPM العاملة وإعدادات خادم الويب وحزم المورّد.

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

ولهذا تُعد إدارة الأصول البرمجية والإصدارات جزءاً أساسياً من إدارة الثغرات الأمنية (Vulnerability Management).

تاسعاً: هل يكفي تحديث PHP لإنهاء الخطر؟

بالنسبة إلى الثغرتين CVE-2026-109618 وCVE-2026-109619، يمثل الانتقال إلى إصدار يتضمن التصحيحات الرسمية المعتمدة إجراء المعالجة الأساسي.

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

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

ولا بد من التمييز بين إصلاح الثغرة ومنع احتمال وجود اختراق سابق.

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

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

عاشراً: إجراءات الحماية الموصى بها للمؤسسات

1. تحديث بيئة PHP بصورة عاجلة

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

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

2. مراجعة جميع إصدارات PHP المثبتة

وجود نسخة PHP حديثة على الخادم لا يعني أن جميع المواقع تستخدمها.

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

3. تقليل سطح الهجوم

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

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

4. مراجعة إعدادات رفع الملفات والجلسات

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

وينبغي مراجعة إعدادات حجم الطلبات والملفات وميزة Session Upload Progress وفق توصيات فريق PHP والمورّد.

5. تطبيق مبدأ أقل الصلاحيات

يُفضّل تشغيل مواقع الويب ضمن حسابات وخدمات محدودة الصلاحيات، مع عزل الملفات الحساسة وقواعد البيانات عن الحسابات غير المرتبطة بها.

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

6. مراقبة السجلات الأمنية

يجب متابعة سجلات Nginx أو Apache، وسجلات PHP-FPM، وسجلات المصادقة والعمليات، بحثاً عن نشاط غير معتاد أو مؤشرات استغلال.

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

7. اختبار التحديثات قبل تعميمها

يُنصح بأخذ نسخ احتياطية واختبار التوافق، ثم تنفيذ التحديثات وفق خطة واضحة تتضمن التحقق من الخدمات وآلية الاستعادة عند الحاجة.

وفي البيئات عالية الحساسية، ينبغي التنسيق بين فرق البنية التحتية والتطوير والأمن السيبراني لضمان سرعة المعالجة وتقليل الانقطاع.

الحادي عشر: ما دور Zero Trust وDefense in Depth في مواجهة هذه المخاطر؟

توضح هذه الثغرات أهمية عدم الاعتماد على أمن الكود وحده لتوفير حماية شاملة.

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

ولهذا يجب بناء منظومة دفاع متعددة الطبقات (Defense in Depth)، تشمل عزل التطبيقات، وتقييد الصلاحيات، وحماية الشبكات، ومراقبة الأنشطة، وإدارة الهوية، وإدارة التصحيحات.

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

لكن من الضروري التأكيد أن Zero Trust ليس بديلاً عن التحديثات الأمنية، بل إطار يساعد على تقليل أثر الاختراق المحتمل.

الثاني عشر: الدروس الأمنية المستفادة من ثغرات PHP في أكتوبر 2026

تكشف هذه الحوادث عن عدة دروس مهمة لفرق الأمن السيبراني والبنية التحتية:

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

ثانياً، أن الاعتماد على أطر العمل الحديثة أو ممارسات البرمجة الآمنة لا يعفي المؤسسة من مسؤولية تحديث بيئات التشغيل.

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

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

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

الخلاصة: قد يكون التطبيق آمناً بينما بيئة تشغيله معرضة للخطر

تُبرز ثغرات PHP المكتشفة في أكتوبر 2026 حقيقة أساسية في هندسة الأمن السيبراني: أمن التطبيق لا ينفصل عن أمن المنصة التي يعمل عليها.

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

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

إن أمن الأنظمة لا يُقاس فقط بمدى خلو التطبيقات من الأخطاء، بل بقدرة المؤسسة على إدارة المخاطر الأمنية عبر جميع طبقات بنيتها التقنية.

المراجع التقنية

1. PHP Official Security Advisory — 21 October 2026

2. PHP — Session Upload Progress Advisory, 23 October 2026

3. CERT-EU — Critical Vulnerabilities in PHP, Advisory 2026-018

4. UK NCSC — Critical Security Issue Affecting PHP

5. Canadian Centre for Cyber Security — PHP Vulnerabilities Alert AL26-026

المهندس صهيب الجراح
Principal Cyber Security Engineer
https://suhibjarrah.com

آخر مراجعة تقنية للمقال: 24 أكتوبر 2026.