A Lovable adatvédelmi incidens 2026-04-22-én kapott hivatalos postmortemet. A cég elismerte, hogy egy backend regresszió miatt adatok szivárogtak ki. A hiba 2026 februárjától 2026 áprilisáig élt észrevétlenül.
A nyilvános Lovable projektek teljes chat-története és forráskódja elérhető volt más felhasználók számára. A privát projektek és a Lovable Cloud nem érintett. A cég Anton Osika és Fabian Hedin aláírásával publikálta a részleteket.
Mi történt a Lovable adatvédelmi incidens során
A Lovable 2024 novemberében indult, és kezdetben minden ingyenes projekt publikus volt. A chat-történet és a forráskód szándékosan nyitott volt. A cél a közösség-alapú remix és tanulás volt a vibe-coding világában.
2025 folyamán a cég fokozatosan szűkítette ezt a hozzáférést. Tavasszal az API-n keresztüli chat-hozzáférést zárta le. Májusban az enterprise felhasználóknál kapcsolta ki a publikus opciót. November végétől minden új projekt privát lett alapértelmezésben.
2026 februárjában egy backend deploy visszahozta a régi viselkedést. A publikus projekteket újra bárki olvashatta, ha megszerezte a projekt linkjét. A regresszió közel két és fél hónapig élt a cég monitoringjában észrevétlenül. A hivatalos postmortem konkrét timeline-t közöl az érintett időszakról.
A javítás két órán belül kiment, miután a probléma publikusan napvilágra került. Ez gyors mérnöki reakció, és jól mutatja a csapat képességeit. A nyolc hétnyi csúszás ennek ellenére komoly kérdést vet fel a tesztlefedettségről. A cég minden jelenleg publikus projektet privátra állít, a hivatalos remix-template-eket leszámítva.
Ez nem pusztán technikai hiba. A probléma jól illusztrálja a no-code és vibe-coding platformok dilemmáját. A biztonság, a gyorsaság és a láthatóság gyakran ütközik. A Lovable most visszamenőleg kommunikál minden érintett felhasználóval, és felülvizsgálja, mely publikus projekteket nyitottak meg idegenek.
Miért bukott el a HackerOne triage
Több kutató is jelezte a hibát HackerOne-on, az első 2026. február 22-én. A Lovable külső triagerei azonban elutasították a bejelentéseket. A triage-csapat formailag helyes döntést hozott egy elavult specifikáció alapján.
A cég által átadott belső dokumentáció még a régi, publikus-alapértelmezésű viselkedést írta le tervezettként. A vulnerability disclosure programok csak annyira működnek, amennyire a triager-képzés aktuális. A Lovable most újrastrukturálja a teljes folyamatot, és minden korábbi bejelentést újra-triagel.
Minden olyan termékváltoztatás, amely userdata-hozzáférést érint, ezentúl automatikusan frissíti a triage-dokumentációt. Ez az intézményi tanulságok klasszikus példája. Hasonló mintát követ a Project Glasswing keretében javasolt iparági gyakorlat. A disclosure-csapat itt a termék kiterjesztése, nem külön entitás.
Külön érdemes kiemelni a kommunikációs hibát. A cég első nyilvános válasza elutasító volt, és nem ismerte el a valódi kockázatot. Ezt a postmortem saját maga minősíti hibának. Az őszinteség mérhető: konkrét dátumok és konkrét folyamat-változások szerepelnek a szövegben.
Mit tanulhatnak ebből a fejlesztők
Három használható tanulság marad. Az első: a backend regresszió ellen csak automatizált biztonsági teszt véd. Az engedély- és láthatósági útvonalakra külön end-to-end tesztsorozat szükséges. A unit-tesztek önmagukban nem pótolják ezt.
Hasonló következtetésre jut a GitHub Copilot automatikus PR-review irányvonala. A CI pipeline-ban piros tesztnek kell megállítania a deployt, ha a láthatóság-matrix változik. Az adatvédelmi tesztek nem egyenértékűek a funkcionális tesztekkel. Külön prioritás és külön felelős szükséges hozzájuk.
A második tanulság: az alapértelmezett biztonság olcsóbb, mint utólag helyrepofozni. A Lovable 2025-ben azért lépett privát-alapértelmezésre, mert a nem-technikai felhasználók félreértették a publikus opciót. Az iparági konszenzus egyértelmű ezen a ponton. A megbízható AI-rendszerek alapelvei szintén a konzervatív alapbeállítást tartják normának.
A harmadik tanulság: a disclosure folyamat csak annyira jó, amennyire friss a triage-brief. Aki HackerOne-t vagy hasonló platformot használ, annak minden érzékeny termékváltoztatásnál frissítenie kell a triager-dokumentációt. A Lovable blogja most publikusan követi ezt a ciklust, és külön figyelmet kap a product–triage szinkron.
A mostani Lovable adatvédelmi incidens postmortem nem mentség, hanem működési minta. A gyors javítás, a nyílt felelősségvállalás és a folyamat-átalakítás együtt mutatja, mit jelent felnőtté válni egy vibe-coding platformnak. A következő lépés minden fejlesztőcsapatnak ugyanaz: audit a saját láthatóság-állapotaira és a disclosure-dokumentáció frissessége.
