Metabase: ثغرة SQLi حرجة بنقاط 10.0 تسرق بيانات العملاء
استُغلت ثغرة SQLi حرجة من نوع صفر-يوم في منصة Metabase لتجزئة البيانات وإصداراتها المستضافة ذاتيًا، مما أدى إلى اختراق وسرقة بيانات حساسة من عملاء بارزين مثل Framework و Tally.
مقدمة تحليلية
بتصنيف CVSS يبلغ 10.0، أعلنت Metabase عن استغلال ثغرة حقن SQL (SQLi) من نوع صفر-يوم بشكل نشط لاختراق مثيلات العملاء وسرقة بياناتهم. تأثرت منصة Metabase Cloud SaaS والإصدارات المستضافة ذاتيًا بدءًا من الإصدار 1.58 وما فوق بالهجمات، التي كُشفت في 7 أغسطس 2026. سمحت الثغرة للمهاجمين بالحصول على صلاحيات إدارية عن بُعد دون الحاجة إلى مصادقة مسبقة، مما أتاح لهم تغيير الإعدادات، وسرقة بيانات الاعتماد، والوصول إلى بيانات قواعد البيانات المتصلة وتصديرها. من بين المتضررين شركة Framework المصنعة للحواسيب المحمولة وTally منشئ النماذج الإلكترونية، بالإضافة إلى LexisNexis عبر أحد مورديها، حيث بدأت عمليات الاختراق منذ 3 أغسطس 2026.
التحليل التقني
تتمحور الثغرة حول عيب حقن SQL غير مصادق عليه ضمن Metabase، تحديداً في نقطة النهاية `/api/session/reset_password`. هذا الخلل سمح لمهاجم عن بُعد بحقن أوامر SQL تعسفية مباشرة في قاعدة بيانات تطبيق Metabase. النتيجة المباشرة لهذا الحقن هي الحصول على وصول إداري كامل إلى مثيل العميل المتأثر. بعد تحقيق صلاحيات المدير، يصبح المهاجم قادراً على:
- تغيير تكوين التطبيق.
- سرقة بيانات الاعتماد المخزنة لقواعد البيانات المتصلة.
- قراءة أي بيانات يمكن الوصول إليها عبر تلك الاتصالات.
- تصدير البيانات الحساسة.
أكدت Metabase أن الهجمات استُغلت بفعالية وأنها قامت بحظر نقاط النهاية المستخدمة وطرحت إصلاحاً فورياً. تشمل الإصدارات التي تم إصلاحها لجميع الفروع المتأثرة من 0.58 إلى 0.63:
- 0.58.24
- 0.59.21
- 0.60.17
- 0.61.11
- 0.62.9
- 0.63.5
بالنسبة للمؤسسات غير القادرة على الترقية الفورية، تُنصح Metabase بحظر الوصول مؤقتاً إلى نقطة النهاية `/api/session/reset_password`. يمكن تحديد الهجمات من خلال طلب POST إلى `/api/session/reset_password` يعيد رمز الحالة 400، يليه طلب GET ناجح إلى `/api/user/current`. تشير سجلات النظام التي تظهر هذه الإدخالات إلى احتمال تعرض النظام للاختراق. توصي Metabase عملاء الإصدارات المستضافة ذاتيًا بالترقية الفورية، وإلغاء جميع جلسات المستخدمين النشطة، ومراجعة مفاتيح API وحسابات المسؤولين بحثًا عن تغييرات غير مصرح بها، وتدوير بيانات الاعتماد لقواعد البيانات المتصلة، وفحص السجلات وسجل الاستعلامات بحثًا عن علامات اختراق.
تأثيرات الاختراق على العملاء
أعلنت شركة Framework عن سرقة معلومات العملاء بعد اختراق مثيل Metabase الخاص بها، متضمنة أسماء كاملة، وعناوين بريد إلكتروني، وعناوين IP لتسجيل الدخول، ومعلومات عناوين الفواتير والشحن، وأرقام هواتف، وأسماء شركات. بالنسبة لعملاء Framework for Business، قد تشمل البيانات اسم الشركة، ورقم الهاتف، ورقم ضريبة القيمة المضافة (VAT)، ورقم تعريف صاحب العمل (EIN)، وعنوان البريد الإلكتروني للفواتير. أبلغت Metabase شركة Framework في 6 أغسطس بأن مثيلها كان عرضة للهجوم وتم الوصول إليه في 3 أغسطس.
كما أخطرت Tally، منصة بناء النماذج الشهيرة، المستخدمين باختراق بيئة Metabase Analytics الخاصة بها في 3 أغسطس، مما أدى إلى الوصول إلى عناوين بريدهم الإلكتروني وكلمات المرور في شكل تجزئة تشفيرية (hash). أكدت Tally أن التجزئة أحادية الاتجاه ولا يمكن تحويلها إلى كلمة المرور الأصلية، وأن بيانات النماذج أو الردود لم تتأثر لأنها مخزنة بشكل منفصل. بينما لم تحدد LexisNexis بشكل مباشر أن الهجوم مرتبط بـ Metabase API، إلا أنها أشارت إلى تأثيره على Metabase API الخاص بها ضمن خدمات Diligence وNewsdesk، بعد تحديد نشاط غير عادي على خوادم يديرها بائع طرف ثالث في وقت سابق من الأسبوع، مما استدعى فصل الأنظمة المتأثرة.
السياق وتأثير السوق
يُشكل استغلال ثغرة Metabase من نوع صفر-يوم دليلاً ملموساً على المخاطر الكامنة في أدوات ذكاء الأعمال (BI) التي تُعتبر حيوية لعمليات الشركات. ففي حين كانت Metabase تُقدم كحل مرن ومتاح للتحليلات سواء كخدمة سحابية مُدارة (SaaS) أو كبرنامج مستضاف ذاتياً، فإن هذا الاختراق يضع معياراً جديداً للتقييم الأمني. لم يعد يكفي مجرد الثقة بوجود فريق أمني للمورد؛ بل أصبح التحقق العميق من نقاط الضعف المحتملة والامتثال الأمني للطرف الثالث أمراً لا مفر منه. قبل هذا الحادث، كان يُفترض أن أنظمة SaaS، لا سيما تلك التي تُقدمها الشركات المطورة للبرنامج نفسه، توفر طبقة أمان إضافية من خلال التحديثات التلقائية والإدارة الاحترافية.
لكن الواقع أثبت أن هذه الثغرة لم تفرق بين بيئة Cloud السحابية والإصدارات المستضافة ذاتياً، مما يُسقط فكرة التفوق الأمني التلقائي لأحد النموذجين. يُضعف هذا الحدث مكانة Metabase وثقة العملاء بها بشكل مباشر، كما أنه يُعيد النظر في مكانة أدوات BI المماثلة. فالمنافسون في سوق أدوات تحليل البيانات، مثل Tableau أو Power BI، لن يمروا بهذا الحدث دون تدقيق متزايد من قبل عملائهم المحتملين، مما يُجبر الصناعة بأكملها على رفع مستوى اختبارات الأمن والشفافية. الخاسر الأكبر هنا ليس فقط Metabase، بل أيضاً الشركات التي اعتمدت على أمانها، حيث تضررت سمعتها وبيانات عملائها بشكل مباشر بسبب إهمال أساسي في تصميم التطبيق.
رؤية Glitch4Techs
إن استغلال ثغرة حقن SQL غير مصادق عليها، تُمنح تصنيف CVSS بقيمة 10.0 وتسمح بالوصول الإداري الكامل عن بُعد، ليس مجرد خلل برمجي عادي؛ إنه إخفاق ذريع في المبادئ الأمنية الأساسية لتطبيق يتعامل مع بيانات حساسة. حقيقة أن هذا الاختراق حدث عبر نقطة نهاية شائعة مثل `/api/session/reset_password` تبرهن على غياب تدقيق أمني عميق خلال دورة حياة تطوير البرنامج. هذا يشير إلى أن Metabase لم تلتزم بأبسط معايير الأمن عند التعامل مع مدخلات المستخدم الحساسة، مما مكن المهاجمين من استغلال الثغرة في 3 أغسطس 2026. إن هذا المستوى من الضعف الجوهري في تطبيق مركزي يعني أن أي ادعاءات سابقة بالأمان كانت قائمة على أساس هش، مما يستوجب إعادة تقييم جذرية لعمليات الأمان لدى الشركة.
كن أول من يعرف بمستقبل التقنية
أهم الأخبار والتحليلات التقنية مباشرة في بريدك.
