الثغرات الأمنية في PHP: كيف يمكن لخلل في الذاكرة أن يهدد المواقع والخوادم؟

مقدمة: عندما تصبح لغة البرمجة نفسها نقطة ضعف

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

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

• CVE-2026-109618

• CVE-2026-109619

صُنّفت الثغرتان بدرجة خطورة حرجة، وبلغ تقييمهما CVSS 4.0 مقدار 9.2 من 10. وتكمن خطورتهما في إمكانية استغلالهما، في ظروف معينة، لتنفيذ تعليمات برمجية عن بُعد دون الحاجة إلى امتلاك حساب أو تسجيل الدخول إلى الموقع المستهدف.

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

أولًا: ما لغة PHP؟ ولماذا تهم أصحاب الأعمال؟

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

تُستخدم PHP في بناء مواقع الشركات والمتاجر الإلكترونية وأنظمة الحجز والمحتوى ولوحات التحكم والتطبيقات السحابية. كما تعتمد عليها أنظمة شائعة مثل WordPress وDrupal وJoomla، إلى جانب عدد كبير من التطبيقات المطورة خصيصًا للشركات.

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

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

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

ثانيًا: ما المقصود بالثغرة الأمنية؟

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

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

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

ما معنى إدارة الذاكرة؟

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

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

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

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

ثالثًا: كيف تعمل الثغرتان من الناحية التقنية؟

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

1. الثغرة CVE-2026-109618

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

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

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

لماذا يمثل ذلك خطرًا؟

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

2. الثغرة CVE-2026-109619

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

يُعرف هذا النوع من الأخطاء في أمن البرمجيات باسم Use-After-Free، أي استخدام الذاكرة بعد تحريرها.

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

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

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

لماذا كانت الثغرتان خطيرتين؟

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

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

رابعًا: كيف يمكن أن يستغل المهاجم هذه الثغرات؟

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

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

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

1. كشف بيانات من الذاكرة: الحصول على أجزاء من البيانات التي يمكن لعملية PHP الوصول إليها.

2. إفساد الذاكرة: جعل البرنامج يتعامل مع بيانات أو مؤشرات غير صحيحة.

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

4. تعطيل الخدمة: قد تتسبب الطلبات التي تؤدي إلى أخطاء قاتلة أو استهلاك موارد غير طبيعي في انهيار بعض العمليات أو زيادة أخطاء الخادم.

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

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

خامسًا: لماذا لا يكفي أن يكون الموقع مبنيًا بصورة سليمة؟

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

يمكن تشبيه الأمر بوجود باب آمن داخل مبنى، بينما توجد مشكلة في نظام القفل الرئيسي للمبنى. جودة الباب لا تعالج الخلل الموجود في النظام الذي يديره.

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

سادسًا: هل جميع المواقع معرضة للخطر؟

ليس من الدقيق القول إن كل موقع على الإنترنت معرض بالطريقة نفسها أو أن كل خادم يمكن اختراقه تلقائيًا.

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

تضمنت الإصدارات التي أُعلن عنها بوصفها إصدارات إصلاح أولى:

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

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

سابعًا: ما الأضرار المحتملة على الشركات وأصحاب المواقع؟

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

• تسريب البيانات: مثل بيانات العملاء أو معلومات الطلبات أو بيانات الاتصال الموجودة في ذاكرة العملية أو ملفات التطبيق.

• اختراق ملفات الموقع: تعديل الصفحات أو إدخال شيفرات ضارة أو إعادة توجيه الزوار.

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

• تعطيل الأعمال: توقف الموقع أو بطء الخدمة أو تعذر الوصول إلى لوحة التحكم.

• المخاطر المالية والتشغيلية: خسارة المبيعات، وتكاليف التحقيق والاستعادة، وتعطل الخدمات التي تعتمد عليها الشركة.

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

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

ثامنًا: هل ساعد الذكاء الاصطناعي في اكتشاف الثغرات؟

بحسب تقرير Wiz Research، استخدم الباحثون أدوات ذكاء اصطناعي متعددة خلال عملية اكتشاف الثغرات وتحليلها وتطوير إثباتات الاستغلال والتحقق من الإصلاحات. وذكر التقرير أدوات منها Wiz Atlas وGemini 4 Argon وGPT-5.6 Sol، مع إسناد مساهمة مهمة إلى Gemini 4 Argon في مراحل البحث.

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

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

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

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

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

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

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

عاشرًا: ما الذي ينبغي على صاحب الموقع فعله الآن؟

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

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

2. تحقق من التحديث الأمني وتأكد من تثبيت إصدار مصحح ومدعوم.

3. لا تفترض أن تحديث موقع واحد يحدّث بقية المواقع الموجودة على الخادم نفسه.

4. حدّث أنظمة إدارة المحتوى والإضافات والقوالب وفق تعليمات مورديها.

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

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

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

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

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

لذلك الأمن يبدأ من تحديث المكونات الأساسية

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

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

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