Der Kern des Problems lag in der Standardlogik des SDK für Modell-Uploads. Wenn kein Bucket gesetzt war, erzeugte das SDK aus Projekt-ID und Region einen vorhersagbaren Namen nach dem Muster „project-vertex-staging-region“. Zwar prüfte das SDK, ob dieser Bucket existierte, aber nicht, ob er dem Projekt des Opfers gehörte.
Da Bucket-Namen global eindeutig sind, konnte ein Angreifer den erwarteten Bucket vorab im eigenen Projekt anlegen. Das SDK des Opfers lud die Modelldateien dann in diesen fremden Bucket hoch. Anschließend konnte der Angreifer das hochgeladene Modell durch eine manipulierte Version ersetzen.
Brisant wurde das, weil viele Python-Modelle mit pickle oder joblib gespeichert werden. Diese Formate können beim Laden einer Datei Code ausführen. Wenn Vertex AI das ausgetauschte Modell später lud, wurde der eingeschleuste Code innerhalb des Serving-Containers ausgeführt.
Die Attacke war allerdings zeitkritisch. Unit 42 maß rund 2,5 Sekunden zwischen dem Upload des Opfers und dem Einlesen der Datei durch Vertex AI. Im Proof of Concept nutzten die Forscher eine Cloud Function, die nach dem Upload ausgelöst wurde und das Modell innerhalb von 1,4 Sekunden ersetzte, also noch bevor Vertex AI darauf zugriff.
In der Testumgebung von Unit 42 stahl die Schadlast anschließend ein OAuth-Token vom Metadatenserver des Serving-Containers und übermittelte es an den Angreifer. Dieses Token war dort nicht auf die kompromittierte Bereitstellung beschränkt. Laut Unit 42 erlaubte es den Zugriff auf weitere Modellartefakte im selben von Google verwalteten Tenant-Projekt, darunter ein vollständiges TensorFlow-Modell mit trainierten Gewichten sowie BigQuery-Metadaten, Zugriffslisten, Tenant-Logs, GKE-Clusternamen und interne Pfade von Container-Images.
Der Angriff funktionierte nur unter bestimmten Bedingungen. Der standardmäßige Staging-Bucket des Opfers durfte in der jeweiligen Region noch nicht existieren, und der Parameter staging_bucket musste ungesetzt bleiben. Vor allem die erste Voraussetzung sei bei einem neuen Vertex-AI-Projekt in einer Region häufig erfüllt, so Unit 42.
Unit 42 meldete die Schwachstelle am 5. März 2026 über Googles Vulnerability Reward Program. Getestet wurden die damals aktuellen Versionen 1.139.0 und 1.140.0; beide erwiesen sich als verwundbar. Google veröffentlichte zunächst in v1.144.0 am 31. März einen ersten Fix, der dem Bucket-Namen ein zufälliges uuid4 hinzufügte. Vollständig abgeschlossen wurde die Korrektur in v1.148.0 am 15. April: In Model.upload() prüft das SDK nun zusätzlich den Besitz des Buckets, um Bucket Squatting zu verhindern.
Zum Zeitpunkt der Veröffentlichung führten weder Unit 42 noch die Vertex-AI-Sicherheitsbulletins von Google eine CVE-Nummer für das Problem. Google empfiehlt ein Update auf 1.148.0 oder neuer, damit die Besitzprüfung aktiv ist. Außerdem sollte beim Upload ein expliziter staging_bucket auf eine selbst kontrollierte Cloud-Storage-Position gesetzt werden. Da die fehlerhafte Logik im Client-SDK steckt, sollte laut Quelltext die Version von google-cloud-aiplatform überall geprüft werden, wo sie läuft, also auch in Notebooks, CI-Jobs und Training-Pipelines.
Es handelt sich bereits um den zweiten Fehler dieser Art in Vertex AI in diesem Jahr. Google hatte im Februar bereits CVE-2026-2473 behoben, einen separaten Bucket-Squatting-Fehler in Vertex AI Experiments, der ebenfalls mandantenübergreifende Codeausführung, Modelldiebstahl und Vergiftung ermöglichte. Zudem hatte Unit 42 in früheren Untersuchungen zu den Standardrechten des Vertex-AI-Service-Agenten einen verwandten Pfad von einem bereitgestellten KI-Agenten zu Kunden- und Tenant-Daten nachgezeichnet.