أصبحنا رسميا بلا PHP. هذا ما علمنا إياه أكتوبر (حتى الآن)

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

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

لماذا يعد الترقيع بعد وقوع الأمر سباقا خاسرا؟

لسنوات كانت النصيحة المعتادة بسيطة: رقع بسرعة وستكون بخير. وكان الاتجاه يسير أصلا ضد تلك النصيحة. فقد قاس فريق Mandiant التابع لـ Google متوسط الوقت بين معرفة الثغرة واستغلالها: 63 يوما في 2018 إلى 2019، و32 يوما خلال 2021 و2022، وخمسة أيام في 2023، كمتوسط بعد استبعاد القيم الشاذة.

خمسة أيام هو رقم عام 2023، قبل أن تصبح أدوات الذكاء الاصطناعي جزءا من العمل البرمجي اليومي. وقد منحنا هذا الشهر قياسا جديدا للسباق، مأخوذا من ثلاث زوايا مختلفة حول الكشف عن PHP2Shell في 21 أكتوبر 2026.

فريق استخبارات التهديدات لدى Amazon رصد محاولة استغلال لـ PHP2Shell في 17 أكتوبر، قبل أربعة أيام من الكشف العلني، ويقول إنه فور رفع الحظر وإصدار الترقيع ظهرت المزيد من أدوات الاستغلال التجريبية في غضون ساعات. ورصدت F5 Labs أول عمليات مسح لـ PHP2Shell قبل أكثر من خمس ساعات من نشر الثغرتين المسجلتين في نظام CVE (نظام الثغرات والتعرضات الشائعة)، وخلال ساعات من الكشف كانت مستشعراتها تسجل آلاف محاولات الاستغلال. أما الرئيس التنفيذي لـ Cloudflare، Matthew Prince، فقال في 22 أكتوبر إن Cloudflare رصدت آلاف المحاولات قبل الإعلان، وعشرات الآلاف في الدقائق الخمس والأربعين التالية له، ومئات الآلاف خلال ساعتين، وملايين بحلول وقت نشره للمنشور. كانت هذه محاولات، لا اختراقات مؤكدة، لكنها تظهر مدى سرعة طرق الأبواب: النافذة تقاس الآن بالدقائق والساعات، وبالنسبة للبعض أغلقت قبل أن يوجد الترقيع أصلا.

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

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

لماذا نزيل البرمجيات بدلا من الترقيع حولها؟

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

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

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

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

كيف يبدو سطح الهجوم الصغير فعليا؟

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

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

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

اخترنا Go لأنظمتنا الأكثر حساسية لأنها تجيب عن مشكلة الاعتماديات على مستوى اللغة نفسها. فلغة Go آمنة من حيث الذاكرة: اللغة تدير الذاكرة نيابة عن المبرمج، ما يستبعد فئة كاملة من الأخطاء مثل فيض المخازن المؤقتة، وتدرج وكالة CISA (وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية) لغة Go ضمن اللغات الآمنة من حيث الذاكرة في وثيقة The Case for Memory Safe Roadmaps. وهذه الفئة أكبر مما تبدو: فمشروع Chromium يجد أن نحو 70% من أخطائه الأمنية الخطيرة هي مشكلات سلامة ذاكرة. ومكتبة Go القياسية تغطي كثيرا مما تحتاجه خدمة ويب، بما في ذلك التشفير، لذا تحتاج خدمة Go إلى حزم خارجية أقل، أي عدد أقل من تلك الوعود المقطوعة من الغرباء. ويؤخذ التشفير بجدية إلى درجة أن وحدة التشفير الخاصة بلغة Go نفسها معتمدة وفق معيار FIPS 140-3 الحكومي الأمريكي، بشهادة CMVP رقم 5247. وحين تظهر ثغرة في النظام البيئي الأوسع، يتولى فريق أمن Go تنسيق قاعدة بيانات للثغرات، وأداته govulncheck تبلغ فقط عن الثغرات الموجودة في الكود الذي يستدعيه البرنامج فعلا، ما يبقي التنبيهات قليلة الضجيج وقابلة للتنفيذ.

ويهم هذا بسبب مدى انتشار منصات PHP وقدمها. تفيد W3Techs بأن PHP تستخدمها 69.2% من جميع المواقع التي تعرف لغة الخادم لديها، مع بقاء 26.6% من مواقع PHP على PHP 7 و7.7% على PHP 5، وفق قياس 27 أكتوبر 2026. ومشروع PHP نفسه يدعم كل فرع إصدار بسنتين من إصلاحات الأخطاء والأمن، ثم سنتين إضافيتين من الإصلاحات الأمنية الحرجة فقط. وقد تجاوز PHP 7 وPHP 5 كل ذلك. حصة كبيرة من الويب تعمل على كود لم يعد صانعوه أنفسهم يحمونه، وهذا هو السباق الخاسر من القسم الأول يدخل طوعا.

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

ما البيانات التي نحتفظ بها عنك؟

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

لا نطلب إلا ما يلزم لتشغيل الحساب. سياسة الخصوصية لدينا (بالإنجليزية) تذكره بوضوح: اسم مستخدم، وعنوان بريد إلكتروني، وكلمة مرور مشفرة، وعنوان IP المستخدم عند التسجيل. المدفوعات تمر عبر معالجي دفع خارجيين، لذا تبقى بيانات بطاقتك لدى متخصصين عملهم كله حمايتها، لا لدينا.

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

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

ماذا يحدث إذا تعطل شيء رغم كل ذلك؟

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

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

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

بأي سرعة تصل الإصلاحات إلى أنظمتنا؟

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

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

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

عند وضعها جنبا إلى جنب، تبدو الأسئلة والمبادئ التي تجيب عنها هكذا:

ماذا يعني كل هذا لك؟

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

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

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