ثغرة Lovable وتسريب البيانات: إيش صار وكيف تتأكد من تطبيقك

إذا منتجك انبنى بـ Lovable، غالبًا سمعت عن «ثغرة Lovable» أو «تسريب Lovable». أغلب الكلام عنها بالإنجليزي، ويخلط بين حادثتين مختلفتين: الأولى كانت في قواعد قاعدة البيانات داخل منتجات كثيرة مبنية بـ Lovable، والثانية كانت في منصة Lovable نفسها وانصلحت. هذا ملخص هادي لإيش صار بحسب المصادر الأصلية، وإيش تفحص في منتجك اليوم.

إيش صار بالضبط

• مارس 2025: بحسب إفصاح الباحث Matt Palmer، انتبه في 20 مارس إن منتج مبني بـ Lovable يكشف بياناته لأي أحد بدون تسجيل دخول، وبلّغ Lovable في اليوم الثاني. وبعدها، بحسب نفس الإفصاح، فحص 1,645 منتج من معرض Lovable، ولقى 170 منها، يعني حوالي 10%، فيها جداول يقدر أي زائر يوصل لها بدون تسجيل دخول. ومن البيانات اللي ذكرها: أسماء وإيميلات وأرقام جوالات ومفاتيح خدمات ثانية.
• 25 أبريل 2025: بحسب سجل تحديثات Lovable، نزل Lovable 2.0 ومعه فحص أمني وقت النشر للمشاريع المربوطة بـ Supabase. Palmer قال في إفصاحه إن هذا الفحص وقتها كان يتأكد إن فيه قاعدة على الجدول، مو إن القاعدة صحيحة.
• نهاية مايو 2025: نشر Palmer إفصاحه، وتسجّلت الثغرة باسم CVE-2025-48757 بدرجة 9.3 من 10. سجل الثغرة في قاعدة بيانات الثغرات الأمريكية (NVD) يقول إنها «متنازع عليها»: موقف Lovable إن كل صاحب منتج مسؤول عن حماية بيانات منتجه.
• يونيو 2025: بحسب سجل تحديثات Lovable، أضافت مراجعة أمنية بالذكاء الاصطناعي قبل النشر، وتنبيه لما تلصق مفتاح سري في المحادثة.
• نوفمبر وديسمبر 2025: صارت المشاريع الجديدة خاصة افتراضيًا، بحسب Lovable.
• فبراير 2026: بحسب تقرير The Register، باحث لقى 16 ثغرة في منتج واحد مبني بـ Lovable، منها قواعد ناقصة وتحقق مقلوب في تسجيل الدخول. ردّت Lovable إن الفحص قبل النشر موجود، وتوصياته ما انطبقت في هذا المنتج.
• أبريل 2026: بحسب بيان Lovable في 22 أبريل، باحث نشر في 20 أبريل إن أي مستخدم مسجّل في Lovable يقدر يشوف بيانات المشاريع العامة. تعديل داخلي في فبراير رجّع هذا الوصول بالغلط، فمن 3 فبراير حتى 20 أبريل 2026 كانت محادثات المشاريع العامة وكودها ممكن يشوفها أي مستخدم عنده رابط المشروع. Lovable قالت إنها صلّحته خلال ساعتين، وإن المشاريع الخاصة و Lovable Cloud ما تأثرت، واعترفت إن ردّها الأول ما أعطى المشكلة حقها. وبعدها بيومين، بحسب سجل تحديثاتها، ألغت خيار المشروع العام.

بعض المقالات قالت إن كل مشروع قبل نوفمبر 2025 انكشف مع مفاتيح قاعدة بياناته، لكن بيان Lovable ما يذكر قواعد البيانات ولا المفاتيح.

ليش يأثّر على تطبيقك

في منتجات Lovable، المتصفح يكلّم قاعدة البيانات في Supabase مباشرة بمفتاح عام (anon أو sb_publishable_). هذا المفتاح موجود في كود الواجهة، وهذا طبيعي: Supabase تقول إنه آمن للنشر، لأنه يوصل فقط للي تسمح فيه قواعد RLS.

تخيّل المفتاح العام مفتاح باب العمارة، وقواعد RLS قفل كل شقة. إذا جدول ما عليه RLS، أو عليه قاعدة شرطها true، مفتاح العمارة يفتح كل الشقق. هذا اللي صار في الـ 170 منتج: ما احتاج أحد يخترق شي، الطلب العادي رجّع كل السطور.

المفتاح السري (service_role أو sb_secret_) شي ثاني: يتجاوز كل القواعد، ومكانه السيرفر فقط.

وحادثة 2026 تخص شي ثاني: إذا مشروعك كان عام ولصقت مفتاح في المحادثة أو الكود، ممكن أحد شافه.

كيف تتأكد بنفسك

جرّب هذي على منتجك أنت فقط:

1. RLS على كل جدول: في لوحة Supabase افتح Table Editor، وأي جدول مكتوب جنبه RLS disabled مكشوف. إذا قاعدة بياناتك على Lovable Cloud وما عندك لوحة Supabase، افتح Database من قائمة More في المشروع، واعتمد على فحص Lovable في الخطوة 5.
2. القواعد مو مفتوحة للكل: افتح صفحة Policies، ودوّر على أي قاعدة شرطها true أو موجهة لـ anon. هذا مقبول فقط لبيانات عامة فعلًا، مثل قائمة منتجات المتجر، مو للمستخدمين أو الطلبات.
3. جرّب كزائر وكمستخدم ثاني: افتح منتجك في نافذة خاصة بدون تسجيل دخول، واضغط F12، وفي تبويب Network شوف ردود الطلبات اللي فيها /rest/v1/. إذا رجعت بيانات أشخاص، فيه مشكلة. بعدها سجّل بحسابين وتأكد إن الثاني ما يشوف بيانات الأول.
4. ما فيه مفتاح سري في الواجهة: في تبويب Sources ابحث (Ctrl+Shift+F) عن service_role و sb_secret_ و sk_ و sk-. المفتاح العام طبيعي يظهر، هذي لا.
5. فحص Lovable: من صفحة Security في مشروعك شغّل Quick scan، وبعده Deep scan. الأول يدوّر على جداول بدون RLS، والثاني يمر على الصلاحيات والمفاتيح في الكود. Lovable نفسها تقول إن الفحصين ما يضمنون أمان كامل.
6. إذا مشروعك كان عام: أي مفتاح سري كان في محادثته أو كوده بين 3 فبراير و 20 أبريل 2026، اعتبره مكشوف وغيّره اليوم.

الحل اللي لا تسويه

• تعطيل RLS أو قاعدة شرطها true عشان يختفي خطأ. هذا بالضبط اللي كشف بيانات المنتجات في 2025.
• تحط المفتاح السري في الواجهة عشان «يشتغل». أي زائر ياخذه ويتحكم في قاعدة بياناتك.
• تكتفي بإن الفحص طلع أخضر. الفحص يساعد، لكن Lovable نفسها تقول إنه ما يضمن أمان كامل، وإن عميل ما يشوف طلبات عميل ثاني ما يتأكد منه إلا اختبار بحسابين.
• تترك Lovable بسبب العناوين فقط. مشكلة 2025 كانت في القواعد، وبتلحقك في أي منصة تكلّم Supabase من المتصفح.

الحل الصح

• RLS مفعّل على كل جدول، وقواعد تقول بالضبط مين يشوف إيش، غالبًا بشرط إن user_id يساوي auth.uid(). التفاصيل في درس new row violates row-level security policy.
• أي مفتاح سري في السيرفر فقط، داخل Edge Function وأسرار Supabase.
• أي مفتاح كان مكشوف تلغيه وتنشئ بداله، قبل ما تصلّح الكود. الخطوات في مفتاح OpenAI انكشف؟.
• المشروع خاص، وبعد كل تعديل كبير من الذكاء الاصطناعي تعيد الفحص وتجرّب بحسابين.

تبي أحد يتأكد منها؟

إذا عندك جداول كثيرة وما تدري أي منها مفتوح، تدقيق جاهزية الإطلاق يمر عليها كلها ويعطيك تقرير مكتوب. إذا عندك سؤال محدد، مكالمة استشارية تكفي. فحوصات أكثر في 5 ثغرات في تسجيل الدخول، ومشاكل ثانية نشوفها في Lovable و Supabase.

المصادر

• Statement on CVE-2025-48757 (mattpalmer.io)
• CVE-2025-48757 (mattpalmer.io)
• NVD - CVE-2025-48757
• Lovable changelog
• Lovable-hosted app littered with basic flaws exposed 18K users, researcher claims (theregister.com)
• Our response to the April 2026 incident | Lovable
• Security overview (docs.lovable.dev)
• API keys | Supabase Docs