Het AI-platform Lovable, gewaardeerd op 6,6 miljard dollar, heeft zijn privacybeleid aangepast nadat een onderzoeker kon aantonen dat gratis accounts toegang gaven tot privégegevens van andere gebruikers. In een bericht op X ontkent het bedrijf dat het om een datalek gaat en wijst het op onduidelijke documentatie als oorzaak.
In het kort:
- Gratis accounts konden broncode, wachtwoorden en chats van andere gebruikers inzien.
- Projecten van voor november 2025 bleven onbedoeld publiek toegankelijk.
- Lovable ontkent een datalek en noemt het een documentatie-fout.
- HackerOne onderzoekt hoe de melding oorspronkelijk is afgehandeld.
De kwetsbaarheid werd openbaar nadat publieke druk toenam. Inmiddels heeft Lovable de toegang tot chats op publieke projecten alsnog geblokkeerd en is het privacybeleid aangepast. Wat precies gewijzigd is in het beleid, heeft het bedrijf niet publiek uitgesplitst.
We were made aware of concerns regarding the visibility of chat messages and code on Lovable projects with public visibility settings.
— Lovable (@Lovable) April 20, 2026
To be clear: We did not suffer a data breach.
Our documentation of what “public” implies was unclear, and that’s a failure on us.
Specifically…
Wat is er precies gebeurd bij Lovable?
Een beveiligingsonderzoeker ontdekte dat projecten op Lovable die als “public” gemarkeerd stonden, meer prijsgaven dan gebruikers verwachtten. Via een gratis account kon een willekeurige bezoeker niet alleen de zichtbare output zien, maar ook de onderliggende laag met broncode, opgeslagen inloggegevens en chatgeschiedenissen.
De technische oorzaak is een BOLA-kwetsbaarheid, voluit Broken Object Level Authorization. In gewone taal: het systeem controleerde onvoldoende of de ingelogde gebruiker daadwerkelijk eigenaar was van de data die opgevraagd werd. Projecten aangemaakt vóór november 2025 bleven daardoor onbedoeld publiek toegankelijk, ook als de maker aannam dat ze afgeschermd waren.
Welke gegevens lagen op straat?
Drie soorten data waren raakbaar via de kwetsbaarheid:
- Broncode van projecten die gebruikers op het platform bouwden
- Wachtwoorden en database-inloggegevens die in de projectconfiguratie waren opgeslagen
- Chatgeschiedenissen tussen gebruikers en het Lovable-platform
Het grootste risico zit in het tweede punt. Als een gebruiker database-credentials of API-keys in de configuratie van een project had staan, en dat project stond als “public” gemarkeerd, konden derden die gegevens direct inzien en mogelijk misbruiken om in te loggen op achterliggende systemen.
Waarom ontkent Lovable dat het een datalek is?
Lovable verzet zich openlijk tegen het woord “datalek”. Het bedrijf schrijft in zijn bericht op X:
“We did not suffer a data breach. Our documentation of what ‘public’ implies was unclear, and that’s a failure on us.”
De redenering: de zichtbaarheid van data was een bewuste keuze in het productontwerp voor projecten met de “public”-instelling. Het probleem zou zitten in de documentatie, die onvoldoende duidelijk maakte wat “public” in de praktijk betekende.
Die verdediging is onderweg een keer verschoven. Aanvankelijk stelde Lovable dat ook de code-zichtbaarheid “by design” was. Toen bleek dat database-inloggegevens mee gingen, werd de schuld deels verschoven naar HackerOne, het platform waar beveiligingsonderzoekers kwetsbaarheden melden. Volgens Lovable zouden rapporten daar zijn gesloten omdat medewerkers de openheid als bedoeld beschouwden. HackerOne onderzoekt nu hoe de oorspronkelijke melding is afgehandeld.
Of de kwetsbaarheid juridisch kwalificeert als datalek onder de AVG, de Europese privacywetgeving, is geen marketing-vraag maar een juridische. Bij blootstelling van persoonsgegevens die niet voor derden bedoeld waren, geldt doorgaans een meldplicht bij de Autoriteit Persoonsgegevens, ongeacht of de blootstelling kwaadwillig was of door een configuratiefout ontstond.
Wat betekent dit als je Lovable gebruikt?
Voor ondernemers en ontwikkelaars die met het platform werken, zijn drie dingen veranderd. Toegang tot chats op publieke projecten is inmiddels geblokkeerd. Het privacybeleid is aangepast. En de eigen oude projecten verdienen nu aandacht, vooral die van voor november 2025 die nog steeds op “public” staan.
Stap 1. Controleer welke projecten “public” staan
Log in op Lovable en inventariseer welke projecten een publieke zichtbaarheidsinstelling hebben. Projecten van voor november 2025 zijn de risicogroep.
Stap 2. Zet projecten met gevoelige data op privé
Bevat een project wachtwoorden, API-keys, database-credentials of klantdata? Wijzig de zichtbaarheid direct naar privé en ga ervan uit dat wat eerder publiek stond mogelijk is ingezien.
Stap 3. Roteer blootgestelde inloggegevens
Als je database-inloggegevens of API-keys in een publiek project had staan, behandel die dan als gecompromitteerd. Maak nieuwe keys aan, wijzig wachtwoorden op de betrokken systemen en controleer logs op ongebruikelijke toegang.
Stap 4. Documenteer als je klantdata verwerkt
Verwerk je persoonsgegevens in Lovable-projecten? Dan is de vraag of hier sprake is van een datalek in AVG-zin relevant voor jouw eigen meldplicht richting de Autoriteit Persoonsgegevens. Bij twijfel: overleg met je DPO of privacyjurist, en leg vast welke projecten blootgesteld konden zijn en vanaf wanneer.
Stap 5. Volg de uitkomst van het HackerOne-onderzoek
Het onderzoek naar hoe de oorspronkelijke melding is afgehandeld loopt nog. De uitkomst kan invloed hebben op hoe serieus Lovable in het vervolg omgaat met gemelde kwetsbaarheden, en daarmee op het vertrouwen dat je aan het platform kunt geven voor productiewerk.
