التحديثات الأمنية ضرورية، لكنها لا تكفي

إن كنت تعمل في الأمن السيبراني، فالأرجح أن أكتوبر ٢٠٢٦ مرّ عليك كأنه شهرٌ بلا عطلة.

تحديثات مايكروسوفت الشهرية (Patch Tuesday) وحدها عالجت أكثر من ١٤٠٠ ثغرة، وهو أكبر إصدار رأيناه، حتى إن أهل الأمن لم يتفقوا على عددها بالضبط. وبدأ المهاجمون يستغلّون ثغرةً في SonicWall تقييمها ١٠٫٠ بعد أيام قليلة من الإعلان عنها، وسدّت GitLab ثغرةً من أعلى درجات الخطورة، وأفسد هجومٌ سيبراني على أنظمة التبريد في متاجر فرنسية بضائع بالملايين في ليلة واحدة.

ثم جاء الأسبوع الذي ما زال الجميع يتحدثون عنه. في ٢٠ أكتوبر حذّر فريق PHP من ثغرتين خطيرتين، صار اسمهما PHP2Shell، تتيحان للمهاجم أن يشغّل شيفرته على خادم الويب دون أن يسجّل دخوله أصلًا. تسرّبت التفاصيل قبل أن يجهز الإصلاح، ورصدت Cloudflare هجماتٍ مبكرة في اليوم نفسه الذي صدرت فيه التحديثات، وبعد يومين ظهرت ثغرة ثالثة لم تشملها تلك التحديثات. ولم تكن PHP وحدها؛ ففي اليوم نفسه أصلحت Node.js عشر ثغرات، وكانت NGINX قد أصدرت خمسة إصلاحات قبل أسبوع، وأصلحت GitLab أربعًا وعشرين ثغرة في إصدار واحد يوم ١٣ أكتوبر، وأصدرت Go تحديثًا خاصًا بها. في نحو أسبوعين، احتاجت كل طبقة تقريبًا من طبقات منظومة الويب المعتادة إلى عناية عاجلة.

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

وهذه أربعة دروس أعود إليها دائمًا.

١. رتّب أولوياتك بما يفعله المهاجمون فعلًا

حين يصل إلى مكتبك ١٤٠٠ إصلاح في يوم واحد، لا تستطيع أن تعاملها كأنها ١٤٠٠ مهمة متساوية. درجة CVSS العالية تخبرك كم قد تكون الثغرة سيئة، لكنها لا تخبرك هل يستغلّها أحدٌ الآن. فليست كل ثغرةٍ معلنة تحت الهجوم، وقد تستحق ثغرةٌ متوسطة الخطورة يستغلّها المهاجمون اهتمامك قبل ثغرةٍ حرجة لا يقترب منها أحد.

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

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

٢. افترض أن شيئًا سيتسلّل، وضيّق المسافة التي يقطعها

ما من فريقٍ يسدّ كل شيء قبل أن يتحرك المهاجمون. وقد أرتنا حالة SonicWall كم صارت هذه النافذة قصيرة: أيام، وأحيانًا ساعات. فالسؤال الأنفع إذن: ماذا يحدث بعد أن تفلت منا ثغرة؟

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

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

٣. عامِل الحافة على أنها خط المواجهة الأول

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

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

وقد أثبتت PHP2Shell ذلك. فلنحو يوم كامل لم يكن هناك ما يُثبَّت، وقال فريق PHP صراحةً إن التحديث هو الإصلاح الحقيقي الوحيد. ومع ذلك نشرت Cloudflare قواعد طارئة في جدار الحماية، وحجبت نمط الهجوم عند الحافة لعملائها. كانت قواعد مؤقتة، ولم يُرَد بها أن تحل محل التحديث، لكنها حوّلت فجوةً مخيفة إلى فجوةٍ يمكن التعامل معها.

٤. الحوكمة هي ما يجعل السرعة ممكنة

يظن كثيرون أن الحوكمة هي الجزء البطيء من الأمن، الأوراق التي تعطّل العمل. وتجربتي تقول العكس: الفرق الأسرع استجابةً هي التي تعرف مسبقًا من يقرّر، ومن ينفّذ، ومن يتواصل، قبل أن يقع أي شيء.

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

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

من ردّ الفعل إلى الصمود

لن يمنع أيٌّ من هذه الدروس الرقمَ القياسي القادم في تحديثات الثلاثاء، ولن يجعل أي نظامٍ منيعًا. لكنها تغيّر السؤال الذي نسأله لأنفسنا: بدل «كم نسرع في التحديث؟» نبدأ نسأل: «كم نصمد ونحن نحدّث؟».

وهذا التحوّل هو ما أسمّيه «هندسة الصمود»: أن نصمّم الأنظمة بحيث تبقى ثابتة حين يهتزّ العالم من حولها، ويظل من يعتمدون عليها قادرين على أن يتخذوا قراراتهم بثقة. ولكل من يدير عملياتٍ حرجة، هذا الثبات هو المقياس الحقيقي للأمن.

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

المصادر

• [Microsoft Patch Tuesday October 2026: Zero-Days, Critical CVEs, and What to Patch First](https://www.splashtop.com/blog/patch-tuesday-october-2026)
• Security Affairs: [October 2026 Patch Tuesday](https://securityaffairs.com/200953/security/microsoft-patch-tuesday-sets-new-record-with-1415-cves-in-october-2026-updates.html), [Cisco email gateway flaw](https://securityaffairs.com/?p=200985)
• Security Affairs: [SonicWall SMA 1000](https://securityaffairs.com/?p=198303), [Ivanti VPN zero-days](https://securityaffairs.com/200895/hacking/volexity-uncovers-stealthy-ivanti-vpn-attack-using-three-zero-day-vulnerabilities.html), [French supermarket attack](https://securityaffairs.com/200863/hacking/hackers-cranked-french-supermarkets-freezers-up-to-50-degrees-causing-hundreds-of-stores-to-lose-their-stock.html)
• Security Affairs: [GitLab maximum-severity fix](https://securityaffairs.com/200868/security/gitlab-patches-max-severity-vulnerability-cve-2026-97229.html)
• [PHP warns admins of two critical flaws, emergency patches coming tomorrow](https://www.bleepingcomputer.com/news/security/php-warns-admins-of-two-critical-flaws-emergency-patches-coming-tomorrow/)
• [AL26-026: Critical vulnerabilities impacting PHP](https://cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619)
• [nginx's latest five vulnerabilities fixed in 1.30.6 and 1.31.7](https://webhosting.today/2026/10/16/nginx-has-disclosed-26-vulnerabilities-in-2026-the-latest-five-are-fixed-in-1-30-6-and-1-31-7/)
• [Node.js fixes 10 flaws on the same day as PHP](https://fourweekmba.com/ai-node-js-fixes-10-flaws-4-high-on-the-same-day-as-php/)
• [GitLab Multiple Vulnerabilities, 13 October 2026](https://www.hkcert.org/security-bulletin/gitlab-multiple-vulnerabilities_20261013)