Między 17 a 21 października 2026 wyciekły klucze API do AI w trzech różnych miejscach: w usłudze OpenCode Console, w paczce LiteLLM i na platformie hostingowej Railway. Każdy z tych incydentów przebiegał inaczej, ale łup był za każdym razem ten sam: klucze do OpenAI, Anthropic i innych dostawców AI.
Jeśli Twoja firma ma automatyzację w n8n albo Make, chatbota na stronie albo integrację zrobioną przez freelancera, to prawie na pewno gdzieś leży Twój klucz API. Najczęściej nie u Ciebie, tylko u pośrednika.
Poniżej znajdziesz, co się stało, i checklistę, którą przejdziesz w 30–45 minut.
Dlaczego klucz API jest jak numer karty kredytowej
Co to jest klucz API? To ciąg znaków, którym Twój program przedstawia się dostawcy AI, np. OpenAI albo Anthropic. Dostawca nie sprawdza, kto go wpisał. Widzi tylko klucz i nalicza opłatę na konto, do którego klucz należy.
Ile kosztuje klucz API? Sam w sobie nic. Płacisz za każde użycie, także za cudze. Dlatego klucz API OpenAI czy klucz API ChatGPT trzeba traktować jak numer firmowej karty płatniczej, a nie jak zwykłe hasło.
Jak to wygląda w praktyce? Po wycieku z OpenCode Console użytkownicy zgłaszali na Reddicie i X, że niektórym ktoś w ciągu jednej nocy nabił ponad 1700 USD nieautoryzowanych opłat (BleepingComputer). Według relacji zebranych przez TechCrunch u kilku osób było to ponad 1000 USD, u innych kilkaset dolarów. To relacje użytkowników, nie dane podane przez OpenCode.
Co się stało: trzy incydenty w pigułce
OpenCode Console, 17 października
W sobotę 17.10 OpenCode ogłosił, że poprzedniej nocy doszło do włamania. Ucierpiało 1,4% użytkowników OpenCode Console, czyli usługi online, a nie samego programu. Współzałożyciel Dax Raad zaznaczył, że aplikacja open source i wiersz poleceń nie były objęte włamaniem. Wyciekły klucze dostawców (m.in. OpenAI, Anthropic, Google), które użytkownicy zapisali w swoich workspace'ach w Console.
Poszkodowani dostali maila. Kto go nie dostał, według OpenCode nie jest objęty. Firma nie ujawniła, jak włamywacz dostał się do systemu. Zaleciła unieważnić klucze i wygenerować nowe bezpośrednio u każdego dostawcy (TechCrunch, komunikat OpenCode).
LiteLLM 1.107.0, 21 października
LiteLLM to popularna biblioteka do łączenia aplikacji z różnymi modelami AI. Wydanie 1.107.0 opublikowane na PyPI i jako obrazy Dockera zawierało program kradnący dane dostępowe oraz backdoora (SafeDep).
Złośliwy kod uruchamiał się przy starcie dowolnego procesu Pythona na komputerze lub serwerze, nawet takiego, który z LiteLLM nie korzysta. Kradł m.in. klucze SSH, dane dostępowe do chmury (AWS, Azure, GCP), tokeny narzędzi AI, hasła zapisane w przeglądarce i klucze dostawców AI zapisane w bazie LiteLLM.
Złośliwa wersja była na PyPI niecałe dwie godziny, obrazy Dockera około dwóch i pół godziny. Czyste wersje to 1.106.2, 1.107.0rc1 i 1.107.0rc2. Kod na GitHubie był czysty.
Najważniejsza lekcja jest taka: atakujący przejął dane logowania trzech deweloperów LiteLLM, a oficjalny proces wydań sam zbudował, podpisał i opublikował zatrutą paczkę. Czyli nawet oficjalna paczka z oficjalnego źródła może być zainfekowana. To nie znaczy, że LiteLLM to zły produkt. Znaczy, że ten sam scenariusz może spotkać każdą bibliotekę. (Raport LiteLLM: litellm.ai).
Railway, 21 października
Rano 21.10 Railway, platforma do hostowania aplikacji, wykrył nietypową aktywność w systemach przechowujących zmienne środowiskowe klientów. Osoba nieuprawniona mogła uzyskać dostęp do zaszyfrowanych zmiennych, a część z nich odczytać (Railway). W takich zmiennych bywają klucze API, hasła do baz danych i dane do rejestrów.
Railway pisze, że problem może dotyczyć części użytkowników, ale liczby nie podaje. Mimo to zaleca wszystkim klientom natychmiastową wymianę wszystkich zmiennych środowiskowych i przejrzenie logów. Firma powiadomiła dostawców AI, żeby prewencyjnie unieważnili klucze, i wstrzymała wdrożenia na czas dochodzenia.
Według Railway incydent to część serii ataków na firmy platformowe, których celem jest dostęp do dostawców AI. To ocena Railway, nie ustalony fakt. Ale pasuje do obrazu całego tygodnia.
Trzy incydenty w jednej tabeli
| Kiedy | Co wyciekło | Kogo dotyczy | Co zalecono | |
|---|---|---|---|---|
| OpenCode Console | 17.10 | klucze dostawców AI zapisane w Console | 1,4% użytkowników Console (powiadomieni mailem) | unieważnić i wymienić klucze u dostawców |
| LiteLLM 1.107.0 | 21.10 | klucze, hasła, dane do chmury z zainfekowanej maszyny | kto zainstalował wersję 1.107.0 z PyPI lub Dockera | czyste wersje: 1.106.2, 1.107.0rc1, 1.107.0rc2 |
| Railway | 21.10 | część zmiennych środowiskowych klientów | „subset of users”, bez liczby | wszyscy klienci: wymienić wszystkie zmienne |
Wspólny mianownik? W żadnym z tych przypadków klucz nie wyciekł przez błąd właściciela. Wyciekł u pośrednika: w usłudze online, w paczce oprogramowania, na hostingu.
To nie tylko problem Doliny Krzemowej
Nie znaleźliśmy polskich publikacji o tych incydentach (stan na 22.10). Ale podobną sytuację mieliśmy u siebie we wrześniu 2026: po włamaniu Fakturownia unieważniła klientom klucze API (Niebezpiecznik). Opisaliśmy to w tekście o wycieku danych z Fakturowni.
Wniosek jest prosty: każda usługa, której dajesz swój klucz, staje się miejscem, z którego ten klucz może wyciec.
Gdzie w małej firmie leżą klucze do AI
Zanim przejdziesz do checklisty, sprawdź te miejsca. Klucze API w n8n i Make to tylko początek:
- n8n: w zapisanych danych dostępowych (credentials). n8n szyfruje je kluczem tworzonym przy pierwszym uruchomieniu i zapisanym w folderze ustawień na serwerze (dokumentacja n8n). W praktyce: kto ma kopię serwera n8n razem z tym kluczem, ma też dostęp do Twoich kluczy API.
- Make: w połączeniach z OpenAI czy Anthropic, które ktoś kiedyś skonfigurował w scenariuszach.
- Plik
.envna serwerze lub hostingu: tam zwykle trafiają zmienne środowiskowe. Więcej o tym, jak agenci AI korzystają ze zmiennych środowiskowych, piszemy w tekście o agencie AI na firmowym komputerze. - Kod strony albo chatbota: jeśli klucz siedzi w kodzie widocznym w przeglądarce, ma go każdy odwiedzający.
- Skrzynka mailowa, Slack, arkusz „z hasłami”: klucz wysłany kiedyś w wiadomości nadal tam jest.
- Laptop lub konto freelancera albo agencji: często to oni zakładali integrację i mają klucz u siebie.
Jeśli n8n stoi na Twoim serwerze, ustal, kto go aktualizuje. Przy krytycznych lukach w PHP to pytanie wraca jak bumerang.
Checklista na 30–45 minut
1. Zrób spis kluczy
Weź kartkę albo arkusz. Dla każdego klucza zapisz: u jakiego dostawcy jest, gdzie jest wpisany, kto go zna i do czego służy.
Gdzie jest klucz API OpenAI
Swoje klucze (po angielsku OpenAI API key) zobaczysz w panelu konta u dostawcy, tak samo w konsoli Anthropic. Panel nie powie Ci jednak, gdzie każdy z nich jest wpisany. Tę część spisu musisz zrobić sam albo z osobą, która stawiała integracje.
Klucz, którego nikt nie potrafi przypisać do konkretnej integracji, to kandydat do usunięcia.
2. Sprawdź zużycie od 16 października
Wejdź w panel zużycia u OpenAI i Anthropic i przejrzyj okres od 16.10. Szukaj nietypowych skoków: nocnych pików, modeli, których nie używasz, kwot wyższych niż zwykle. Każdy taki skok to sygnał alarmowy.
3. Ustaw limity wydatków
U Anthropic każdy poziom konta ma miesięczny limit wydatków organizacji. Możesz ustawić własny, niższy limit, a dodatkowo limity dla poszczególnych workspace'ów (dokumentacja Anthropic). Limit nie zatrzyma wycieku, ale ograniczy rachunek, jeśli do niego dojdzie.
Sprawdź też ustawienia rozliczeń u pozostałych dostawców, z których korzystasz.
4. Wymień klucze, które mogły wyciec
Wymień klucze od razu, jeśli:
- używałeś OpenCode Console i dostałeś maila od OpenCode,
- Twoja aplikacja stoi na Railway (Railway zaleca to wszystkim klientom),
- ktoś 21.10 instalował albo aktualizował LiteLLM i mógł trafić na wersję 1.107.0.
Przy LiteLLM sama wymiana kluczy AI nie wystarczy. Złośliwy kod kradł też hasła z przeglądarki, klucze SSH i dane do chmury, a backdoor mógł pobrać dodatkowy kod. Taką maszynę oddaj komuś od IT.
Jak wygenerować nowy klucz API
Kolejność ma znaczenie, bo inaczej zatrzymasz własne automatyzacje:
- Wygeneruj nowy klucz w panelu dostawcy.
- Podmień go we wszystkich integracjach ze spisu z kroku 1.
- Przetestuj, czy automatyzacje działają.
- Dopiero teraz unieważnij stary klucz.
5. Jeden klucz to jedna integracja albo jedna osoba
OpenAI wprost zaleca osobny klucz dla każdego członka zespołu, a dzielenie się kluczem jest niezgodne z zasadami (OpenAI). My rozszerzamy to też na integracje: osobny klucz dla n8n, osobny dla chatbota, osobny dla freelancera. Gdy jeden wycieknie, wymieniasz jeden, a reszta działa.
OpenAI pozwala też tworzyć klucze projektowe z datą wygaśnięcia i mocno to zaleca, razem z regularną rotacją. Administrator może wymusić maksymalny czas życia klucza.
6. Sprawdź freelancera i agencję
Zapytaj wprost: czy masz nasz klucz na swoim laptopie albo koncie? W jakich narzędziach go wpisałeś? Po zakończeniu współpracy klucz wymieniasz. Zawsze, nawet jeśli rozstajecie się w zgodzie.
7. Klucz nigdy w kodzie strony ani w aplikacji mobilnej
Według OpenAI klucz umieszczony w kodzie strony lub aplikacji mobilnej może przejąć każdy i generować koszty na Twoje konto. Klucz w repozytorium kodu to też częsta droga wycieku. Zalecane miejsce to zmienne środowiskowe po stronie serwera (OpenAI).
A co z RODO?
Sam wyciek klucza do API OpenAI czy Anthropic nie jest automatycznie naruszeniem ochrony danych osobowych.
Sprawa zmienia się, gdy przez ten wyciek ktoś mógł dostać się do danych osobowych. Przykład z Railway: w tych samych zmiennych środowiskowych co klucze AI często leżą hasła do baz danych, a w bazie dane klientów.
Jeśli tak było u Ciebie, sprawdź z osobą odpowiedzialną za RODO (administratorem danych lub IOD), czy to naruszenie do zgłoszenia. Zgodnie z art. 33 RODO naruszenie zgłasza się do UODO bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od jego stwierdzenia, chyba że ryzyko dla osób jest mało prawdopodobne (UODO).
Co zrobić, gdy już widzisz obce zużycie
- Unieważnij klucz u dostawcy. Natychmiast, nawet jeśli część automatyzacji na chwilę stanie.
- Wygeneruj nowy i podmień go w integracjach według kolejności z kroku 4.
- Sprawdź rachunek: od kiedy trwa obce zużycie i ile kosztowało.
- Napisz do supportu dostawcy w sprawie spornych opłat. Opisz, kiedy zaczęło się nietypowe zużycie i kiedy unieważniłeś klucz. Zwrotu nikt Ci nie gwarantuje, ale bez zgłoszenia na pewno go nie dostaniesz.
- Ustaw limit wydatków, jeśli jeszcze go nie masz.
Jeśli klucz leżał na Railway, ten sam zestaw dotyczy kont w AWS i GCP: dezaktywuj klucz, wymień go, przejrzyj logi i rachunki (poradnik Railway).
FAQ
Co to jest klucz API?
To ciąg znaków, którym program loguje się do usługi, np. do OpenAI. Kto ma klucz, ten korzysta z usługi na Twój rachunek. Dlatego chronisz go jak numer karty płatniczej.
Czy używając n8n albo Make jestem zagrożony?
Żaden z trzech opisanych incydentów nie dotyczył n8n ani Make. Ale to w nich zwykle leżą Twoje klucze do AI, więc to od nich zaczynasz spis. Przy n8n na własnym serwerze ważne jest też, kto ma dostęp do serwera i jego kopii, bo razem z kluczem szyfrującym daje to dostęp do zapisanych kluczy.
Czy muszę zgłaszać wyciek klucza do UODO?
Nie automatycznie. Sam klucz do API AI to nie są dane osobowe. Zgłoszenie wchodzi w grę, jeśli przez wyciek ktoś mógł dostać się do danych osobowych, np. do bazy klientów. Wtedy decyzję podejmuje administrator danych lub IOD, a termin to 72 godziny od stwierdzenia naruszenia.
Nie wiesz, gdzie u Ciebie leżą klucze do AI i kto je zna? Zrobimy przegląd Twoich automatyzacji (n8n, Make, integracje), a potem ustawimy limity i rotację kluczy. Napisz do nas.
