Pięć wywołań API z darmowego konta wystarczyło, żeby badacz bezpieczeństwa pobrał kod źródłowy cudzych aplikacji, hasła do baz danych i historie czatów z AI. Platforma Lovable, jedno z największych narzędzi do tak zwanego vibe codingu, przez 48 dni ignorowała zgłoszenie tej luki. Pierwsza oficjalna reakcja firmy brzmiała “to nie był wyciek”. Druga mówiła “takie zachowanie było zamierzone”. Trzecia, wydana dzień później, przyznawała błąd i zapowiadała poprawki. Do tego wszystkiego doszło na oczach firm takich jak Uber, Zendesk i Deutsche Telekom, których pracownicy budowali na Lovable aplikacje pokazywane w serwisie jako publiczne. Poniżej rozkładamy co dokładnie poszło nie tak, dlaczego luka typu BOLA jest klasycznym błędem projektowym i co powinien zrobić każdy, kto zbudował coś w Lovable przed listopadem 2025.
Na czym dokładnie polegała luka BOLA w Lovable
Luka nazywa się BOLA, czyli Broken Object Level Authorization. W wolnym tłumaczeniu to “zepsuta kontrola dostępu na poziomie obiektu”. Od lat zajmuje ona pierwsze miejsce w rankingu OWASP API Security Top 10, czyli w oficjalnym spisie najczęstszych błędów w interfejsach API. Mechanizm jest prosty. Serwer sprawdza, czy użytkownik jest zalogowany, ale nie sprawdza, czy ma prawo zobaczyć akurat ten projekt, do którego sięga. Każdy zalogowany widzi wszystko, pod warunkiem że zna identyfikator.
W przypadku Lovable dotyczyło to konkretnego punktu końcowego API o adresie api.lovable.dev/GetProjectMessagesOutputBody. Pięć wywołań z poziomu darmowego konta wystarczało, żeby pobrać pełną historię wiadomości dowolnego projektu. Razem z wiadomościami wracał kod źródłowy, hasła do Supabase, klucze API i dane użytkowników, które aplikacja obsługiwała. Badacz działający pod pseudonimem @weezerOSINT pokazał to na przykładzie duńskiej organizacji non-profit Connected Women in AI. Wyciągnął stamtąd imiona, nazwiska i firmy prawdziwych prelegentek z Accenture Denmark i Copenhagen Business School. Żadna z tych osób nie wiedziała, że jej dane są dostępne z poziomu darmowego konta byle kogo.
To nie jest hakowanie. To jest pięć wywołań API z darmowego konta.
Co tak naprawdę wyciekło z platformy Lovable
Wyciekły trzy rzeczy, z których każda osobno byłaby poważnym problemem. Razem tworzyły scenariusz, w którym napastnik nie potrzebuje żadnego przygotowania technicznego. Pierwsza to kod źródłowy aplikacji. Każdy projekt stworzony na Lovable przed listopadem 2025 był w zasięgu. W kodzie często znajdowały się hasła lub klucze, bo początkujący budowniczy MVP rzadko wiedzą, że nie powinni ich zapisywać na twardo w kodzie. Druga rzecz to dane dostępowe do baz Supabase, czyli dokładnie te klucze, których wyciek pozwala od razu podłączyć się do bazy i zobaczyć wszystkie rekordy. Trzecia to historie czatów z AI, w tym polecenia systemowe, reasoning modelu i wszystko, co użytkownik kiedykolwiek wpisał, budując aplikację.
Na liście poszkodowanych znalazły się nazwy, które brzmią poważnie. The Register wymienia Uber, Zendesk i Deutsche Telekom, czyli firmy, których pracownicy tworzyli na Lovable projekty publiczne. Niezależni badacze dokładają do tej listy konta związane z NVIDIA, Microsoft i Spotify. Skala dokładnej ekspozycji nie została ogłoszona, ale według analizy Superblocks chodzi o co najmniej 170 aplikacji z poważnie wrażliwymi danymi. Lovable ma kilkaset tysięcy użytkowników, więc prawdziwa liczba jest prawdopodobnie większa.
Kronika 48 dni – jak zgłoszenie utknęło na HackerOne
Chronologia incydentu sama w sobie jest lekcją o tym, jak nie reagować na zgłoszenia luk. 3 marca 2026 roku badacz @weezerOSINT wysłał raport przez platformę HackerOne, w której Lovable prowadzi program ujawniania luk. Zespół HackerOne sklasyfikował zgłoszenie jako duplikat wcześniejszego raportu i zamknął je bez eskalacji do zespołu Lovable. W oficjalnym wyjaśnieniu HackerOne później przyznała, że operator “myślał, iż widoczność czatów w projektach publicznych jest zachowaniem zamierzonym”.
Przez 48 dni nic się nie działo. Raport istniał, ale nikt w Lovable go nie widział ani nie analizował. Dopiero 20 kwietnia 2026 roku badacz opublikował swoje ustalenia na platformie X, załączając zrzuty ekranu odpowiedzi API oraz konkretne dane, które udało mu się pobrać. Post miał w ciągu doby ponad milion wyświetleń, pięć tysięcy polubień i prawie tysiąc udostępnień. Dopiero wtedy Lovable zareagowało. Luka została załatana tego samego dnia, co publikacja.
HackerOne zamknęła raport jako duplikat. Operator myślał, że widoczność cudzych czatów jest zamierzona.
Gdzieś w tle cały czas działała zasada, że luka istniała dla projektów utworzonych przed listopadem 2025. Nowe projekty były już bezpieczne, bo Lovable zmieniło walidację przy ich tworzeniu. Nikt jednak nie cofnął się do projektów starszych, żeby wyłączyć podatny punkt końcowy. W efekcie dla każdego, kto zbudował coś na Lovable między 2023 a listopadem 2025, ta luka była otwarta przez miesiące.
Trzy wersje wyjaśnień Lovable w 24 godziny
Reakcja Lovable na publiczne ujawnienie zasługuje na osobną analizę. W ciągu doby firma wydała trzy różne oświadczenia, każde z innym tonem i inną narracją. Pierwsze, opublikowane 20 kwietnia, brzmiało: “Nie doszło do wycieku danych”. Lovable tłumaczyło to “niejasną dokumentacją dotyczącą tego, co oznacza publiczny projekt”. Odbiorcy tego komunikatu dostali w praktyce informację, że to oni źle rozumieli regulamin, a nie że coś w platformie nie działało.
Drugie oświadczenie, jeszcze tego samego dnia, szło dalej w tej samej linii. Lovable przekonywało, że udostępnianie kodu w projektach publicznych było “zachowaniem zamierzonym” i “tak zaprojektowanym”. Trzecie wyjaśnienie, wydane 21 kwietnia, przyznawało już błąd. Firma opisała rzeczywisty przebieg wydarzeń. W lutym 2026 roku, przy okazji “ujednolicania uprawnień” w platformie, ktoś przypadkowo przywrócił dostęp do czatów w projektach publicznych. Ten stan utrzymywał się przez dwa miesiące, zanim ktokolwiek zauważył problem.
Ten wzorzec reakcji pokrywa się z tym, co widzieliśmy przy wycieku z Vercel w kwietniu 2026. Firmy coraz częściej publikują najpierw komunikat “nic się nie stało”, a dopiero po presji publicznej przyznają rzeczywisty zakres incydentu. Dla użytkowników to oznacza, że pierwszy komunikat bezpieczeństwa rzadko jest ostatni i warto czekać z oceną incydentu przynajmniej 48 godzin.
Pierwsza Misja AI · Kodożercy
Używasz AI codziennie. Ale czy wiesz jak ono działa?
Kurs Pierwsza Misja AI pokaże Ci, jak naprawdę działają narzędzia AI, które dziś zlecają budowę aplikacji, piszą kod i obsługują klientów. 8 godzin, prawdziwy GPT-4 w ćwiczeniach, certyfikat. Zanim znowu powierzysz AI dane swoich klientów, zacznij rozumieć co się dzieje pod maską.
Sprawdź program kursu →
Co zrobić jeśli masz projekt zbudowany na Lovable
Jeśli korzystałeś z Lovable przed listopadem 2025 roku, są trzy rzeczy, które powinieneś zrobić w najbliższych godzinach. Pierwsza to przyjąć założenie pesymistyczne. Potraktuj wszystkie hasła, klucze API i identyfikatory Supabase, które kiedykolwiek pojawiły się w Twoim projekcie, jako potencjalnie wyciekłe. Zaloguj się do Supabase, otwórz panel Settings i zrotuj klucze. W praktyce oznacza to wygenerowanie nowych kluczy i wklejenie ich w kod aplikacji zamiast starych. Stare klucze unieważnij.
Druga rzecz to weryfikacja, czy nikt nie uzyskał dostępu do Twojej bazy danych w okresie luki, czyli między lutym a kwietniem 2026 roku. Supabase ma w panelu zakładkę z logami aktywności. Sprawdź tam, czy nie pojawiają się połączenia z adresów IP, których nie rozpoznajesz. Jeśli widzisz logowania z nietypowych lokalizacji albo masowe zapytania do tabel z danymi użytkowników, masz problem, który warto zgłosić do UODO. Przypomnij sobie, że RODO obejmuje każdy taki incydent, nawet jeśli ofiarą jesteś Ty, a nie Twój klient.
Trzecia rzecz to zastanowienie się nad ogólną higieną budowania w narzędziach typu vibe coding. Platformy takie jak Lovable zachęcają do tego, żeby testować, eksperymentować i publikować szybko. Efektem ubocznym bywa to, że klucze i hasła lądują w projektach publicznych, bez świadomości tego, co znaczy “publiczny” w danym momencie. Dobra praktyka polega na tym, żeby nigdy nie umieszczać prawdziwych kluczy w projektach przeznaczonych do demo. Używaj do tego osobnych kont i baz testowych. Więcej o tym podejściu pisaliśmy w artykule vibe coding – co to jest i jak nie wpaść w pułapkę.
FAQ – Najczęstsze pytania o wyciek Lovable
Czy mój projekt w Lovable jest zagrożony, jeśli zbudowałem go po listopadzie 2025?
Według Lovable luka dotyczyła projektów utworzonych przed listopadem 2025 roku. Nowsze projekty miały już poprawną walidację dostępu. Mimo to warto przejrzeć historię czatów i upewnić się, że nie umieściłeś tam kluczy, których rotacja byłaby kosztowna.
Czy Lovable poinformuje mnie, jeśli mój projekt wyciekł?
Na dzień 21 kwietnia 2026 roku Lovable nie opublikowało listy konkretnych poszkodowanych projektów. W dotychczasowych komunikatach firma odnosi się do problemu ogólnie. Jeśli chcesz mieć pewność, rotacja kluczy i audyt logów to Twoja decyzja, nie Lovable.
Czy mogę pozwać Lovable za wyciek moich danych?
Zależy od tego, gdzie jesteś zarejestrowany i jakie dane wyciekły. W Unii Europejskiej RODO daje Ci prawo do informacji o incydencie, naprawy szkody i zgłoszenia sprawy do UODO. Lovable działa przez europejski podmiot, więc te przepisy mają zastosowanie. Skonsultuj się z prawnikiem, jeśli wyciekły dane Twoich klientów.
Czy warto w ogóle używać narzędzi typu Lovable do budowy prawdziwych aplikacji?
Odpowiedź zależy od tego, jakie dane obsługuje aplikacja. Dla MVP bez prawdziwych danych użytkowników platformy AI są świetnym skrótem. Dla systemów produkcyjnych z danymi osobowymi potrzebujesz kontroli, której vibe coding dzisiaj nie daje. Najlepsze narzędzia łączą szybkość AI z tradycyjnym procesem code review i audytem bezpieczeństwa.
Podsumowanie
Wyciek Lovable to nie tyle historia o jednej podatnej platformie, co o tym, co się dzieje, gdy szybkość budowania wyprzedza dyscyplinę bezpieczeństwa. BOLA to klasyczny błąd, który można znaleźć w każdym poradniku OWASP od lat. Pięć wywołań API z darmowego konta wystarczyło, żeby obejść ochronę, której firma nie zbudowała. Czterdzieści osiem dni ciszy po zgłoszeniu pokazuje, że proces reagowania na luki bywa równie słaby jak sama platforma. Trzy wersje komunikatów w 24 godziny pokazują, że nawet firmy z nowoczesnym brandem potrafią reagować jak w poprzedniej epoce.
Dla Ciebie jako użytkownika wnioski są trzy. Traktuj wszystkie klucze w projektach Lovable jako potencjalnie wyciekłe i rotuj je teraz. Sprawdź logi aktywności Supabase pod kątem nieznanych połączeń. Przy kolejnym projekcie w dowolnym narzędziu AI do budowy aplikacji zadawaj sobie pytanie, co znaczy “publiczny” dziś, co znaczyło wczoraj i jak to się zmieni po kolejnej aktualizacji. To jedyne pytanie, które ochroni Twoje dane, niezależnie od tego, ile razy platforma w komunikacie użyje słowa “nowoczesny”.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
