أصلحت شركة مايكروسوفت ثغرة أمنية مهمة في تطبيق Microsoft Authenticator على نظام أندرويد كانت تسمح لتطبيقات خبيثة لا تمتلك أي أذونات خاصة بانتحال صفة تطبيقات مايكروسوفت الموثوقة، مثل Microsoft Teams، والحصول على رموز المصادقة الخاصة بحسابات العمل للمستخدمين.
وتحمل الثغرة المعرف CVE-2026-80097، وقد صنفتها مايكروسوفت بدرجة خطورة بلغت 8.6 وفق نظام CVSS، فيما جرى تصحيح المشكلة ضمن الإصدار 6.2606.4246 من تطبيق Microsoft Authenticator لنظام أندرويد، مع دعوات مباشرة للمستخدمين والمؤسسات إلى تحديث التطبيق بأسرع وقت ممكن.
وتكتسب هذه الثغرة أهمية خاصة لأنها تستهدف أحد أكثر التطبيقات استخدامًا في منظومة الهوية الرقمية الخاصة بمايكروسوفت، والذي تعتمد عليه ملايين المؤسسات حول العالم في إدارة عمليات تسجيل الدخول والمصادقة والوصول إلى الخدمات السحابية.
كيف تعمل الثغرة داخل تطبيق المصادقة؟
لا يقتصر دور Microsoft Authenticator على توليد الرموز المؤقتة المستخدمة في المصادقة متعددة العوامل، بل يعمل أيضًا كوسيط مركزي لإدارة عمليات تسجيل الدخول بين تطبيقات مايكروسوفت المختلفة.
فعند محاولة المستخدم تسجيل الدخول إلى تطبيقات مثل Teams أو Outlook أو غيرها من تطبيقات Microsoft 365، يتولى Authenticator التحقق من هوية المستخدم وإصدار رمز وصول رقمي يعرف باسم Token.
ويمنح هذا الرمز التطبيقات القدرة على الوصول إلى موارد الحساب المختلفة دون الحاجة إلى إعادة إدخال بيانات الاعتماد في كل مرة، وهو ما يجعل آلية التحقق من التطبيق الطالب للرمز عنصرًا حاسمًا في أمن المنظومة بأكملها.
وبحسب الباحث الأمني أوفيك ليفين، الذي اكتشف الثغرة خلال برنامج زمالة مع شركة Enclave، فإن المشكلة كانت تكمن في مكون داخل التطبيق يدعى AccountChooserActivity، يمكن لأي تطبيق موجود على الجهاز تشغيله.
وعندما كانت التطبيقات الخبيثة تستدعي هذا المكون، كان التطبيق يبني طلب المصادقة اعتمادًا على معلومات يزودها المهاجم نفسه، بما في ذلك اسم التطبيق الذي يدعي تمثيله.
وبذلك أصبح بإمكان التطبيق الضار الادعاء بأنه تطبيق Teams أو أي تطبيق رسمي آخر من مايكروسوفت، ليحصل على رموز وصول مخصصة لهذا التطبيق دون أن يتحقق النظام بصورة صحيحة من هوية الجهة الحقيقية مقدمة الطلب.
خلل في آلية التحقق من التوقيع الرقمي
كانت مايكروسوفت قد أدرجت آلية للتحقق من التوقيعات الرقمية بهدف منع مثل هذا النوع من الانتحال، لكن الباحثين اكتشفوا أن طريقة تطبيقها لم تكن كافية.
فبدلاً من التحقق من هوية التطبيق الذي أرسل الطلب فعليًا، كانت المنظومة تتحقق فقط من التوقيع الرقمي الخاص بالتطبيق الذي يدعي المهاجم تمثيله.
وبما أن تطبيق Teams الأصلي كان مثبتًا بالفعل على الجهاز في السيناريو التجريبي، فقد تمكن النظام من قراءة توقيعه الرقمي الحقيقي واعتباره دليلًا كافيًا على شرعية الطلب، على الرغم من أن الطلب نفسه أتى من تطبيق مختلف تمامًا.
وأشار الباحثون إلى أن التطبيق كان قادرًا على تحديد التطبيق الحقيقي الذي أرسل الطلب، لكنه لم يستخدم هذه المعلومة لاتخاذ قرار بشأن منح رمز الوصول من عدمه.
إمكانية الوصول إلى البريد والملفات والتقويم
أظهرت الاختبارات التي أجرتها شركة Enclave أن المهاجم يستطيع، بعد نجاح العملية، الحصول على رموز وصول تمنحه صلاحيات واسعة داخل بيئة العمل الخاصة بالضحية.
وشملت الصلاحيات القدرة على قراءة البريد الإلكتروني وإرسال الرسائل والوصول إلى الملفات المخزنة وتعديلها وقراءة بيانات التقويم وإدارتها، فضلاً عن الوصول إلى موارد أخرى مرتبطة بحساب العمل عبر خدمات Microsoft Graph.
وبصورة عملية، فإن نجاح الهجوم يمنح المهاجم القدرة على التصرف كمستخدم شرعي داخل بيئة المؤسسة، الأمر الذي قد يؤدي إلى سرقة البيانات أو تنفيذ هجمات تصيد داخلية أو الوصول إلى معلومات حساسة دون إثارة الشبهات.
ورغم ذلك، أكدت مايكروسوفت أن الثغرة لا تؤثر إلا على حساب العمل المسجل داخل التطبيق على الجهاز نفسه، ولا تسمح بالوصول إلى حسابات أخرى غير مرتبطة به.
خلاف حول الحاجة إلى تفاعل المستخدم
أحد الجوانب المثيرة للاهتمام في القضية يتمثل في اختلاف رواية الباحثين عن رواية مايكروسوفت بشأن شروط الاستغلال.
فقد ذكرت شركة Enclave أن نموذجها التجريبي تمكن من الحصول على الرموز المطلوبة بمجرد وجود حساب مسجل داخل التطبيق، ودون الحاجة إلى أي تفاعل إضافي من المستخدم.
في المقابل، أكدت مايكروسوفت أن نجاح الهجوم يتطلب تثبيت تطبيق خبيث على الجهاز وإقناع الضحية بإكمال خطوة مصادقة عبر التطبيق، وهو ما انعكس أيضًا في تقييم CVSS الذي أشار إلى وجود عنصر تفاعل بشري ضمن شروط الاستغلال.
وعلى الرغم من هذا الاختلاف، تتفق جميع الأطراف على أن المشكلة كانت حقيقية وتمت معالجتها رسميًا قبل الكشف العلني عنها.
التحديث الإجباري وخطوات الحماية
أوضحت مايكروسوفت أنها لم ترصد أي استغلال فعلي للثغرة في بيئات الإنتاج، كما لم تكن معروفة للعامة قبل إصدار التصحيح الأمني.
وجرى تضمين المعالجة ضمن تحديثات سبتمبر 2026 الأمنية، فيما أوصت المؤسسات التي تدير أجهزة أندرويد عبر أنظمة إدارة الأجهزة المحمولة بفرض استخدام الإصدار 6.2606.4246 أو أحدث على جميع المستخدمين.
كما أشارت الشركة إلى أن احتمالية الاستغلال تعد منخفضة نسبيًا، لكنها لم توضح بشكل صريح ما إذا كان تثبيت التحديث يؤدي تلقائيًا إلى إبطال أي رموز وصول ربما حصلت عليها تطبيقات خبيثة قبل تثبيت الإصلاح.
وتسلط هذه الحادثة الضوء على التحديات الأمنية المتزايدة في أنظمة إدارة الهوية الحديثة، حيث لم تعد المخاطر تقتصر على سرقة كلمات المرور أو اختراق الخوادم، بل باتت تمتد إلى المكونات الوسيطة المسؤولة عن إدارة الثقة والمصادقة بين التطبيقات، وهي مكونات تمنح المهاجمين في حال استهدافها القدرة على تجاوز طبقات أمنية متعددة والوصول إلى البيانات المؤسسية الحساسة.
