Google Cloud w obliczu kryzysu – publiczne klucze stają się zagrożeniem

Masz w kodzie publiczny klucz do Map Google i śpisz spokojnie? Zły scenariusz: po włączeniu Gemini ten „nieszkodliwy” token może działać jak przepustka do twoich danych i budżetu.

Badacze z Truffle Security znaleźli blisko 3 tysiące publicznie dostępnych kluczy Google Cloud (te na „AIza…”), które po aktywowaniu Gemini (Generative Language API) zaczynają uwierzytelniać żądania do wrażliwych endpointów. Google przyznało, że problem istnieje i wdrożyło blokadę dla wyciekających kluczy, ale stare projekty wciąż mogą być odsłonięte. Jeśli kiedyś wklejałeś klucz w JavaScript, bo „tak było w dokumentacji” – to jest moment, żeby to zmienić.

Przez lata Google uczyło deweloperów, że klucze do usług typu Maps, YouTube czy Firebase to identyfikatory rozliczeniowe, a nie sekrety. Tolerowano ich obecność w publicznym HTML/JS. Realia zmieniło przyjście Gemini: włączenie jego API w projekcie GCP niepostrzeżenie „podnosi rangę” każdego istniejącego klucza w tym projekcie. Efekt? To, co miało być niewinne, zaczyna działać jak pełnoprawne poświadczenie do AI – bez ostrzeżenia, potwierdzenia czy maila do właściciela projektu. [6]

O co chodzi

Truffle Security przeskanowało zrzut Common Crawl z listopada 2025 i znalazło 2 863 działające klucze Google API wystawione w sieci. Część należała do dużych instytucji finansowych, firm security, rekruterów, a nawet do serwisu powiązanego z samym Google. W praktyce atakujący kopiuje klucz z kodu strony i wywołuje endpointy Gemini: listy modeli, plików (/files) albo pamięci podręcznej (/cachedContents). Jak ujął to jeden z badaczy: mając ważny klucz, można pobierać przesłane pliki, czytać cache i nabić komuś rachunek za LLM. [3][1]

Kontekst i trend

To nie jest klasyczna „konfiguracja z piekła rodem”, tylko cicha eskalacja uprawnień wynikająca z domyślnych ustawień. Nowo tworzone klucze w GCP startują jako „Unrestricted” – działają dla każdego API w projekcie, w tym Gemini, jeśli zostało włączone. Stare klucze, które od lat wiszą w publicznym JS jako „bezpieczne do udostępniania”, z dnia na dzień zyskały nowe moce, gdy ktoś w zespole kliknął „Enable” przy Generative Language API. To pokazuje, jak ryzyko jest dynamiczne: architektura się zmienia, a klucze nagle robią coś, do czego nie zostały zaprojektowane. [5][1]

Fakty, dane, reakcje

• Skala: 2 863 żywe klucze na stronach WWW; osobny raport Quokka wskazuje 35 tys. unikalnych kluczy Google znalezionych w 250 tys. aplikacji Android.
• Koszt: w zależności od modelu i okna kontekstu, wyciskanie API może generować tysiące dolarów dziennie na jedno konto. Na Reddicie ktoś pokazał rachunek 82 314,44 dol. za… dwa dni (przy normalnym miesięcznym 180 dol.).
• Dostęp: oprócz wywołań modeli, zagrożone są zasoby za pośrednictwem endpointów plików i cache – czyli realne dane i realne limity.
• Timeline: badacze zgłosili problem 21 listopada 2025. Po korespondencji Google sklasyfikowało go jako „single-service privilege escalation” 13 stycznia 2026 i zaczęło wdrażać środki zaradcze. Najpierw problem miał uchodzić za „zamierzony”, potem został uznany za błąd i wzięty na warsztat.
• Google: firma mówi, że wykrywa i blokuje wyciekające klucze próbujące uderzyć w Gemini, zawęża domyślne zakresy dla nowych kluczy AI Studio (Gemini-only) i wysyła powiadomienia, gdy wykryje wycieki. Czy ktoś to masowo wykorzystywał? Nie wiadomo. [4]

Dlaczego to ważne

Bo „to tylko identyfikator rozliczeń” przestało być prawdą w świecie, w którym AI podczepia się pod istniejące projekty chmurowe. Granica między publicznym tokenem a sekretem się zatarła w milisekundzie kliknięcia „Enable”. A że Gemini to nie kalkulator, tylko multimodalna platforma z dostępem do plików i pamięci kontekstowej – zakres skutków wycieku jest inny niż w starym modelu „tylko rozliczenia”.

Co na to bezpieczeństwo

Eksperci wskazują na klasyki: niebezpieczne domyślne ustawienia (CWE-1188) i błędne przypisywanie uprawnień (CWE-269). Innymi słowy: jeśli wszystko jest do wszystkiego, to prędzej czy później coś pójdzie nie tak. Google AI Studio, które ma wygładzać pracę z Gemini i jego API, jest świetne do prototypowania – ale wygoda bez wydzielonych poświadczeń zwiększa ryzyko. [9]

Co robić teraz (naprawdę teraz)

Sprawdź w każdym projekcie GCP, czy „Generative Language API” jest włączone. Jeśli tak – zrób przegląd wszystkich kluczy w „APIs & Services > Credentials”. Klucze „Unrestricted” albo takie z dozwolonym dostępem do Gemini traktuj priorytetowo. Poszukaj wzorca „AIza” w klienckim JS, publicznych repo i artefaktach buildów; rotuj najstarsze klucze (to one najczęściej trafiły do frontendu „bo tak mówiła dokumentacja sprzed lat”). Do integracji z AI używaj kont serwisowych i ogranicz zakresy. Włącz skanery sekretów (np. TruffleHog) w CI/CD. I – powiedz zespołowi, że „klucze Google to nie sekrety” jest już nieaktualne. [5]

Krótka interpretacja

To nie „wielki hack na Google”, tylko zgrzyt na styku UX chmury i bezpieczeństwa. AI podpięto do istniejącej mechaniki kluczy, a ryzyko skoczyło o rząd wielkości, zanim ktokolwiek zdążył zareagować. Gdy platformy dodają inteligencję do wszystkiego, najgorszym pomysłem bywa trzymanie się starych założeń.

Na koniec

Jeśli korzystasz z czegokolwiek w Google Cloud – od Map po YouTube Data API – załóż, że twoje klucze to już sekrety. Zastanów się, co dziś może zrobić klucz, który wczoraj „tylko” liczył requesty. A potem działaj, zanim zrobi to za ciebie ktoś inny.

FAQ

Czy jestem zagrożony, jeśli w moim projekcie nie włączono Generative Language API (Gemini)?

Nie, ten wektor dotyczy tylko projektów z włączonym Generative Language API. Jeśli API Gemini nie jest aktywne, publiczny klucz nie powinien uwierzytelniać żądań do Gemini.

Jak szybko sprawdzić, czy wyciekły mi klucze Google API z dostępem do Gemini?

Najprościej: przeszukaj repozytoria i artefakty buildów pod kątem „AIza”, a w GCP sprawdź, które klucze są „Unrestricted” lub mają dostęp do Gemini. Możesz użyć skanera sekretów (np. TruffleHog), żeby wykryć żywe, eksponowane klucze.

Czy luka była wykorzystywana w praktyce?

Nie wiadomo – brak potwierdzonych przypadków od Google. Istnieje jednak relacja użytkownika o rachunku ponad 82 tys. dol. w dwa dni, co pokazuje potencjał nadużyć.

Czy Google naprawiło problem w całości i kiedy będzie „po sprawie”?

Nie, pełna poprawka architektoniczna jest w toku; firma wdrożyła blokowanie wycieków i ostrzejsze domyślne zakresy dla nowych kluczy. Nie podano daty finalnego rozwiązania, więc audyt i rotacja kluczy są na dziś.

Czy nowe klucze są bezpieczniejsze niż stare?

Tak, częściowo: nowe klucze AI Studio mają domyślnie zakres „tylko Gemini”, a wyciekające klucze są wykrywane i blokowane. To nie rozwiązuje ryzyka w starszych projektach z kluczami „Unrestricted”, które trzeba ręcznie uporządkować.

Źródła

• [1] https://thehackernews.com/2026/02/thousands-of-public-google-cloud-api.html
• [2] https://linkedin.com/posts/spin-idg-media_thousands-of-public-google-cloud-api-keys-activity-7433472642113798144-UzuK
• [3] https://bleepingcomputer.com/news/security/previously-harmless-google-api-keys-now-expose-gemini-ai-data/
• [4] https://cyberpress.org/google-api-key-misconfigurations-lead-to-silent-data-exposure-via-gemini/
• [5] https://cybersecuritynews.com/google-api-keys-gemini/
• [6] https://c3.unu.edu/blog/google-api-key-gemini-security-risk
• [7] https://gigazine.net/gsc_news/en/20260227-google-api-key-gemini/
• [8] https://androidpolice.com/thought-google-docs-was-enough-until-paired-it-with-gemini/
• [9] https://ts2.tech/en/google-ai-studio-unleashed-inside-googles-gemini-powered-ai-playground-taking-on-chatgpt/