Wprowadzenie do problemu / definicja
W ekosystemach chmurowych bezpieczeństwo łańcucha dostarczania modeli uczenia maszynowego staje się równie ważne jak ochrona tradycyjnych aplikacji. Opisana podatność w Google Cloud Vertex AI SDK for Python dotyczyła mechanizmu przesyłania artefaktów modelu do tymczasowego zasobnika Cloud Storage, gdzie przewidywalne nazewnictwo bucketów i brak weryfikacji ich właściciela otwierały drogę do ataku typu bucket squatting.
W praktyce oznaczało to możliwość przejęcia procesu uploadu modelu jeszcze przed jego wdrożeniem. Napastnik mógł wykorzystać kontrolowany przez siebie bucket do przechwycenia artefaktów i podmiany ich na złośliwe pliki, co tworzyło ryzyko wykonania kodu w środowisku obsługującym model.
W skrócie
- Problem dotyczył biblioteki google-cloud-aiplatform używanej z Vertex AI.
- Jeśli użytkownik nie wskazał własnego staging_bucket, SDK generował domyślną nazwę bucketu na podstawie projektu i regionu.
- Napastnik mógł wcześniej zarejestrować taki bucket we własnym projekcie i przejąć upload artefaktów.
- Skutkiem mogła być podmiana modelu, zatrucie pipeline’u ML oraz zdalne wykonanie kodu.
- Zalecana poprawka to aktualizacja do wersji 1.148.0 lub nowszej.
Kontekst / historia
Vertex AI to zarządzana platforma Google Cloud służąca do trenowania, rejestrowania i wdrażania modeli ML. W wielu organizacjach Pythonowe SDK jest podstawowym narzędziem do automatyzacji pipeline’ów, publikowania modeli i ich wdrażania do środowisk inferencyjnych.
Badacze bezpieczeństwa wykryli problem w logice stagingu podczas operacji Model.upload(). Podatne były co najmniej wersje 1.139.0 i 1.140.0, a działania naprawcze rozpoczęto pod koniec marca 2026 roku. Pełna poprawka została ukończona 15 kwietnia 2026 roku w wydaniu 1.148.0, natomiast publiczny opis problemu pojawił się 16 czerwca 2026 roku.
Incydent wpisuje się w szerszą klasę błędów projektowych związanych z przewidywalnym nazewnictwem zasobów obiektowych. W środowiskach chmurowych globalna unikalność nazw bucketów może stać się wektorem przejęcia przepływu danych między klientem a usługą zarządzaną.
Analiza techniczna
Źródłem problemu był sposób wyznaczania domyślnego bucketu stagingowego. Gdy parametr staging_bucket nie był ustawiony, SDK konstruował nazwę bucketu deterministycznie na podstawie identyfikatora projektu i regionu, a następnie sprawdzał jedynie, czy taki zasób istnieje. Krytyczny błąd polegał na tym, iż biblioteka nie weryfikowała, czy bucket należy do adekwatnego właściciela.
Ze względu na globalną unikalność nazw bucketów w Google Cloud napastnik mógł wcześniej utworzyć przewidywany bucket w swoim projekcie. o ile ofiara uruchamiała upload bez jawnie wskazanego zasobnika stagingowego, artefakty modelu trafiały do infrastruktury kontrolowanej przez atakującego.
Kolejny etap ataku opierał się na krótkim oknie czasowym. Po pojawieniu się pliku w bucketcie napastnik musiał gwałtownie podmienić artefakt, zanim Vertex AI odczyta go do dalszego przetwarzania. Według opublikowanej analizy czas ten wynosił około 2,5 sekundy, a w demonstracji udało się przeprowadzić podmianę w około 1,4 sekundy.
Najbardziej niebezpieczny scenariusz dotyczył modeli i artefaktów serializowanych przy użyciu pickle lub joblib. Deserializacja takich plików może prowadzić do wykonania dowolnego kodu, jeżeli dane zostały spreparowane przez napastnika. W rezultacie złośliwy model mógł uruchomić ładunek w kontenerze obsługującym inferencję.
Analiza wskazywała również możliwość pozyskania tokenu OAuth z serwera metadanych dostępnego w środowisku uruchomieniowym. To z kolei otwierało drogę do dalszej eskalacji, dostępu do innych artefaktów i szerszej kompromitacji procesu MLOps.
Konsekwencje / ryzyko
Z punktu widzenia bezpieczeństwa chmury i systemów AI podatność miała wysoki potencjał oddziaływania. Najpoważniejsze skutki obejmowały zdalne wykonanie kodu, przejęcie modelu, zatrucie procesu wdrożeniowego oraz ekspozycję danych dostępnych z poziomu tożsamości wykorzystywanej przez usługę.
Szczególnie istotne jest to, iż atak nie wymagał wcześniejszego dostępu do projektu ofiary, przejęcia konta ani działań phishingowych. Wystarczał własny projekt Google Cloud i znajomość identyfikatora projektu, który bywa ujawniany publicznie w dokumentacji, skryptach CI/CD czy repozytoriach kodu.
Najbardziej narażone były nowe projekty i regiony, w których domyślny bucket stagingowy nie został jeszcze utworzony, a także środowiska silnie zautomatyzowane, gdzie korzysta się z domyślnych ustawień SDK i trudno zauważyć nieautoryzowane przejęcie transferu artefaktów.
Rekomendacje
Podstawowym działaniem naprawczym jest aktualizacja biblioteki google-cloud-aiplatform do wersji 1.148.0 lub nowszej. Wersja ta wprowadza mechanizmy ograniczające ryzyko bucket squattingu, w tym kontrolę własności bucketu używanego podczas Model.upload().
- Jawnie definiować staging_bucket i używać wyłącznie bucketów kontrolowanych przez organizację.
- Przeanalizować notebooki, pipeline’y treningowe, zadania CI/CD i skrypty operacyjne korzystające z Vertex AI SDK.
- Ograniczyć uprawnienia do bucketów stagingowych zgodnie z zasadą najmniejszych uprawnień.
- Monitorować operacje odczytu i zapisu artefaktów modeli w Cloud Storage.
- Wdrożyć walidację integralności modeli przed rejestracją i wdrożeniem.
- Unikać ładowania artefaktów opartych o pickle i joblib, jeżeli ich pochodzenie nie jest w pełni zaufane.
- Rozważyć dodatkowe kontrole supply chain dla modeli ML, takie jak podpisywanie artefaktów, sumy kontrolne i etap zatwierdzania przed deploymentem.
Organizacje powinny też przeprowadzić przegląd architektury MLOps pod kątem zależności od przewidywalnych nazw zasobów, szczególnie tam, gdzie zarządzane usługi chmurowe komunikują się z infrastrukturą klienta.
Podsumowanie
Luka w Google Vertex AI SDK for Python pokazuje, iż bezpieczeństwo środowisk AI zależy nie tylko od jakości modeli, ale także od poprawności logiki klienta, kontroli własności zasobów i bezpieczeństwa całego procesu stagingu. Połączenie przewidywalnej nazwy bucketu, braku weryfikacji właściciela i możliwości deserializacji niebezpiecznych artefaktów stworzyło realny scenariusz przejęcia uploadu modelu.
Dla zespołów bezpieczeństwa i inżynierów MLOps to wyraźny sygnał, iż pipeline’y ML należy traktować jak pełnoprawny łańcuch dostarczania oprogramowania. Aktualizacja SDK, jawna konfiguracja bucketów i kontrola integralności modeli powinny stać się standardem operacyjnym.
Źródła
- The Hacker News – Google Vertex AI SDK Flaw Let Attackers Hijack Model Uploads via Bucket Squatting
- Unit 42 – Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE
- Google GitHub Releases – Release v1.148.0 · googleapis/python-aiplatform
- Google GitHub Compare – Comparing v1.143.0…v1.144.0 · googleapis/python-aiplatform
- Google Cloud Documentation – Vertex AI Security Bulletins
