PHP2Shell: ثغرات PHP الخطيرة وكيف تحمي موقعك أو نظامك الإلكتروني

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

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

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

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

ما الذي نعرفه عن ثغرتي PHP2Shell؟

 الثغرتان تحمل المعرّفين CVE-2026-109618 وCVE-2026-109619 كما ذكرنا، وقد صُنفت كل منهما بدرجة خطورة تبلغ 9.2 من 10 وفق مقياس CVSS 4.0.

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

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

كيف بدأت القصة؟

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

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

كيف تعمل الثغرتان؟

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

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

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

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

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

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

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

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

لماذا تمثل الثغرتان خطرا على المواقع أو الأنظمة؟

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

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

وتشمل بيئات التشغيل المعنية PHP-FPM ، Apache مع mod_php ، php-cgi ، FrankenPHP ، LiteSpeed.

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

ما هي إصدارات PHP التي تتضمن الإصلاحات؟

أعلن فريق PHP عن الإصدارات التالية لمعالجة الثغرتين الرئيسيتين:

• PHP 8.5.12

• PHP 8.4.27

• PHP 8.3.36

• PHP 8.2.35

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

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

من الأفضل التخطيط للانتقال إلى إصدار مدعوم، مع اختبار توافق التطبيق قبل الترقية.

كيف تحمي موقعك من هذه الثغرات؟

أولا: تحقق من إصدار PHP الفعلي

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

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

ثانيا: ثبّت التحديث الأمني المناسب

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

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

ثالثا: اتخذ إجراءات مؤقتة إذا تعذر التحديث

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

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

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

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

رابعا: راجع سجلات الخادم

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

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

عدم العثور على مؤشرات واضحة في السجلات لا يثبت وحده أن النظام لم يتعرض للاستغلال.

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

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

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

سادسا: تعامل بجدية مع أي اشتباه في الاختراق

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

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

هل PHP وحدها معرضة للثغرات الأمنية؟

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

• المستوى الأول: هو محرك اللغة أو بيئة التشغيل. ففي حالة PHP2Shell، تتعلق المشكلة بإدارة الذاكرة والحالة الداخلية داخل محرك PHP.

• المستوى الثاني: هو المكتبات الخارجية. فقد تكون اللغة نفسها سليمة في سياق معين، بينما تحتوي مكتبة يعتمد عليها التطبيق على ثغرة. ومن الأمثلة المعروفة ثغرة Log4Shell في مكتبة Log4j المستخدمة مع Java، وثغرة Heartbleed في مكتبة OpenSSL.

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

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

هل تساعد اللغات الآمنة للذاكرة في تقليل المخاطر؟

يمكن للغات مثل Rust أن تقلل فئات مهمة من أخطاء إدارة الذاكرة التي تظهر في البرامج المكتوبة بلغة C أو C++، بفضل قواعد السلامة التي يفرضها المترجم.

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

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

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

كيف يغير الذكاء الاصطناعي مستقبل الأمن السيبراني؟

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

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

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

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

الخلاصة

توضح ثغرتا PHP2Shell أن جودة كود التطبيق لا تكفي وحدها لحماية الموقع. فمحرك اللغة وبيئة التشغيل والمكتبات والإعدادات جميعها أجزاء أساسية من منظومة الأمان.

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

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

إذا كنت بحاجة إلى مراجعة تقنية لموقعك أو التحقق من إعدادات الأمان والتحديثات، يمكنك التواصل مع فريق Alpha4Tech عبر موقعنا:

المصادر والمراجع

1. إعلانات PHP الأمنية الرسمية لعام 2026:

[https://www.php.net/archive/2026.php](https://www.php.net/archive/2026.php)

2. تحليل watchTowr لثغرتي PHP2Shell:
   [https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/](https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/)
3. المركز الكندي للأمن السيبراني، التنبيه الأمني بشأن ثغرات PHP:
   [https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619](https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619)
4. NHS England Digital، تفاصيل الثغرات والتوصيات:
   [https://digital.nhs.uk/cyber-alerts/2026/cc-4875/cc-4875](https://digital.nhs.uk/cyber-alerts/2026/cc-4875/cc-4875)

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