Door een fout in de Google Cloud Vertex AI SDK voor Python kon een aanvaller zonder toegang tot het project van een slachtoffer de machine learning-modelupload van het slachtoffer kapen en code uitvoeren binnen de service-infrastructuur van Google.
Palo Alto Networks Unit 42, die de bug heeft gevonden en gerapporteerd via het bugbountyprogramma van Google, noemt de techniek “Augurk in het midden” en zei dat er geen exploitatie in het wild werd gezien. Google heeft het gepatcht; als je de SDK gebruikt, update dan naar versie 1.148.0 of hoger.
De aanvaller had alleen een eigen Google Cloud-project nodig en de project-ID van het slachtoffer, die vaak openbaar is. Geen inloggegevens, geen phishing, geen voet aan de grond in het doelwit.
De fout zat in de manier waarop de SDK een tijdelijke Cloud Storage-bucket koos voor modeluploads. Als een gebruiker geen bucket heeft ingesteld, genereerde de SDK een voorspelbare naam op basis van de project-ID en regio, zoals project-vertex-staging-regio. Er werd gecontroleerd of die emmer bestond, maar niet of het slachtoffer de eigenaar was.
Omdat bucketnamen wereldwijd uniek zijn, kan een aanvaller de verwachte bucket eerst in zijn eigen project maken. De SDK van het slachtoffer uploadt vervolgens de modelbestanden naar de bucket van de aanvaller. De aanvaller kan het geüploade model vervolgens vervangen door een kwaadaardig model.
Veel Python ML-modellen worden opgeslagen met pickle of joblib, waarmee code kan worden uitgevoerd wanneer een bestand wordt geladen. Toen Vertex AI later het verwisselde model laadde, werd de code van de aanvaller uitgevoerd in de serveercontainer.
De aanval was afhankelijk van snelheid. Eenheid 42 mat ongeveer 2,5 seconden tussen het uploaden van het slachtoffer en het lezen van het bestand door Vertex AI. In zijn proof of concept gebruikte de aanvaller een cloudfunctie die na het uploaden werd geactiveerd en het model in 1,4 seconden verving, voordat Vertex AI het las.
De payload stal vervolgens een OAuth-token van de metadataserver van de dienende container en stuurde dit naar de aanvaller. In de testomgeving van Unit 42 was dat token niet beperkt tot de gecompromitteerde implementatie. Het had toegang tot andere modelartefacten in hetzelfde door Google beheerde tenantproject, waaronder een volledig TensorFlow-model met getrainde gewichten, evenals BigQuery-metagegevens, toegangslijsten, tenantlogboeken, GKE-clusternamen en interne containerimagepaden.
De aanval werkte alleen onder specifieke omstandigheden: de standaard staging-bucket van het slachtoffer bestond nog niet in die regio en het slachtoffer verliet de staging_bucket parameter uitgeschakeld. De eerste is gebruikelijk voor een nieuw project in Vertex AI in een regio.
De tweede hangt ervan af of de ontwikkelaar vertrouwt op de standaardwaarde van de SDK in plaats van zijn eigen bucket een naam te geven.
Unit 42 meldde de fout op 5 maart 2026 via het Vulnerability Reward Program van Google. Het testte versies 1.139.0 en 1.140.0, de nieuwste versie die op dat moment beschikbaar was, en vond beide kwetsbaar.
Google heeft op 31 maart een eerste oplossing in v1.144.0 uitgebracht, waarbij een willekeurige uuid4 aan de bucketnaam is toegevoegd. Het voltooide de oplossing in v1.148.0 op 15 april, waarbij verificatie van bucketeigendom werd toegevoegd om bucket-hurken in Model.upload() te blokkeren. Op het moment van publicatie vermelden noch Unit 42, noch de Vertex AI-beveiligingsbulletins van Google een CVE voor dit probleem.
Update naar 1.148.0 of hoger zodat de eigendomscontrole actief is. Stel ook expliciet een staging_bucket in op een Cloud Storage-locatie die u beheert bij het uploaden van modellen. Omdat de gebrekkige logica zich in de client-SDK bevindt, moet u de google-cloud-aiplatform-versie controleren waar deze ook wordt uitgevoerd, inclusief notebooks, CI-taken en trainingspijplijnen, en niet alleen productieservices.
Het is de tweede fout in de voorspelbare bucketnaam die dit jaar aan de oppervlakte komt in Vertex AI. Google heeft in februari CVE-2026-2473 gepatcht, een aparte bucket-squatting-bug in Vertex AI Experiments die ook cross-tenant code-uitvoering, modeldiefstal en vergiftiging mogelijk maakte.
Het eerdere werk van Unit 42 aan de standaard machtigingen voor serviceagenten van Vertex AI volgde een gerelateerd pad van een geïmplementeerde AI-agent naar klant- en huurdergegevens.
