ثغرة Zero-Auth في ServiceNow: ما يكشفه تأخر الإفصاح عن أمان SaaS في 2026

معلمة واحدة أسقطت جدار المصادقة

تتلخص السبب الجذري في سطر واحد من الإعداد: requires_authentication = false. هذه المعلمة، المضبوطة على نقطة وصول Scripted REST في ServiceNow عند المسار /api/now/related_list_edit/create، أزالت كامل التسلسل الهرمي لضبط الوصول المبني فوقها. كل فحص للأدوار، وكل قائمة تحكم بالوصول، وكل سياسة صلاحيات — هذه كلها تعمل بعد التحقق من الهوية، فحين يُزال حاجز المصادقة يصبح ما يليه عديم الأثر.

يُظهر التحليل التقني في تنبيه الحادثة CA-26-021 الصادر عن Deepwatch أن ناقل الهجوم لم يستلزم اختبار بيانات الاعتماد ولا تصعيد الامتيازات. نفّذت طلبات HTTP غير مصادَقة ضمن سياق مستخدم الضيف، إذ استعلمت مباشرةً عن جدول sys_group_has_role لإلحاق أدوار إدارية عالية الامتياز ببنى المجموعات الافتراضية — وهو آلية استمرارية لا مجرد استخراج بيانات. اجتاح الهجوم نُسَخ المؤسسات من عنوان IP51.159.98[.]241 في 2 و3 يونيو 2026، قبل يومين من نشر ServiceNow التصحيح الطارئ.

كان النطاق المتأثر أوسع من نقطة وصول واحدة. أكّد تقرير CSO Online أن تحديثاً ثانياً في 10 يونيو أصلح نقطتَي وصول Scripted REST إضافيتين تشتركان في نمط الإعداد الخاطئ ذاته — مما يعني أن تصحيح 5 يونيو كان ناقصاً. تأثّر بشكل مباشر العملاء على إصدار Australia من ServiceNow (المتاح عموماً منذ 5 مايو 2026)، فضلاً عن نُسَخ Xanadu وYokohama وZurich ذات تكوينات API المخصصة. أكّدت ServiceNow للعملاء أن مجموعة فرعية من النُسَخ جرى الاستعلام عنها بنجاح، لكنها أحجمت عن تحديد أنواع البيانات التي جرى الوصول إليها.

لا تُعدّ نُسَخ ServiceNow في المؤسسات مستودعات بيانات خاملة. فهي تتراكم فيها تذاكر دعم IT ومعلومات الموظفين وقوائم جرد الأصول وتقارير الحوادث الأمنية الداخلية — والأهم — بيانات الاعتماد. كثيراً ما يلصق المهندسون مفاتيح API وكلمات مرور حسابات الخدمة وسلاسل اتصال قواعد البيانات في أوصاف التذاكر ومرفقاتها. يُحدّد تحليل Unosecur لحادثة KB3067321 هذا بوصفه المخاطرة الحقيقية بعيدة المدى: “تتراكم بيانات الاعتماد إلى أجل غير مسمى بصورة افتراضية دون جدول تدوير أو تدقيق جزئي”، وبما أنها تقطن في نصوص غير منظمة فإنها تفلت من أدوات فحص الأسرار التي تعتمد عليها المؤسسات.

الأيام الأربعة التي شلّت الساعة التنظيمية

يمثّل التصحيح التقني والجدول الزمني للإفصاح إخفاقَين منفصلَين، وقد يكون الثاني أشد عواقب قانونية من الأول.

تلقّت ServiceNow تقريراً سرياً عبر برنامج bug bounty يصف الثغرة في 22 أبريل 2026. تُظهر الوثائق الداخلية الواردة في تحليل Deepwatch أن الشركة رصدت المشكلة نحو 7 أبريل وأجّلت التصحيح إلى إصدار “Brazil” الخاص بالربع الرابع — قرار جدولة اتُّخذ قبل وصول تقرير bug bounty. لم يُنشر التصحيح الطارئ إلا في 5 يونيو، بعد ستة أسابيع من تقديم البلاغ. لذا فإن نافذة الاستغلال في 2 و3 يونيو لم تكن ثغرة zero-day بالمعنى التقليدي؛ بل كانت ثغرة معروفة جرى تخفيض أولويتها.

زادت آليات الإفصاح الأمر سوءاً. نشرت ServiceNow نشرة الدعم KB3067321 في 9 يونيو — بعد أربعة أيام من تصحيح النُسَخ المستضافة — ووضعتها خلف بوابة دعم العملاء. وثّقت BleepingComputer تسلسل الإخطار: أُبلغ العملاء عبر دعاوى دعم فردية، لكن النشرة ذاتها تطلّبت علاقة دعم قائمة للوصول إليها. المؤسسات التي لم تفتح دعوى بعد لم تتلقَّ أي إشارة من المورّد لبدء التحقيق.

هذه تحديداً هي الفجوة البنيوية التي صُمّمت المادة 33 من GDPR لمنعها. يتعيّن على مسؤول المعالجة الذي يكتشف خرقاً أن يُخطر السلطة الإشرافية “دون تأخير لا مبرر له وحيثما أمكن في غضون 72 ساعة”. نشرة مقيّدة لا يكتشفها المسؤول إلا بعد تسجيل الدخول إلى بوابة المورّد تُشغّل الساعة متأخرةً وبصورة غير متساوية. يبدأ التزام GDPR من لحظة إدراك المعالج للخرق — والمعالج، أي ServiceNow هنا، كان مدركاً للثغرة الأشمل منذ أسابيع. من المتوقع أن يدرس المنظّمون في الاتحاد الأوروبي وكاليفورنيا ما إذا كانت النشرة المقيّدة تستوفي معايير الإفصاح بموجب GDPR وCCPA، ولا سيما حين كانت بيانات مواطنين أوروبيين تُعالَج في النُسَخ المتأثرة.

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

ما يجب على فرق أمان المؤسسات فعله

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

1. التحقق من وصول التصحيح إلى نسختك ومراجعة آثار ما بعد الاستغلال

بالنسبة لعملاء ServiceNow المستضافين، نُشر التصحيح الطارئ في 5 يونيو تلقائياً. أما التثبيتات المستضافة ذاتياً أو on-premises فقد استلزمت تطبيق KB3067372 يدوياً. تأكّد من TAM خاص بـ ServiceNow أن نسختك تلقّت التحديث، ثم اطلب إدخال سجل التغيير دليلاً كتابياً.

لا ينهي التصحيح التحقيقَ. توصي تحليل الخرق الصادرة عن SOCRadar بالاحتفاظ بسجلات المعاملات اعتباراً من 1 يونيو والتصفية تحديداً عن الطلبات غير المصادَقة التي يُظهر فيها حقل المستخدم guest أو anonymous أو null. إن ظهرت طلبات كهذه في سجلاتك تستهدف نقطة الوصول /api/now/related_list_edit/create أو موارد REST المبرمجة ذات الصلة، فاعتبر ذلك حادثة مؤكدة لا حادثة كادت تقع. دوّر جميع بيانات الاعتماد التي قد تكون حاضرة في نصوص تذاكر الدعم ومرفقاتها، مع إعطاء الأولوية وفق نطاق الامتياز.

التحديث الثانوي في 10 يونيو أصلح نقطتَي وصول إضافيتين بالإعداد الخاطئ ذاته. أجرِ تدقيقاً كاملاً لموارد REST المبرمجة في نسخة ServiceNow الخاصة بك. أي نقطة وصول مضبوطة على requires_authentication = false ولا تُقصد صراحةً كـ API عامة هي إعداد خاطئ ينتظر الاستغلال.

2. إدراج SLA الإخطار من موردي SaaS في بنود العقود

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

ينبغي أن يتضمن تجديد عقدك القادم مع مورّد SaaS أو مراجعة أمان الموردين SLA صريحة للإخطار: حد أقصى محدد من الساعات بين الاستغلال المؤكد والإخطار المباشر للعميل (24 ساعة مثلاً)، واشتراط وصول الإخطار عبر تواصل مباشر (بريد إلكتروني أو webhook أو تكامل مع SIEM) لا عبر بوابة محمية فحسب، وبند حق التدقيق الذي يتيح لفريقك التحقق باستقلالية من نشر التصحيح.

3. معاملة منصة التذاكر كمستودع بيانات اعتماد وحوكمتها على هذا الأساس

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

هذه المشكلة سابقة لخرق يونيو 2026 وستستمر بعده. طبّق سياسة راسخة: يجب تدوير أي بيانات اعتماد تُلصق في تذكرة دعم فور إغلاق التذكرة. فعّل مكوّن Sensitive Data Exposure (SDE) الخاص بـ ServiceNow إن أتاحه مستوى ترخيصك، واضبطه للكشف تلقائياً عن السلاسل عالية الانتروبيا المتسقة مع مفاتيح API وسلاسل الاتصال والرموز. بالنسبة لبيانات الاعتماد الحساسة (حسابات مشرفي قواعد البيانات، خدمات السحابة الرئيسية، أسرار موردي الهوية)، فكّر في حظر تضمينها مباشرةً في نص التذاكر واستخدام رابط يشير إلى إدخال مدير الأسرار ينتهي فور إغلاق التذكرة.

الصورة الأشمل: للمسؤولية المشتركة زاوية عمياء

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

كان الضبط الافتراضي requires_authentication = false في ServiceNow قراراً من المورّد. لم يكن لدى العميل أي رؤية عنه، ولا لوحة تعرض وضع المصادقة لكل نقطة وصول REST مبرمجة، ولا إخطار حين تُشحن منصة بإصدار جديد يحمل هذه المعلمة مضبوطةً خطأ. لكن البيانات المعرّضة للخطر — تذاكر الدعم والسجلات الوظيفية وبيانات الاعتماد — كانت بيانات العميل بالكامل. والالتزامات القانونية التي يُفضي إليها الخرق — المادة 33 من GDPR وقاعدة الأيام الأربعة للـ SEC وإخطار خرق HIPAA — تقع على عاتق العميل لا المورّد.

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

الأسئلة الشائعة

المصادر والقراءات الإضافية

• والقراءات الإضافية
• ServiceNow تكشف عن حادثة أمنية تعرّض بيانات العملاء — BleepingComputer
• CA-26-021: نقطة وصول ServiceNow غير المصادَقة مستغَلة فعلياً — Deepwatch
• ServiceNow تُصلح مشكلة API بعد تقارير عن نشاط مشبوه — CSO Online
• ServiceNow KB3067321: فجوة حوكمة NHI المكشوفة — Unosecur
• خرق ServiceNow: بيانات العملاء مكشوفة عبر وصول API غير مصادَق — SOCRadar