BlogDroit du numériqueProtection des données & vie privéeFuite de données Lovable : vibe coding, CVE critique et vos recours RGPDFuite de données Lovable : vibe coding, CVE critique et vos recours RGPD
Une faille de sécurité majeure a été découverte dans Lovable, l'une des principales plateformes de vibe coding — ces outils no-code IA qui permettent de générer des applications web en quelques minutes. La vulnérabilité, signalée il y a 48 jours et restée ouverte, permettait à n’importe quel compte gratuit d’accéder au code source, aux credentials de base de données, aux historiques de chat IA et aux données clients d’autres utilisateurs. Des clients comme Uber, Zendesk et Deutsche Telekom seraient concernés.
La fuite Lovable est-elle confirmée ?
Oui. Lovable a reconnu dans un troisième communiqué officiel que l’incident était lié à une régression de février 2026 qui a réactivé accidentellement l’accès aux chats des projets publics lors d’une unification des permissions backend. La faille technique est donc confirmée par l’entreprise elle-même. Ce qui reste débattu est la qualification : « data breach » ou « misconfiguration ». Sous RGPD, la distinction importe peu si des données personnelles ont été exposées sans autorisation.
Qu’est-ce que le vibe coding et pourquoi pose-t-il un problème de sécurité ?
Le vibe coding désigne la génération d’applications web via des outils d’IA comme Lovable, Cursor ou Bolt. Ces plateformes permettent de créer une app fonctionnelle en quelques minutes, sans compétences techniques. Le problème structurel : les modèles de langage optimisent pour « ça fonctionne », pas pour « c’est sécurisé ». Ils répètent systématiquement une confusion entre authentification (qui es-tu ?) et autorisation (que peux-tu voir ?). Une étude Wiz estime que 20 % des apps vibe-codées présentent des vulnérabilités sérieuses, et Veracode note que 45 % du code généré par LLM contient des vulnérabilités classées OWASP Top-10.
🚨 À retenir : La vulnérabilité CVE-2025-48757 a été identifiée sur Lovable avec un score CVSS de 9,3 sur 10 (Critical). Un scan de 1 645 applications construites sur la plateforme a révélé que 170 d’entre elles (~10 %) étaient vulnérables, exposant 303 endpoints API.
Comment fonctionnait la faille ?
La faille était de type BOLA (Broken Object Level Authorization) : en effectuant 5 appels API simples, un utilisateur quelconque pouvait accéder aux données d’un autre projet. Aucune technique sophistiquée n’était requise. Pour les applications générées par la plateforme, la faille dite RLS (Row Level Security sur Supabase) était encore plus basique : il suffisait de modifier un chiffre dans une URL pour accéder aux données d’un autre utilisateur.
| Faille | Cible | Méthode | Gravité |
|---|---|---|---|
| BOLA (plateforme Lovable) | Projets d’autres utilisateurs | 5 appels API | CVSS 9,3 — Critical |
| RLS Supabase (apps générées) | Données d’autres comptes dans l’app | Modification d’un paramètre URL | Élevée |
La gestion de crise de Lovable : trois versions en une journée
Ce qui est également révélateur, c’est la manière dont Lovable a géré la divulgation :
- 1er communiqué : pas de breach, juste une « documentation unclear » sur la notion de projet « public »
- 2e communiqué : « comportement intentionnel » et « by design » pour les projets publics (sauf pour les clients enterprise où le paramètre avait été désactivé depuis mai 2025 — contradiction flagrante)
- 3e communiqué : mea culpa partiel, régression accidentelle de février 2026 reconnue, et rejet partiel de la faute sur HackerOne dont les triageurs auraient fermé les rapports sans escalade
👉 HackerOne est-il responsable ?
Lovable affirme que les reports soumis sur la plateforme de bug bounty HackerOne ont été fermés sans escalade par les triageurs, qui auraient considéré l’accès aux chats publics comme un comportement voulu. HackerOne n’a pas encore commenté et « review les détails ». La vulnérabilité avait été signalée 48 jours avant la divulgation publique.
Ce que cela signifie pour les utilisateurs et leurs données
Si vous avez créé une application sur Lovable avant novembre 2025, vos données de projet — code source, historiques de conversation avec l’IA, credentials de bases de données, données de vos propres clients — ont pu être accessibles à n’importe quel tiers. Sous RGPD, si des données personnelles de vos clients étaient stockées dans ces bases, vous êtes potentiellement co-responsable d’un incident de sécurité au sens de l’article 82 du règlement.
L’article 33 du RGPD impose une notification à la CNIL sous 72 heures en cas de violation de données à caractère personnel. Si vos données clients ont été exposées via Lovable, cette obligation s’applique à vous en tant que responsable de traitement — indépendamment du fait que la faille soit imputable à votre sous-traitant technique.
Quels recours pour les victimes ?
- Vérifier si vos projets Lovable étaient configurés en « public » avant novembre 2025
- Auditer les données clients potentiellement exposées
- Notifier la CNIL si des données personnelles sont concernées (article 33 RGPD)
- Notifier les personnes concernées si le risque pour leurs droits et libertés est élevé (article 34 RGPD)
- Engager la responsabilité de Lovable en tant que sous-traitant au sens de l’article 28 RGPD si un DPA (équivalent d’un contrat de traitement) était en place
- Déposer plainte auprès de la CNIL ou devant les juridictions compétentes pour obtenir réparation du préjudice
Vous utilisez ou avez utilisé Lovable ou une application vibe-codée pour gérer des données clients ? Décrivez votre situation pour être mis en relation avec un avocat spécialisé en droit du numérique et protection des données.
Les questions des internautes
Une faille BOLA permettait à tout compte gratuit d’accéder au code source, aux credentials et aux données clients d’autres utilisateurs. Lovable confirme une régression de février 2026 ayant réactivé accidentellement cet accès. Tous les projets antérieurs à novembre 2025 peuvent être concernés.
Le vibe coding génère des apps via IA (Lovable, Cursor, Bolt) sans compétences techniques. Problème : les LLM optimisent pour la fonctionnalité, pas la sécurité. Ils confondent authentification et autorisation. Résultat : selon Wiz, 20 % des apps vibe-codées ont des vulnérabilités sérieuses et 45 % du code LLM contient des failles OWASP Top-10.
En tant que responsable de traitement, deux obligations s’imposent : notifier la CNIL sous 72 h (art. 33 RGPD) et, si le risque est élevé, notifier les personnes concernées (art. 34 RGPD). Cette obligation vaut même si la faille est imputable à votre sous-traitant (Lovable).
Si Lovable était votre sous-traitant (art. 28 RGPD), sa responsabilité peut être engagée pour manquement à l’obligation de sécurisation (art. 32 RGPD). La faille confirmée et le délai de 48 jours entre signalement et correction constituent des éléments à charge. Plainte CNIL ou action judiciaire sont possibles.
✔ Vérifiez si vos projets étaient en mode public avant nov. 2025. ✔ Auditez les données exposées. ✔ Notifiez la CNIL sous 72 h si des données personnelles sont concernées. ✔ Informez les personnes affectées si le risque est élevé. ✔ Consultez un avocat en droit du numérique pour évaluer vos recours.
.png)
