Krytyczna luka w Google Vertex AI SDK umożliwiała przejęcie uploadu modeli przez bucket squatting

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

W środowiskach AI i MLOps bezpieczeństwo łańcucha dostarczania modeli ma dziś równie duże znaczenie jak ochrona kodu aplikacyjnego i infrastruktury chmurowej. Ujawniona podatność w Google Vertex AI SDK for Python pokazała, że nawet mechanizmy zaprojektowane z myślą o wygodzie deweloperów mogą stać się wektorem ataku. Problem dotyczył procesu przesyłania modeli do Vertex AI oraz sposobu automatycznego wyboru bucketu stagingowego w Google Cloud Storage.

W praktyce luka umożliwiała atak typu bucket squatting. Jeśli użytkownik nie wskazał własnego bucketu stagingowego, biblioteka korzystała z przewidywalnego schematu nazewnictwa. Napastnik mógł wcześniej utworzyć bucket o oczekiwanej nazwie, przechwycić przesyłane artefakty modelu, a następnie podmienić je na złośliwe pliki.

W skrócie

Podatność dotyczyła klienta Vertex AI SDK for Python używanego do uploadu modeli. Kluczowym problemem był brak odpowiedniej weryfikacji własności bucketu oraz przewidywalny sposób generowania jego nazwy w sytuacji, gdy parametr stagingowy pozostawał pusty.

atakujący mógł utworzyć bucket o przewidywalnej nazwie przed ofiarą,
przesyłane modele trafiały do zasobu kontrolowanego przez napastnika,
możliwa była podmiana artefaktu modelu przed jego załadowaniem przez Vertex AI,
skutkiem mogło być wykonanie złośliwego kodu w kontenerze servingowym,
Google wdrożył poprawki, a zalecaną wersją naprawczą jest co najmniej 1.148.0.

Kontekst / historia

Błąd został zidentyfikowany przez badaczy z Unit 42, którzy zwrócili uwagę na ryzyko wynikające z automatycznego przygotowywania przestrzeni stagingowej dla modeli. Mechanizm miał upraszczać proces wdrożeniowy, ale opierał się na nazwach bucketów możliwych do odgadnięcia na podstawie identyfikatora projektu i regionu.

Ze względu na globalną unikalność nazw bucketów w Google Cloud Storage, wystarczyło, aby napastnik zarejestrował właściwą nazwę wcześniej. To pozwalało przejąć ruch związany z uploadem modelu bez uzyskiwania dostępu do projektu ofiary, bez poświadczeń i bez stosowania klasycznych technik włamania.

Według opisu incydentu podatność zgłoszono do programu bug bounty Google 5 marca 2026 roku. Wersja 1.144.0, opublikowana 31 marca 2026 roku, ograniczyła przewidywalność nazw bucketów, natomiast pełniejsze zabezpieczenie wdrożono 15 kwietnia 2026 roku w wydaniu 1.148.0, dodając kontrolę własności bucketu podczas uploadu modelu. Nie wskazano przy tym potwierdzonych przypadków aktywnego wykorzystania luki w środowiskach produkcyjnych.

Analiza techniczna

Źródło problemu znajdowało się po stronie klienta SDK, a nie w samym backendzie Vertex AI. Gdy parametr staging_bucket nie był ustawiony, biblioteka próbowała automatycznie wyznaczyć bucket stagingowy na podstawie wzorca związanego z projektem i regionem. Taki schemat był wystarczająco przewidywalny, by osoba trzecia mogła przygotować odpowiedni zasób z wyprzedzeniem.

Samo sprawdzenie istnienia bucketu nie rozwiązywało problemu, ponieważ biblioteka nie potwierdzała, czy bucket należy do właściwej organizacji lub projektu. W efekcie upload modelu mógł zostać skierowany do zasobu kontrolowanego przez napastnika. To klasyczny przypadek bucket squattingu, ale osadzony w kontekście pipeline’u MLOps i procesu wdrażania modeli AI.

Krytycznym elementem ataku była możliwość podmiany artefaktu modelu. Miało to szczególne znaczenie dla serializowanych formatów, takich jak obiekty zapisane z użyciem mechanizmów mogących uruchamiać kod podczas deserializacji. Jeśli platforma wczytywała podmieniony plik jako model, złośliwy kod mógł zostać wykonany wewnątrz kontenera servingowego.

Badacze opisali także aspekt czasowy całego scenariusza. Okno pomiędzy przesłaniem pliku a jego odczytem przez usługę było krótkie, ale wystarczające do automatycznej zamiany obiektu. W demonstracji wykorzystano mechanizm reagujący na upload w chmurze i błyskawicznie podmieniający plik przed jego załadowaniem przez Vertex AI.

W jednym ze scenariuszy testowych złośliwy kod uzyskał token OAuth z serwera metadanych dostępnego z poziomu kontenera. Taki dostęp potencjalnie otwierał drogę do dalszego ruchu bocznego, odczytu innych artefaktów modeli oraz pozyskania dodatkowych informacji o środowisku uruchomieniowym.

Konsekwencje / ryzyko

Skutki tej podatności wykraczały daleko poza sam incydent związany z uploadem modelu. W zależności od architektury wdrożenia i uprawnień przypisanych workloadom, luka mogła prowadzić do poważnego naruszenia poufności, integralności i dostępności środowiska AI.

zdalne wykonanie kodu w procesie obsługi modelu,
kradzież wag modeli i innych artefaktów stanowiących własność intelektualną,
zatrucie modeli przez podmianę binariów lub serializowanych obiektów,
wyciek tokenów, metadanych i informacji o środowisku chmurowym,
możliwość eskalacji wpływu na kolejne komponenty pipeline’u MLOps.

Szczególnie istotne jest to, że atak nie wymagał wcześniejszego kompromitowania kont, poświadczeń ani sieci ofiary. W wielu przypadkach wystarczał publicznie znany identyfikator projektu oraz użycie domyślnej konfiguracji przez podatną wersję SDK. To czyniło problem wyjątkowo groźnym dla nowych wdrożeń, notebooków badawczych, pipeline’ów CI/CD i środowisk eksperymentalnych.

Rekomendacje

Organizacje korzystające z Vertex AI powinny potraktować ten incydent jako sygnał ostrzegawczy dotyczący bezpieczeństwa całego łańcucha dostarczania modeli. Kluczowe jest nie tylko wdrożenie poprawki producenta, ale również przegląd praktyk operacyjnych związanych z publikacją artefaktów ML.

zaktualizować pakiet google-cloud-aiplatform do wersji 1.148.0 lub nowszej,
jawnie definiować parametr staging_bucket i używać wyłącznie bucketów kontrolowanych przez organizację,
przeanalizować notebooki, pipeline’y treningowe, zadania CI/CD i skrypty operacyjne pod kątem starszych wersji SDK,
ograniczyć użycie niebezpiecznych formatów serializacji tam, gdzie mogą prowadzić do wykonania kodu,
zweryfikować uprawnienia kont serwisowych i dostęp workloadów do serwera metadanych,
wdrożyć monitoring uploadów modeli, zmian w bucketach i nietypowych operacji na artefaktach,
stosować mechanizmy integralności, takie jak hashe, podpisy i attestation artefaktów.

Z perspektywy zespołów bezpieczeństwa warto również rozszerzyć model zagrożeń dla środowisk AI o ryzyka związane z automatyzacją SDK, zasobami stagingowymi i zależnościami wykorzystywanymi w pipeline’ach MLOps. Ten przypadek pokazuje, że atak na model może rozpocząć się jeszcze przed jego uruchomieniem.

Podsumowanie

Podatność w Google Vertex AI SDK for Python była przykładem błędu projektowego o wysokim znaczeniu operacyjnym. Przewidywalne nazewnictwo bucketów i brak skutecznej weryfikacji własności zasobu umożliwiały przejęcie uploadu modelu, jego podmianę oraz wykonanie kodu w infrastrukturze obsługującej AI.

Choć Google wdrożył poprawki i nie odnotowano publicznie potwierdzonego nadużycia tej luki w produkcji, incydent stanowi ważne ostrzeżenie dla organizacji rozwijających rozwiązania oparte na sztucznej inteligencji. Domyślne ustawienia w narzędziach MLOps nie zawsze są bezpieczne, dlatego pipeline’y AI powinny być traktowane jako pełnoprawny obszar bezpieczeństwa aplikacyjnego i chmurowego.