Skradzione klucze AI: jak LiteLLM, Railway i OpenCode zawiodły programistów

W ciągu zaledwie jednego tygodnia w październiku 2026 roku doszło do trzech poważnych wycieków danych. Incydenty dotknęły popularne narzędzie LiteLLM, platformę hostingową Railway oraz usługę OpenCode. We wszystkich trzech przypadkach cyberprzestępcy szukali tego samego: kluczy dostępu do OpenAI, Anthropic, Google i usług chmurowych.

Skradziony klucz API działa jak Twoja karta bankowa w cudzych rękach. Ktoś z niego korzysta, a rachunek trafia do Ciebie. Jeśli podłączałeś AI do swojej strony internetowej, bota lub aplikacji, sprawdź klucze jeszcze dziś. Poniżej znajdziesz prostą instrukcję.

Czym jest klucz API i dlaczego ktoś chce go ukraść?

Klucz API to długi ciąg znaków, na przykład sk-ant-... lub sk-proj-.... Twoja strona lub bot przekazuje go usłudze takiej jak ChatGPT czy Claude. Usługa rozpoznaje klucz i wie, że to Ty korzystasz z jej zasobów — i że to Ty za nie płacisz.

To właściwie karta bankowa bez kodu PIN. Każdy, kto zna jej numer, może wydawać pieniądze. Tyle że płacisz nie on, lecz Ty.

Dlaczego klucze API stały się tak atrakcyjnym celem?

• To prawdziwe pieniądze. Mając cudzy klucz, można za darmo korzystać z drogich modeli AI albo odsprzedawać dostęp. Jeden skradziony klucz może wygenerować rachunek na dziesiątki tysięcy dolarów w ciągu jednej doby.

• Klucze są kupowane hurtowo. Niektóre firmy wykorzystują cudze klucze do pobierania odpowiedzi dużych modeli AI i trenowania na ich podstawie własnych modeli. Nazywa się to destylacją. Na takie klucze istnieje stały popyt.

• Klucze często leżą obok innych poufnych danych. W tym samym miejscu mogą znajdować się hasła do baz danych, dane dostępowe do chmury oraz klucze do systemów płatności. Kradnąc jedno, można zdobyć wszystko.

LiteLLM: zatruta aktualizacja

LiteLLM to popularne narzędzie pośredniczące. Dzięki niemu strony internetowe i boty mogą komunikować się z dziesiątkami usług AI. Jest pobierane około 23 milionów razy tygodniowo.

Co się stało. 21 października cyberprzestępcy opublikowali pod nazwą LiteLLM złośliwą wersję 1.107.0. Była dostępna w PyPI i Dockerze przez około dwie godziny. W tym czasie pobrano ją mniej więcej 49 tysięcy razy.

To tak, jakby ktoś w fabryce podmienił zawartość opakowań z lekami na truciznę. Opakowanie jest oryginalne, producent prawdziwy, ale w środku znajduje się coś niebezpiecznego.

Co robiła złośliwa wersja. Zbierała wszystko, co wartościowe, z komputera lub serwera: hasła zapisane w przeglądarkach, klucze SSH, dane dostępowe do chmury i klucze API usług AI. Instalowała również tzw. tylne drzwi (backdoor), dzięki którym atakujący mógł wrócić w dowolnym momencie. Skradzione klucze zaczęto testować już po kilku godzinach.

Jak to się zaczęło. W maju programiści LiteLLM przypadkowo opublikowali wewnętrzny klucz w publicznym repozytorium GitHub. Nikt go nie wymienił. W październiku atakujący znalazł ten klucz i wykorzystał go do uzyskania dostępu do systemu publikowania aktualizacji.

Wniosek jest prosty. Jeden zapomniany klucz pozostawał publicznie dostępny przez pół roku i doprowadził do opublikowania zainfekowanej aktualizacji, którą pobrano dziesiątki tysięcy razy.

Wszystkie wersje wcześniejsze niż 1.107.0 są bezpieczne. LiteLLM zapowiedziało również ujawnienie kolejnej luki bezpieczeństwa 27 października. Jeśli korzystasz z LiteLLM, śledź aktualizacje dotyczące bezpieczeństwa.

Railway: włamanie do platformy hostingowej

Railway to platforma chmurowa, na której programiści uruchamiają swoje aplikacje. Hasła i klucze przechowywane są tam w tak zwanych zmiennych środowiskowych.

Co się stało. 21 października Railway wykryło podejrzaną aktywność w systemach przechowujących te zmienne. Według firmy atakujący mógł uzyskać do nich dostęp i odszyfrować część danych.

Wyobraź sobie, że ktoś włamał się nie do Twojego mieszkania, lecz do pomieszczenia portiera, w którym znajdują się zapasowe klucze do wszystkich mieszkań w budynku.

Konsekwencje. Railway poprosiło wszystkich klientów o wymianę kluczy i haseł. Wdrażanie aplikacji zostało wstrzymane na około 17 godzin. Użytkownicy zgłaszali, że ich klucze do usług AI były wykorzystywane jeszcze przed oficjalnym ostrzeżeniem. Według badaczy z portfeli kryptowalutowych, których klucze przechowywano na Railway, wyprowadzono około 371 tysięcy dolarów. Samo Railway nie potwierdziło tego powiązania.

Railway uważa, że włamanie było częścią serii ataków na platformy hostingowe, których celem była kradzież kluczy do usług AI. Dwa dni wcześniej podobny incydent zgłosił dostawca hostingu Zeabur.

OpenCode: klucze pozostawione w starym systemie

OpenCode to popularny asystent AI dla programistów. Udostępnia panel internetowy Console, w którym można zapisać klucze API do OpenAI, Anthropic lub Google, aby cały zespół mógł z nich korzystać.

Co się stało. W nocy 16 października atakujący uzyskał dostęp do starego systemu OpenCode. Firma przygotowywała się właśnie do jego wyłączenia. Jednak klucze klientów nadal były tam przechowywane. Incydent dotknął 1,4% użytkowników Console.

To tak, jakby przenieść się do nowego biura, ale w starym pozostawić sejf pełen dokumentów. Drzwi nie są już przez nikogo pilnowane.

Co zauważyli użytkownicy. Jeden z programistów opowiedział, że w nocy otrzymał powiadomienia o wydatkach jednocześnie z trzech usług. Google automatycznie zablokowało podejrzaną aktywność. OpenAI i Anthropic nadal naliczały opłaty, dopóki ręcznie nie unieważnił kluczy.

Ważne: samo usunięcie klucza z OpenCode nie rozwiąże problemu. Osoba, która go skopiowała, nadal będzie mogła z niego korzystać. Klucz trzeba unieważnić bezpośrednio w panelu usługi, która go wydała.

Sprawdź, czy problem dotyczy również Ciebie

LiteLLM. Sprawdź wersję zainstalowaną na serwerze:

pip show litellm

Jeśli wynik zawiera Version: 1.107.0, serwer jest zainfekowany. Poszukaj również plików pozostawionych przez złośliwą wersję:

find / -name "cook.pth" -o -name "litellm-1.107.0.dist-info" 2>/dev/null

Jeśli uruchamiasz LiteLLM w Dockerze, sprawdź, czy 21 października nie aktualizowałeś obrazu. Niebezpieczne były tagi v1.107.0, latest, main-latest oraz main-stable.

• Railway. Jeśli masz tam choć jeden projekt, załóż, że incydent mógł dotknąć również Ciebie. Railway samo zaleca wszystkim klientom wymianę kluczy.

• OpenCode. Sprawdź pocztę: OpenCode wysłało wiadomości do poszkodowanych użytkowników. Jeśli nie otrzymałeś powiadomienia, ale przechowywałeś klucze w OpenCode Console, i tak warto je wymienić. Jeśli korzystasz wyłącznie z programu zainstalowanego na własnym komputerze, Twoje klucze są przechowywane lokalnie i nie były objęte tym wyciekiem.

• Pozostali użytkownicy. Otwórz panele OpenAI, Anthropic i Google oraz przejrzyj wydatki z ostatnich dwóch tygodni. Nagły wzrost kosztów, szczególnie w nocy, powinien wzbudzić podejrzenia.

Jak prawidłowo wymienić klucze API

Klucze trzeba wymienić tak, aby strona internetowa nie przestała działać. Postępuj w następującej kolejności:

1. Utwórz nowy klucz w panelu dostawcy: OpenAI, Anthropic, Google AI Studio lub innej usługi.

2. Dodaj nowy klucz do swojej strony, bota lub aplikacji.

3. Sprawdź, czy wszystko działa prawidłowo.

4. Unieważnij stary klucz w panelu dostawcy. Dopiero wtedy atakujący straci możliwość korzystania z niego.

To jak wymiana zamka po zgubieniu kluczy. Najpierw montujesz nowy zamek i przekazujesz nowe klucze odpowiednim osobom. Dopiero potem pozbywasz się starych.

Wymieniaj nie tylko klucze AI. Jeśli klucz znajdował się na serwerze razem z innymi poufnymi danymi, wymień wszystko: hasła do baz danych, klucze do usług chmurowych, tokeny systemów płatności i klucze SSH.

Jeśli miałeś zainstalowaną wersję LiteLLM 1.107.0, sama wymiana kluczy nie wystarczy. Złośliwa wersja pozostawiała tylne drzwi. Samo usunięcie pakietu nie rozwiąże problemu. Jeśli złodziej był już w mieszkaniu i dorobił klucz do tylnych drzwi, nowy zamek przy głównym wejściu nie pomoże. Bezpieczniej jest ponownie zainstalować taki serwer od podstaw, a następnie wymienić wszystkie hasła i klucze.

Ustaw limity i uporządkuj dostęp do usług

Nie da się całkowicie wyeliminować ryzyka wycieku. Można jednak ograniczyć jego konsekwencje finansowe.

• Ustaw limit wydatków dla każdego klucza. Wszyscy najwięksi dostawcy usług AI umożliwiają określenie miesięcznego budżetu. To jak limit na karcie bankowej. Nawet jeśli ktoś ją ukradnie, nie wyda więcej niż ustalony limit.

• Jeden klucz do jednego projektu. Nie korzystaj z tego samego klucza na stronie, w bocie i podczas testów. Jeśli dojdzie do wycieku, wymienisz tylko jeden klucz i od razu będziesz wiedzieć, skąd pochodził problem.

• Nie przechowuj kluczy w kodzie. Trzymaj je w pliku .env i dodaj ten plik do .gitignore, aby nie trafił do repozytorium. Właśnie tak rozpoczęło się włamanie do LiteLLM: klucz przypadkowo znalazł się na GitHubie.

• Nie zapisuj kluczy w logach. Sprawdź, czy Twoja strona lub bot nie zapisuje pełnych żądań zawierających klucze i tokeny. To właśnie przez logi atakujący uzyskał dostęp do systemu aktualizacji LiteLLM.

• Przypinaj konkretne wersje oprogramowania. Podawaj dokładną wersję, na przykład litellm==1.106.2, zamiast samego litellm. W Dockerze nie używaj tagu latest. Dzięki temu złośliwa aktualizacja nie zainstaluje się automatycznie, zanim ją sprawdzisz.

Lista kontrolna

• Sprawdziłem wersję LiteLLM na serwerze

• Sprawdziłem, czy mam projekty na Railway

• Sprawdziłem pocztę pod kątem wiadomości od OpenCode

• Przejrzałem wydatki w panelach OpenAI, Anthropic i Google

• Wymieniłem klucze we właściwej kolejności: nowy klucz, test, unieważnienie starego

• Wymieniłem pozostałe hasła i klucze na zainfekowanym serwerze

• Ustawiłem limity wydatków dla każdego klucza

• Usunąłem klucze z kodu i logów

• Przypiąłem konkretne wersje oprogramowania i obrazów Docker

Nie chcesz zajmować się tym samodzielnie?

Znalezienie wszystkich kluczy na serwerze jest trudniejsze, niż się wydaje. Jeden może znajdować się w pliku .env, drugi w ustawieniach bota, trzeci w kontenerze Docker, a czwarty przypadkowo trafił do logów. Jeśli istnieje ryzyko, że serwer został zainfekowany, trzeba go ponownie zainstalować, nie tracąc ważnych danych.

W takich sytuacjach Zomro oferuje dwa rozwiązania.

SOD: sprawdzimy Twój serwer za Ciebie

Nasz administrator systemów:

• sprawdzi, czy na serwerze znajduje się zainfekowana wersja LiteLLM lub pozostawione przez nią ślady;

• znajdzie miejsca przechowywania kluczy i haseł oraz wskaże, które należy wymienić;

• sprawdzi, czy poufne dane nie trafiają do logów;

• pomoże przenieść projekt na czysty serwer, jeśli będzie to konieczne.

Cena: €12.50 za każde 15 minut pracy.

Zamów kontrolę bezpieczeństwa serwera

Premium: szybka pomoc, kiedy jej potrzebujesz

Gdy klucz API wycieknie, rachunek może rosnąć z każdą godziną. Odpowiedź na standardowe zgłoszenie techniczne może zająć do 10 godzin. W ramach Premium odpowiadamy w ciągu 5–30 minut.

Co tydzień pojawiają się nowe wycieki danych i luki bezpieczeństwa. Z Premium nie musisz radzić sobie z nimi samodzielnie.

Aktywuj Premium