تنبيه هام بشأن لغة PHP: ما الذي يعنيه "php2shell" لأنظمة الأمان المتصلة؟

في 21 أكتوبر 2026، صدر تحذيرٌ يُذكّر بأنّ أنظمة الأمان قد تكون متينةً ماديًا، ومع ذلك تظلّ عرضةً للاختراق التشغيلي عبر نافذة المتصفح. في ذلك التاريخ، أصدرت وكالة الأمن السيبراني للاتحاد الأوروبي (ENISA)، والمديرية العامة للاتصالات والشبكات التابعة للمفوضية الأوروبية (DG CNECT)، وفريق الاستجابة لحوادث أمن الحاسوب التابع للاتحاد الأوروبي (CERT-EU)، ومركز يوروبول EC3، وشبكة فرق الاستجابة لحوادث أمن الحاسوب التابعة للاتحاد الأوروبي (EU CSIRTs Network) تحذيرًا مشتركًا بشأن ثغرتين أمنيتين خطيرتين في لغة PHP: CVE-2026-109618 وCVE-2026-109619. ويُثير هذا الأمر قلقًا بالغًا، إذ تُشير التحذيرات إلى احتمال تعرّض الخوادم المُعرّضة للخطر لتنفيذ تعليمات برمجية عن بُعد دون مصادقة.

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

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

تنبيه أوروبي منسق، وليس مجرد ملاحظة تصحيح عادية

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

في اليوم نفسه، أصدر مشروع PHP الإصدارات 8.5.12 و8.4.27 و8.3.36 و8.2.35. ويشير إشعار الأمان الخاص به إلى أن جميع تطبيقات PHP التي تستقبل طلبات الويب معرضة للخطر، بما في ذلك التطبيقات التي تستخدم PHP-FPM، وApache مع mod_php، وphp-cgi، وFrankenPHP، وLiteSpeed. وهذا الأمر بالغ الأهمية، لأن عبارة "نحن لا ندير موقعًا إلكترونيًا يعمل بلغة PHP" لا تُعدّ ضمانًا كافيًا إذا كانت PHP جزءًا من تطبيق المورّد، أو بيئة الاستضافة، أو برنامج الجهاز.

صنّف مركز الاستجابة للطوارئ الحاسوبية في الاتحاد الأوروبي (CERT-EU) كلاً من CVE-2026-109618 وCVE-2026-109619 عند مستوى خطورة CVSS 9.2 في التقرير الأمني ​​رقم 2026-018. كما أفاد المركز بأن نماذج أولية لإثبات المفهوم قد بدأت بالانتشار علنًا، مما يزيد من احتمالية محاولة استغلالها. وهذا تمييز هام: فالنقاش التقني العلني ووجود ثغرة أمنية حرجة لا يثبتان بالضرورة اختراق مؤسسة معينة. ولكنهما يعنيان أن التأخير يجب أن يُعامل كقرار يتعلق بمخاطرة جوهرية وليس مجرد تراكم أعمال صيانة روتينية.

سطح الهجوم الذي تم تجاهله: طبقة إدارة الأمن

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

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

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

قم بحصر الواجهات، وليس فقط نقاط النهاية

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

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

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

أصبح الاعتماد على الموردين الآن إجراءً للتحكم الأمني

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

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

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

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

يستحق الظهور على الإنترنت الأولوية

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

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

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

إن التخفيف ليس خط النهاية

قد يميل البعض إلى اعتبار تغيير مؤقت في الإعدادات بمثابة حل نهائي للمشكلة. إلا أن كلاً من مشروع PHP وفريق الاستجابة لحوادث أمن الحاسوب في الاتحاد الأوروبي (CERT-EU) يحذران من هذا التفسير. فالإجراءات المذكورة في الإرشادات الفنية - مثل تغيير قيمة memory_limit، وتقييد أحجام طلبات POST، وتعطيل session.upload_progress ، أو عزل التطبيقات المعرضة للخطر - قد تقلل من بعض مسارات الهجوم، لكنها لا تجعل النظام المتأثر آمناً. التحديث هو الإجراء الذي يُصلح الثغرات الأمنية بشكل كامل.

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

خمسة أسئلة تحوّل الإنذار السيبراني إلى إجراء عملياتي

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

1. ما هي خدمات إدارة الأمن المتاحة للجمهور؟ تشمل هذه الخدمات البوابات الإلكترونية، وصفحات العرض، ووحدات التحكم في الصيانة، وقنوات دعم الموردين.
2. ما هي التطبيقات أو الأجهزة أو المنصات المُدارة التي قد تتضمن لغة PHP؟ اسأل الموردين مباشرةً بدلاً من الاعتماد على واجهة المنتج الظاهرة.
3. من قام بتأكيد حالة التحديث؟ سجّل رقم الإصدار، أو مرجعًا استشاريًا، أو تذكرة خدمة، أو تأكيدًا كتابيًا - وليس مجرد تأكيد غامض.
4. هل لا تزال أي من المكونات التي انتهى عمرها الافتراضي تدعم سير عمل أمني؟ قد يستمر النظام في التقاط اللقطات رغم افتقاره إلى مسار تحديث طارئ فعال.
5. هل يمكن عزل واجهة مكشوفة بأمان في حال تأخر الإصلاح؟ حدد التأثير التشغيلي قبل أن يُجبر التنبيه العاجل على اتخاذ القرار.

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

الدرس الأوسع: صيانة الأمن السيبراني هي أمن تشغيلي

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

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

الرد الأوروبي، الموثق في مجموعة الاستشارات CNW-2026-04 التابعة لشبكة فرق الاستجابة لحوادث أمن الحاسوب (CSIRTs))، أن هذه ليست مشكلة معزولة تخص موردًا واحدًا، بل هي مشكلة إدارة حوادث منسقة على مستوى الدول الأعضاء. بالنسبة للمؤسسات المسؤولة عن أنظمة الأمن المتصلة، فإن المهمة العاجلة بسيطة ولكنها بالغة الأهمية: تحديد طبقة الويب، وتحديد مالكها، والتحقق من الإصلاح، والتأكد من عدم اعتبار الحلول المؤقتة حلاً نهائيًا.

مصادر

• وكالة الأمن السيبراني للاتحاد الأوروبي (ENISA) - بيان مشترك بشأن ثغرات PHP الحرجة
• PHP - إشعارات أمنية وإصدارات
• CERT-EU — إشعار أمني 2026-018
• المركز الوطني للأمن السيبراني في هولندا (NCSC-NL) - مستودع معلومات تشغيلية لـ php2shell
• شبكة ENISA / CSIRTs — CNW-2026-04