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

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

ماذا تعني أرقام “1,072 ثغرة” عمليًا؟

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

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

وتأتي هذه الوتيرة بالتوازي مع بيانات من قاعدة قاعدة الثغرات الوطنية الأمريكية (NVD) التي أشارت إلى تسجيل 46,872 ثغرة حتى الآن في عام 2026، على مقربة من 49,920 ثغرة تم الإبلاغ عنها كامل عام 2025. هذه الأرقام تعكس تحديًا عالميًا: عدد الثغرات لا يتناقص بل يتصاعد، بينما تظل القدرة التشغيلية لدى كثير من المؤسسات على التحديث السريع والاختبار المحدود مصدر قلق.

حزمة الثغرات في كروم 151: ما حجم الخطر؟

في تحديث كروم 151 الذي صدر يوم الأربعاء، تم إصلاح 370 ثغرة، من بينها 349 تم الإبلاغ عنها بواسطة جوجل نفسها. كما تم تصنيف 7 ثغرات على أنها حرجة (Critical).

لفهم أهمية التصنيف “حرجة”، من المفيد ربط ذلك بمفهوم نظام تقييم شدة الثغرات (CVSS) الذي يقدّم تقديرًا لاحتمالات التأثير والاستغلال. كلما ارتفع المؤشر، زادت احتمالات أن تكون الثغرة قابلة للاستغلال عن بُعد أو دون تفاعل كبير من المستخدم.

ثغرة الهروب من الحماية العازلة: لماذا تظل الأكثر إزعاجًا؟

من بين الأمثلة البارزة التي وردت في سياق الخبر، تم رصد ثغرة حرجة في مكوّن الملاحة داخل كروم، مرتبطة بإمكانية الهروب من الحماية العازلة في نظام التعرف على الثغرات (CVE) تحت المعرف CVE-2026-3545، بدرجة 9.6 على CVSS.

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

الأهم هنا أن جوجل أشارت إلى أن الاكتشاف تم عبر مشغل/هيكل اختباري اعتمد على نماذجها (ضمن سياق [Gemini])، وأن الثغرة لم تكن مرئية في الكود المصدر لأكثر من 13 عامًا. هذا يسلط الضوء على فجوة مزمنة: حتى مع اختبارات متكررة، قد تبقى أنماط ثغرات “كامنة” لسنوات طويلة، ثم تظهر فجأة عندما تتغير أدوات التحليل أو تتوفر نماذج قادرة على توليد سيناريوهات تشغيل أكثر تنوعًا.

لماذا تتغير دورة الإصدارات؟ من “كل أسبوعين” إلى “مرتين في الأسبوع”

أشارت جوجل إلى أنها تنتقل—تجريبيًا—إلى نسق يهدف إلى تقليل زمن الاستجابة. فهي تعمل على:

• اعتماد إصدارات رئيسية كل أسبوعين بدلًا من النسق السابق.
• إضافة تحديثات أمنية أسبوعية.
• تجربة إصدارين أمنيين في الأسبوع في مواجهة هجمات “سريعة الحركة” تعتمد على [ذكاء اصطناعي] و[أتمتة] الهجوم.

من الناحية الأمنية، هذا ليس “تحسينًا لراحة المستخدم” بقدر ما هو محاولة لإدارة نافذة الاستغلال (Time-to-Exploit): الفترة بين ظهور الثغرة في الواقع وبين وصول التصحيح للمستخدمين. كلما زادت هذه النافذة، زادت فرصة استغلال الثغرة قبل أن يتم تحديث الأجهزة.

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

أتمتة الوصف والإصدارات: تقليل الاختناق في “الورق” قبل “الكود”

أحد التحديات التي تواجه فرق الأمن ليس اكتشاف الثغرة فقط، بل تحويل الإصلاح إلى حزمة نشر كاملة: ملاحظات إصدار (Release Notes)، وصف الثغرة، وربطها بمعرفات [CVE]، وتوثيق ظروف الاستغلال. لذلك، تعمل جوجل على أتمتة أجزاء من توليد ملاحظات الإصدار ووصف [CVE] لتقليل الاعتماد على العمل اليدوي.

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

التصحيح دون إعادة تشغيل: متى يصبح ذلك ضرورة؟

من بين التحسينات التي لفتت الانتباه أيضًا فكرة “التصحيح الديناميكي” دون إجبار المستخدم على إعادة تشغيل المتصفح. الفكرة تعتمد على بنية المتصفح متعددة العمليات (Multi-process architecture)، بحيث يتم استبدال مكونات فرعية (مثل عملية العرض أو تسريع الرسومات) بملفات ثنائية مُحدّثة على نحو متسلسل.

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

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

إغلاق فئات الثغرات، لا مجرد إصلاح كل حالة

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

• التشديد على بيئة التشغيل لتقليل استغلال أخطاء الذاكرة.
• الانتقال تدريجيًا إلى لغات أكثر أمانًا للذاكرة مثل [Rust] بدلًا من اعتماد [C++] في أجزاء معينة.
• تقليل الاعتماد على أطر [C++] القديمة عبر بناء واجهة المستخدم العليا باستخدام [HTML] و[CSS] و[TypeScript].

لماذا هذا مهم؟ لأن كثيرًا من الثغرات الحرجة تاريخيًا كانت مرتبطة بمشاكل الذاكرة مثل الاستخدام بعد التحرير (Use-after-free) أو أخطاء تجاوز الحدود (Out-of-bounds). معالجة السبب الجذري عبر هندسة لغوية أكثر أمانًا قد يكون أكثر فعالية على المدى الطويل من زيادة عدد الإصلاحات.

سلسلة التوريد البرمجية: تحديث التبعيات كخط دفاع مبكر

أشارت جوجل كذلك إلى أنها تعمل على نقل تبعيات كروم التابعة لجهات خارجية إلى مسارات تحديث آلية (Automated update pipelines) لضمان بقائها محدثة. هذا يلامس أحد أكثر الاتجاهات نموًا في أمن التطبيقات: أمن سلسلة التوريد البرمجية (Software Supply Chain Security).

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

ما الذي يجب أن تفعله المؤسسات بعد هذا النوع من الأخبار؟

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

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

أسئلة للنقاش: هل نملك حقًا السيطرة على سرعة الثغرات؟

بينما تساعد أتمتة الإصلاحات والتصحيح الديناميكي وتحسين هندسة الأمان على تقليص نافذة الاستغلال، يبقى السؤال الأهم: هل تستطيع المؤسسات—بعملياتها البشرية وقيودها التشغيلية—مجاراة وتيرة اكتشاف الثغرات المتسارعة؟ أم أننا سنشهد فصلًا متزايدًا بين “زمن إصلاح المطور” و“زمن تحديث المؤسسة”؟

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

مصادر مقترحة للقراءة:

• قاعدة الثغرات الوطنية الأمريكية NVD
• منظومة تعريفات الثغرات CVE (MITRE)
• CVSS على ويكيبيديا
• Sandbox escape على ويكيبيديا

تابعوا التحديثات والنقاشات عبر صفحاتنا:
فيسبوك و
إكس.

هاشتاغات مقترحة: #أمن_الويب #إدارة_الثغرات #أمن_المتصفحات #أمن_البرمجيات #ذكاء_اصطناعي