Ponad 9300 ujawnionych kluczy AWS wciąż działało

Badanie Truffle Security z sierpnia 2026 roku wskazuje na problem z poświadczeniami chmurowymi, który jest jednocześnie ogromny i wyjątkowo trwały. W publicznych repozytoriach, historii Git, zbiorach danych, obrazach Dockera, rejestrach kontenerów oraz logach systemów ciągłej integracji badacze odnotowali 431 875 znalezisk zawierających sekrety AWS między sierpniem 2022 a sierpniem 2026. Po usunięciu duplikatów i weryfikacji pozostały 64 024 unikalne klucze AWS. 145

Najważniejsza nie jest jednak sama liczba ujawnionych poświadczeń, lecz to, ile z nich wciąż działało. 10 sierpnia 2026 roku pomyślnie uwierzytelniło się 9308 z 10 616 przetestowanych, kompletnych par poświadczeń — około 88%. 145

Wśród wycieków były poświadczenia o najwyższych uprawnieniach

Zweryfikowany zbiór obejmował 10 625 poświadczeń root, 48 744 klucze użytkowników IAM oraz 4655 kluczy, których nie udało się sklasyfikować. Poświadczenia root stanowiły 16,6% unikalnych kluczy. 1

Truffle Security zidentyfikowało 817 aktywnych kluczy powiązanych z firmami. W tej grupie znalazły się:

• 526 kluczy root — poświadczeń o najwyższym poziomie uprawnień w koncie AWS;
• 242 klucze użytkowników IAM z polityką AdministratorAccess, która może zapewniać pełną kontrolę nad kontem;
• 768 poświadczeń łącznie, które mogły dać atakującemu pełną kontrolę nad firmowym kontem AWS;
• 130 aktywnych kluczy root dla kont zarządzających AWS Organizations, których przejęcie potencjalnie mogłoby wpłynąć także na konta członkowskie w całej organizacji. 13

W węższej grupie użytkowników IAM, dla których można było odczytać polityki, 976 z 1157 kont — 84% — miało AdministratorAccess. Kolejne 144 miały IAMFullAccess. Truffle Security zastrzegło, że jest to wynik orientacyjny, ponieważ użytkownicy pozwalający na odczyt polityk mogą nie być reprezentatywni dla wszystkich ujawnionych użytkowników IAM. 1

Ile kont AWS mogło zostać dotkniętych?

W dostarczonych materiałach pojawiają się dwie liczby dotyczące kont AWS i najpewniej odnoszą się do różnych zakresów analizy. Jedno podsumowanie mówi o 9945 różnych kontach AWS powiązanych ze zbiorem 64 024 kluczy, podczas gdy podsumowanie raportu źródłowego wskazuje 50 654 różne konta AWS. Materiały nie wyjaśniają, skąd wynika ta rozbieżność, dlatego tych wartości nie należy traktować jako zamiennych. 1

Skala ryzyka na poziomie firm jest jednak jasna: setki aktywnych poświadczeń powiązano z przedsiębiorstwami, a 768 kluczy mogło zapewnić pełną kontrolę nad firmowym kontem AWS. 13

Hugging Face było największym pojedynczym źródłem

Hugging Face odpowiadało za 8482 unikalne, aktywne klucze AWS znalezione w 3394 publicznych zbiorach danych. Było to największe pojedyncze źródło w analizie. Poświadczenia root stanowiły tam 17,9% kluczy — najwięższy odsetek wśród monitorowanych źródeł. 125

Problem pogłębia sposób, w jaki publiczny kod może być ponownie wykorzystywany. Migawki kodu zawierające sekrety mogą trafiać do zbiorów danych używanych do trenowania modeli, a następnie być rozpowszechniane w wielu kolejnych zbiorach. Usunięcie sekretu z pierwotnego repozytorium nie oznacza więc, że zniknęły wszystkie jego kopie. 1

Wynik dotyczący AWS jest częścią szerszego skanowania Hugging Face przeprowadzonego przez Truffle Security. Firma twierdzi, że przeanalizowała 7,6 petabajta danych i 187 milionów plików, znajdując 221 303 aktywne, unikalne poświadczenia w 6003 zbiorach danych. Te liczby obejmują wszystkie typy poświadczeń, nie tylko klucze AWS. 6

Wiele kluczy miało po kilka lat i nie zostało wymienionych

Wśród 2903 aktywnych kluczy, dla których można było odczytać datę utworzenia, mediana wieku wynosiła 1831 dni — około pięciu lat. Połowa kluczy miała ponad pięć lat, najstarszy miał 17,4 roku, a zaledwie 25 kluczy — 0,9% — utworzono w ciągu poprzednich 30 dni. 1

Tylko 398 z tych 2903 kluczy — 13,7% — miało nowszy klucz zastępczy. Sugeruje to, że większość nie została wymieniona, zastąpiona ani usunięta po ujawnieniu. 1

Wniosek praktyczny jest prosty: sekret, który trafił do publicznego materiału, należy traktować jako trwale przejęty. Dotyczy to także sytuacji, w której oryginalny plik lub wpis w repozytorium został później zmieniony. Historię Git, obrazy kontenerów, artefakty pakietów i publiczne zbiory danych mogą zachować wcześniejsze kopie. 1

Brak alertów budżetowych zwiększał ryzyko kopania kryptowalut

Rzadko stosowano także kontrolę wydatków. Spośród 2754 kont, których ustawienia można było odczytać, tylko 262 — 9,5% — miały skonfigurowany jakikolwiek alert budżetowy. Mediana progu alertu wynosiła 8 dolarów. 12

Oznacza to, że w 90,5% analizowanych kont nie wykryto alarmu budżetowego. Osoba dysponująca działającymi poświadczeniami mogła wykorzystać moc obliczeniową AWS do kopania kryptowalut lub uruchamiania innych obciążeń, zanim organizacja zauważyłaby nietypowy wzrost kosztów. 12

Konta, dla których można było odczytać dane o wydatkach, wydały łącznie 420 631 dolarów w lipcu 2026 roku. Pięćdziesiąt z nich wydało w tym miesiącu ponad 1000 dolarów, a dziewięć — ponad 10 000 dolarów. Dane te opisują zaobserwowane konta, ale nie dowodzą, że wydatki były skutkiem nadużycia poświadczeń. 1

Kwarantanna AWS nie musiała od razu unieważniać klucza

Truffle Security poinformowało, że AWS nakładało na wykryte, ujawnione klucze IAM politykę AWSCompromisedKeyQuarantine. Ogranicza ona zakres działań, które może wykonać dany klucz, ale nie musi natychmiast uniemożliwiać uwierzytelnienia. 1

Wśród przeanalizowanych aktywnych kluczy IAM 929 z 7590 — 12% — miało tę politykę. Kolejne 112 posiadało jej starszą wersję, której AWS zaprzestało stosowania w 2023 roku. Wyniki Truffle Security wskazują, że niektóre klucze pozostawały użyteczne mimo wieloletnich powiadomień o ich ujawnieniu. 1

Politykę kwarantanny należy zatem traktować jako sygnał możliwego wycieku, a nie dowód bezpiecznego wycofania sekretu. Organizacja powinna ustalić właściciela i zakres uprawnień klucza, a następnie go unieważnić lub wymienić. 1

Jak badacze testowali poświadczenia?

Truffle Security twierdzi, że ponownie weryfikowało wyłącznie pary poświadczeń, dla których miało kompletne dane. Do analizy kont i uprawnień używano wywołań IAM tylko do odczytu, wykonując je pojedynczo dla każdego klucza. Badacze nie publikowali materiału kluczowego i powiadamiali każdego właściciela, którego udało się zidentyfikować. 15

To ważne przy interpretacji wyniku 88%. Odsetek ten dotyczy podzbioru kompletnych par poświadczeń poddanych ponownemu testowi, a nie wszystkich publicznych znalezisk ani wszystkich częściowo ujawnionych sekretów. 14

Co organizacje powinny zrobić?

Wyniki badania wspierają krótki plan działań reagowania na incydent:

1. Usunąć klucze root. Truffle Security argumentuje, że nie mają one uzasadnionego zastosowania operacyjnego. 1
2. Zinwentaryzować wszystkie klucze dostępu IAM — także te znajdujące się w repozytoriach, historii Git, logach CI, obrazach i rejestrach kontenerów oraz opublikowanych zbiorach danych. 1
3. Natychmiast unieważniać lub wymieniać ujawnione poświadczenia. Usunięcie widocznej kopii nie wystarczy, jeśli sekret nadal znajduje się w historii lub materiałach pochodnych. 1
4. Ustalić maksymalny wiek klucza i wymuszać jego rotację. Stare i nieużywane poświadczenia lepiej usuwać, niż pozostawiać je bezterminowo aktywne. 1
5. Skonfigurować alerty budżetowe. Nawet niski próg, na przykład 10 dolarów, może wcześnie ostrzec o nieautoryzowanych wydatkach. 1
6. Monitorować AWSCompromisedKeyQuarantine i traktować tę politykę jako dowód możliwego ujawnienia poświadczenia. 1
7. Stosować ciągłe skanowanie sekretów w kodzie źródłowym, historii, systemach budowania, artefaktach kontenerowych, rejestrach i opublikowanych zbiorach danych. 1

Najważniejsze ostrzeżenie płynące z badania jest takie, że publiczne ujawnienie nie jest jednorazowym wyciekiem. Bez unieważnienia, rotacji i monitorowania klucz AWS może przez lata pozostawać działającymi drzwiami do infrastruktury chmurowej.