في أواخر مارس 2025، تعرضت مستودعات GitLab تابعة لشركة Europcar Mobility Group لوصول غير مصرح به أدى إلى سرقة شيفرات مصدرية وبيانات مرتبطة ببعض عملاء علامتي Goldcar وUbeeqo. المهم هنا أن التقارير لم تُشر إلى اختراق منصة GitLab نفسها؛ الحادثة كانت مرتبطة بمستودعات تستخدمها Europcar لإدارة جزء من أصولها البرمجية.
أكدت Europcar وقوع الاختراق وبدأت تقييم نطاق الضرر وإخطار المتأثرين والجهة المختصة بحماية البيانات. أما الرقم المتداول، وهو ما يصل إلى 200 ألف عميل، فكان تقديرًا لنطاق الأشخاص المحتمل تأثرهم وليس رقمًا نهائيًا معلنًا لكل ضحايا الحادثة.
ماذا حدث في اختراق Europcar؟
ظهر في نهاية مارس 2025 مهاجم ادعى أنه تمكن من الوصول إلى مستودعات GitLab الخاصة بـEuropcar Mobility Group. ونشر لاحقًا معلومات ولقطات بهدف إثبات امتلاكه بيانات من بيئة التطوير، قبل أن يهدد بنشر نحو 37 جيجابايت من البيانات.
بحسب التقرير الأصلي الذي نشره BleepingComputer، شملت البيانات المسروقة شيفرة مصدرية مرتبطة بتطبيقات Android وiOS، إلى جانب نسخ احتياطية وقواعد بيانات وملفات إعداد مرتبطة بالتطبيقات والبنية التقنية الداخلية.
وأكد CERT-EU في ملخصه السيبراني لشهر أبريل 2025 وقوع الحادثة، مشيرًا إلى أن Europcar أخطرت السلطات وبدأت التواصل مع المستخدمين المتأثرين.
ما الذي أكده Europcar وما الذي كان مجرد ادعاء من المهاجم؟
من المهم فصل المعلومات المؤكدة عن ادعاءات المهاجم، خصوصًا في حوادث الابتزاز التي يحاول فيها منفذ الهجوم تضخيم حجم الاختراق لزيادة الضغط على الضحية.
| المعلومة | الحالة |
|---|---|
| حدث وصول غير مصرح به إلى مستودعات GitLab لدى Europcar | مؤكد |
| تسرب جزء من الشيفرة المصدرية والبيانات المرتبطة بالبيئة التقنية | مؤكد |
| تأثرت أسماء وعناوين بريد إلكتروني لعملاء Goldcar وUbeeqo | مؤكد وفق المعلومات المنشورة أثناء التحقيق |
| تراوح عدد العملاء المحتمل تأثرهم بين نحو 50 ألفًا و200 ألف | تقدير وليس رقمًا نهائيًا مؤكدًا |
| سرقة جميع مستودعات GitLab التابعة للشركة | ادعاء للمهاجم لم تؤكده المعلومات المتاحة بالكامل |
| وجود أكثر من 9000 ملف SQL و269 ملف .ENV ضمن المواد التي حصل عليها المهاجم | أرقام أعلنها المهاجم ونقلتها التقارير عن الحادثة |
| تسرب كلمات مرور العملاء أو بيانات البطاقات البنكية | لم تؤكده Europcar؛ المعلومات المنشورة قالت إنها لم تكن ضمن بيانات العملاء المتأثرة |
هذه التفرقة ضرورية لأن وجود ملف أو اسم ملف داخل عينة منشورة لا يعني تلقائيًا أن كل محتوياته كانت صالحة أو حديثة أو أن المهاجم حصل على كل الأنظمة المرتبطة به.
ما بيانات العملاء التي تعرضت للتسريب؟
أفادت المعلومات المنشورة أثناء التحقيق بأن بيانات العملاء المؤكد وجودها في المواد المسروقة اقتصرت على الأسماء وعناوين البريد الإلكتروني المرتبطة ببعض مستخدمي Goldcar وUbeeqo، وكانت بعض السجلات تعود إلى سنوات سابقة مثل 2017 و2020.
في المقابل، لم يُعلن عن تعرض كلمات مرور العملاء أو أرقام الحسابات البنكية أو بيانات بطاقات الدفع للسرقة ضمن هذه الحادثة. وهذا فرق مهم عند تقييم الخطر: تسريب البريد الإلكتروني والاسم لا يمنح المهاجم تلقائيًا إمكانية الدخول إلى حساب العميل، لكنه قد يجعله أكثر قدرة على تنفيذ رسائل احتيالية موجهة ومقنعة.
لماذا يعد الوصول إلى مستودعات الشيفرة خطرًا يتجاوز بيانات العملاء؟
مستودع Git لا يحتوي بالضرورة على الشيفرة المصدرية فقط. فقد توجد فيه ملفات إعداد، مسارات داخلية، معلومات عن الخدمات السحابية أو بنية التطبيقات، وأحيانًا أسرار مثل رموز الوصول أو مفاتيح API إذا تمت إضافتها إلى المستودع بطريق الخطأ.
في حادثة Europcar، نشر المهاجم لقطات ادعى أنها تظهر بيانات اعتماد موجودة داخل الشيفرة التي حصل عليها. لكن هذا لا يثبت أن كل بيانات الاعتماد كانت ما تزال صالحة أو أنها استُخدمت لاختراق أنظمة إضافية.
توضح وثائق GitLab الخاصة بـSecret Detection أن المفاتيح والرموز السرية ينبغي الاحتفاظ بها خارج المستودعات، لأن أي سر يتم دفعه إلى مستودع يمكن أن يصبح قابلًا للاستخدام من أي شخص يحصل لاحقًا على حق الوصول إليه.
ولهذا لا تنتهي الاستجابة لمثل هذا الاختراق بمجرد حذف ملف حساس؛ إذا تعرض Token أو API Key أو Credential للكشف، فيجب التعامل معه على أنه مكشوف وإلغاؤه أو تدويره، ثم مراجعة السجلات بحثًا عن أي استخدام غير مصرح به.
هل نعرف كيف تمكن المهاجم من اختراق Europcar؟
لا. لم تكشف Europcar علنًا في المعلومات المتاحة عن مسار الدخول الأولي الذي استخدمه المهاجم للوصول إلى مستودعات الشيفرة.
لذلك لا يصح وصف الحادثة بأنها استغلال لثغرة معينة في GitLab أو القول إن بيانات دخول مسروقة كانت السبب ما لم يظهر دليل إضافي. التقارير التي تناولت الحادثة ذكرت سرقة بيانات الاعتماد بواسطة Infostealers باعتبارها سيناريو شائعًا في اختراق بيئات التطوير، لكنها لم تثبت أن هذا هو ما حدث لدى Europcar.
كما أن وقوع حادثة في مستودعات شركة تستخدم GitLab لا يعني وجود ثغرة أمنية في خدمة GitLab نفسها. هذه نقطة مهمة عند تحليل أي حادثة تتضمن GitHub أو GitLab أو خدمة سحابية مشابهة.
لماذا يمكن أن تكون الأسماء وعناوين البريد الإلكتروني مفيدة للمهاجم؟
حتى عندما لا تتسرب كلمات المرور، يمكن استخدام الاسم والبريد الإلكتروني في بناء رسائل Phishing أكثر إقناعًا. يستطيع المهاجم، على سبيل المثال، انتحال رسالة مرتبطة بحجز سيارة أو فاتورة أو تحديث حساب ومحاولة دفع المستخدم إلى تسجيل الدخول في صفحة مزيفة.
ولهذا يجب على العملاء المتأثرين التعامل بحذر مع الرسائل التي تستغل اسم Europcar أو Goldcar أو Ubeeqo، خصوصًا إذا كانت تطلب فتح رابط أو تقديم معلومات شخصية أو مالية بصورة عاجلة.
وتوضح حالة مختلفة تناولناها في CyberOPlus كيف يمكن أن تتحول البيانات المسروقة إلى هجمات على الحسابات عبر Credential Stuffing عندما يحصل المهاجمون فعلًا على كلمات مرور يعيد أصحابها استخدامها في خدمات أخرى. في حادثة Europcar لعام 2025، لم يكن هناك تأكيد على تسرب كلمات مرور العملاء نفسها.
كيف استجابت Europcar للحادثة؟
بعد تأكيد الاختراق، بدأت Europcar تقييم البيانات التي تمكن المهاجم من الوصول إليها وتحديد المستخدمين المتأثرين. ووفق التقارير المنشورة، شرعت الشركة كذلك في إخطار هؤلاء المستخدمين وأبلغت جهة حماية البيانات المختصة بالحادثة.
وهذا يفسر أيضًا لماذا لا ينبغي التعامل مع الرقم الأولي للضحايا على أنه إحصاء نهائي؛ ففي المراحل الأولى من التحقيقات الجنائية الرقمية تحتاج الشركات إلى مطابقة قواعد البيانات المسروقة، إزالة السجلات المكررة، تحديد عمرها، والتأكد من ارتباطها بأشخاص حقيقيين قبل تحديد النطاق النهائي.
ما وضع حادثة Europcar في 2026؟
حتى أغسطس 2026، تظل حادثة مارس 2025 واقعة تاريخية مؤكدة وليست هجومًا جديدًا يجري الآن. ولا توجد في المعلومات العامة المتاحة متابعة رسمية تثبت أن كلمات مرور العملاء أو معلومات بطاقاتهم المصرفية كانت ضمن البيانات التي كُشف عنها في هذه الحادثة.
كما لا ينبغي تحويل تقدير «حتى 200 ألف عميل» إلى رقم نهائي مؤكد؛ المصادر الموثوقة التي وثقت الحادثة تحدثت عن نطاق محتمل يتراوح تقريبًا بين 50 ألفًا و200 ألف مستخدم من Goldcar وUbeeqo.
وتواصل Europcar نشر سياسة الخصوصية الحالية التي توضح أنواع البيانات الشخصية التي تعالجها الشركة والجهات التي قد تتلقى هذه البيانات والإجراءات المتعلقة بحمايتها، لكن هذه السياسة العامة ليست تقريرًا جنائيًا تفصيليًا عن حادثة GitLab نفسها.
ماذا يجب أن يفعل العميل الذي تلقى إشعارًا من Europcar؟
إذا أخطرتك Europcar أو إحدى علاماتها بأن بياناتك كانت ضمن الحادثة، فالأولوية هي تقليل فرص استغلال المعلومات في الاحتيال اللاحق:
- تحقق من الرسائل بصورة مستقلة: لا تستخدم الرابط الموجود في رسالة مفاجئة تدعي أنها من Europcar. افتح الموقع أو التطبيق الرسمي مباشرة.
- كن حذرًا من التصيد المخصص: معرفة المهاجم لاسمك وبريدك قد تجعل الرسالة المزيفة تبدو أكثر مصداقية.
- لا تقدم بيانات دفع بسبب رسالة غير متوقعة: خصوصًا الرسائل التي تدعي وجود فاتورة أو تعويض أو ضرورة تأكيد بطاقة بنكية.
- استخدم كلمة مرور فريدة لكل خدمة: إعادة استخدام كلمة المرور تعني أن اختراق خدمة مختلفة قد يعرض حسابات أخرى للخطر.
- فعّل MFA متى كان متاحًا: فهو يقلل خطر سيطرة المهاجم على الحساب إذا حصل لاحقًا على كلمة المرور.
- راقب محاولات الدخول والتنبيهات الأمنية: وتعامل بسرعة مع أي تغيير لم تطلبه أنت.
يمكن تطبيق هذه الإجراءات ضمن مجموعة أوسع من أفضل ممارسات الأمن السيبراني لحماية الحسابات والبيانات من سرقة بيانات الدخول والتصيد والهجمات التي تستغل كلمات المرور المعاد استخدامها.
ما الدروس الأمنية التي تكشفها حادثة Europcar؟
القيمة الأهم للحادثة في 2026 ليست إعادة سرد خبر الاختراق، بل فهم كيف يمكن لمستودع تطوير واحد أن يجمع أنواعًا مختلفة من الأصول الحساسة في مكان واحد: شيفرة التطبيقات، ملفات الإعداد، معلومات البنية الداخلية، نسخ قواعد البيانات وربما أسرار الوصول.
1. لا تخزن الأسرار داخل المستودع
توصي GitLab باستخدام أنظمة مخصصة لإدارة الأسرار بدل تخزين كلمات المرور والمفاتيح والرموز الحساسة كنصوص واضحة داخل المستودعات. وتوفر المنصة كذلك تقنيات لاكتشاف الأسرار أثناء التطوير وقبل وصولها إلى الفروع المهمة.
2. افحص تاريخ Git وليس الملفات الحالية فقط
حذف مفتاح API من آخر نسخة من المشروع لا يضمن اختفاءه إذا كان موجودًا في Commit سابق. لذلك تتضمن أدوات Secret Detection في GitLab إمكانية فحص المستودعات وسجلها بحثًا عن أسرار تم إدخالها في مراحل سابقة.
3. ألغِ بيانات الاعتماد المكشوفة بدل الاكتفاء بحذفها
إذا وصل سر إلى مستودع ثم تعرض المستودع للاختراق، يجب تدوير السر أو إلغاؤه. إزالة النص من الشيفرة لا تمنع المهاجم من استخدام النسخة التي سبق أن نسخها.
4. طبّق أقل قدر ممكن من الصلاحيات
الحساب أو Token الذي يستطيع الوصول إلى جميع المشاريع والبيئات يرفع أثر أي اختراق. تقسيم الصلاحيات بين المستودعات والخدمات يقلل مساحة الضرر في حال الاستيلاء على بيانات اعتماد واحدة.
5. افصل النسخ الاحتياطية وبيانات الإنتاج عن بيئة التطوير
وجود نسخ من بيانات العملاء داخل بيئة يستطيع مستخدمو التطوير الوصول إليها يزيد أثر اختراق حساب أو مستودع. ينبغي تقليل بيانات الإنتاج المستخدمة في التطوير، وإخفاء البيانات الشخصية عندما لا تكون مطلوبة، ووضع ضوابط منفصلة للنسخ الاحتياطية.
الخلاصة
كانت حادثة Europcar في مارس 2025 اختراقًا حقيقيًا لمستودعات GitLab مرتبطة بالشركة، وأسفرت عن كشف شيفرات وبيانات تقنية وأسماء وعناوين بريد إلكتروني لبعض عملاء Goldcar وUbeeqo. أما الرقم البالغ 200 ألف عميل فهو الحد الأعلى لتقدير منشور أثناء التحقيق، وليس رقمًا نهائيًا ينبغي عرضه باعتباره مؤكدًا.
كما لم يكن الحادث دليلًا على اختراق GitLab كمنصة، ولم يثبت أن كلمات مرور العملاء أو بيانات بطاقاتهم المصرفية تعرضت للتسريب. وتبقى أبرز دروس الواقعة هي ضرورة فصل الأسرار عن مستودعات الشيفرة، واكتشافها مبكرًا، وتدوير أي Credentials مكشوفة، وتقييد صلاحيات الوصول حتى لا يتحول اختراق حساب تطوير واحد إلى وصول واسع داخل المؤسسة.