Viele Unternehmen behandeln Machine-Learning-Pipelines inzwischen wie klassische Software-Lieferketten: Code wird versioniert, Modelle werden gebaut, Artefakte landen in Registries, anschließend folgt das Deployment in eine Cloud-Laufzeitumgebung. Genau an dieser unscheinbaren Übergabestelle setzte die Schwachstelle an, die Palo Alto Networks Unit 42 am 16. Juni unter dem Namen „Pickle in the Middle“ veröffentlichte. Betroffen war das Python-SDK google-cloud-aiplatform für Google Cloud Vertex AI. Unter bestimmten Bedingungen konnte ein Angreifer ohne Zugriff auf das Projekt des Opfers einen Model-Upload kapern, das hochgeladene Modell austauschen und beim späteren Laden Code in der Vertex-AI-Serving-Umgebung ausführen.
Das ist kein Anlass für pauschale Cloud-Panik. Google hat die Lücke nach Angaben von Unit 42 bereits im April 2026 geschlossen; The Hacker News berichtet ebenfalls, Nutzer sollten auf Version 1.148.0 oder neuer aktualisieren. Für Unternehmen bleibt der Fall trotzdem relevant. Er zeigt präzise, wo klassische Cloud-Sicherheitsannahmen in AI-/ML-Workflows nicht mehr ausreichen: Kritisch sind nicht nur produktive Endpunkte, sondern auch Client-SDKs, temporäre Staging-Buckets, Modellformate und die Identitäten, mit denen Managed Services Artefakte lesen.
Der technische Kern: vorhersehbarer Staging-Bucket plus fehlende Besitzprüfung
Vertex AI nutzt beim Upload eines Modells über das Python-SDK einen Zwischenschritt. Modellartefakte werden zunächst in einem Google-Cloud-Storage-Bucket abgelegt. Danach referenziert die Model Registry diese Artefakte, und die Serving-Infrastruktur lädt sie später in einen Container. Wenn Entwickler keinen eigenen staging_bucket setzten, erzeugten verwundbare SDK-Versionen laut Unit 42 einen Bucket-Namen aus Projekt-ID und Region, etwa nach dem Muster <project>-vertex-staging-<region>.
Der Schwachpunkt: Cloud-Storage-Bucket-Namen sind global eindeutig. Wer einen vorhersagbaren Bucket-Namen kennt, kann ihn in einem eigenen Projekt vorab registrieren. Das SDK prüfte zwar, ob der Bucket existiert. In den betroffenen Versionen prüfte es aber nicht ausreichend, ob der Bucket tatsächlich zum Projekt des aufrufenden Nutzers gehörte. Existierte der vorhergesagte Name bereits im Angreiferprojekt, konnte der Upload laut Unit 42 in den fremden Bucket laufen.
Damit war der Angriff noch nicht abgeschlossen. Der Angreifer musste das legitime Modell nach dem Upload rasch durch ein manipuliertes Artefakt ersetzen, bevor Vertex AI es weiterverarbeitete. Unit 42 nennt ein Zeitfenster von ungefähr 2,5 Sekunden; im Proof of Concept ersetzte eine Cloud Function das Artefakt nach rund 1,4 Sekunden. Der Name „Pickle in the Middle“ verweist auf pickle und joblib, zwei gängige Serialisierungsformate für Python-Modelle. Sie sind bequem, aber sicherheitstechnisch problematisch: Wer eine Pickle-Datei kontrolliert, kann beim Deserialisieren Code ausführen lassen.
Warum das mehr ist als ein exotischer Cloud-Bug
Der Angriff erforderte nach den veröffentlichten Informationen mehrere Bedingungen. Das Opfer musste einen verwundbaren SDK-Stand einsetzen, keinen expliziten Staging-Bucket konfigurieren und in einer Region arbeiten, in der der automatisch erwartete Default-Bucket noch nicht existierte. Außerdem musste der Angreifer die Projekt-ID kennen und schnell genug reagieren.
Trotzdem ist das Angriffsmuster für viele AI-Plattformen relevant. ML-Workflows bestehen nicht nur aus Quellcode, sondern aus Artefakten: Modelle, Tokenizer, Embeddings, Konfigurationsdateien und Container-Images wandern durch Registries, Buckets, Caches und temporäre Speicher. Wenn Herkunft, Besitz und Integrität an einer dieser Stellen nicht sauber geprüft werden, entsteht eine Supply-Chain-Schwachstelle im AI-Lebenszyklus. Genau deshalb ist der Fall für Security- und Plattformteams interessant.
Unit 42 beschreibt, dass der Schadcode in der Testumgebung ein OAuth-Token aus dem Metadata-Server der Serving-Umgebung auslesen konnte. The Hacker News ergänzt, dass der Token in Unit-42s Test nicht nur auf das kompromittierte Deployment beschränkt war, sondern Zugriff auf weitere Artefakte und Metadaten im Google-managed Tenant-Kontext ermöglichte. Diese Details sollte man nicht überbewerten. Sie stammen aus einer kontrollierten Forschungsumgebung und belegen keine aktive Ausnutzung. Unit 42 schreibt, dass keine Ausnutzung in freier Wildbahn bekannt sei. Für die Risikobewertung reicht aber bereits die Architekturklasse: Ein manipuliertes ML-Artefakt kann von einer hochprivilegierten Managed-Service-Identität gelesen werden.
Faktenstand und Patch-Lage
Die wichtigsten belastbaren Daten stammen aus dem Unit-42-Bericht und der Berichterstattung von The Hacker News. Unit 42 meldete die Schwachstelle nach eigenen Angaben am 5. März 2026 über das Vulnerability Reward Program an Google. Getestet wurden die SDK-Versionen 1.139.0 und 1.140.0; Version 1.140.0 soll zum Testzeitpunkt aktuell gewesen sein. Google habe am 31. März einen ersten Fix ausgerollt und am 15. April mit Version 1.148.0 eine vollständige Korrektur bereitgestellt. Diese ergänzte unter anderem eine Besitzprüfung für Buckets in Model.upload(); zuvor wurde laut Bericht auch die Namensgebung durch eine zufällige UUID gehärtet.
Ein CVE wurde in der Berichterstattung nicht genannt. Für interne Maßnahmen ist das zweitrangig. Entscheidend ist, ob in Notebooks, CI/CD-Jobs, Trainingspipelines oder Produktionsautomatisierung noch alte Versionen von google-cloud-aiplatform laufen. Gerade in Data-Science-Umgebungen ist diese Frage nicht trivial. Bibliotheken stecken oft in langlebigen Notebook-Images, privaten Docker-Basisimages oder Build-Caches. Ein zentraler Paket-Scan der Produktionsservices reicht deshalb nicht aus.
Konkrete Implikationen für Unternehmen
Erstens sollten Teams das SDK inventarisieren. Die Suche darf sich nicht auf produktive Services beschränken. Relevant sind alle Orte, an denen Modelle mit Vertex AI registriert oder hochgeladen werden: Entwicklernotebooks, Vertex-Workbench-Images, GitHub-Actions- oder GitLab-CI-Jobs, Airflow-/Kubeflow-Pipelines, interne Trainingscontainer und Beispiel-Repositories. Zielversion ist mindestens google-cloud-aiplatform 1.148.0.
Zweitens sollten Teams den Default-Pfad vermeiden. Wer einen expliziten staging_bucket setzt, der unter eigener Kontrolle steht, reduziert die Angriffsfläche deutlich. Der Bucket sollte projekt- und umgebungsspezifisch sein, mit restriktiven IAM-Rechten, Logging, Object-Versioning je nach Bedarf und klarer Lifecycle-Policy. Wichtig ist außerdem, dass Service-Accounts nur die Rechte erhalten, die sie für Upload, Registrierung und Deployment tatsächlich benötigen.
Drittens gehört Modellintegrität in den Prozess. Unternehmen können Hashes, Signaturen oder attestierte Build-Metadaten für Modellartefakte erfassen und beim Deployment prüfen. Das löst nicht jedes Problem — eine kompromittierte Pipeline kann auch signierte schlechte Artefakte erzeugen. Es verschiebt die Kontrolle aber weg vom blinden Vertrauen in temporäre Speicherorte. Besonders riskant sind Pickle- und Joblib-Artefakte aus unklarer Herkunft. Wo möglich, sollten sicherere Formate oder zusätzliche Prüfungen genutzt werden.
Viertens sollten Metadata-Server und Managed-Service-Identitäten Teil der Bedrohungsmodellierung sein. In Cloud-Umgebungen sind Tokens aus Metadata-Services ein häufiger Hebel für laterale Bewegung. Für AI-Serving gilt das genauso wie für klassische Compute-Workloads. Monitoring auf ungewöhnliche Token-Nutzung, restriktive Service-Agent-Berechtigungen und Segmentierung zwischen Trainings-, Staging- und Serving-Umgebungen sind hier keine Luxusmaßnahmen.
Risiken und Grenzen der Bewertung
Der Fall ist bereits gepatcht und erforderte Timing sowie spezifische Fehlkonfigurationen beziehungsweise Default-Nutzung. Er ist daher nicht mit einer breit ausnutzbaren Internet-RCE gleichzusetzen. Zudem stammen die technischen Details vor allem aus der Forschungsperspektive von Unit 42; öffentliche Hinweise auf aktive Angriffe gibt es derzeit nicht.
Trotzdem wäre es falsch, den Vorfall als erledigte Einzelkuriosität abzutun. Unit 42 und The Hacker News weisen darauf hin, dass dies nicht der erste Vertex-AI-Fall mit vorhersehbaren Bucket-Namen in diesem Jahr war. Google patchte im Februar CVE-2026-2473, eine separate Bucket-Squatting-Schwachstelle in Vertex AI Experiments. Das Muster ist wichtiger als der einzelne Bug: Automatisierte AI-Plattformen erzeugen Ressourcen im Hintergrund. Deren Namensgebung, Besitzprüfung und Identitätsgrenzen werden damit selbst zur Sicherheitskontrolle.
Fazit
„Pickle in the Middle“ ist ein gutes Beispiel für die nächste Reifephase von AI-Security. Es geht nicht mehr nur um Prompt Injection, Modellmissbrauch oder Datenschutz im Chatfenster. Unternehmen müssen die gesamte AI-Lieferkette absichern: SDK-Versionen, temporäre Buckets, Artefaktformate, Managed-Service-Identitäten und Deployment-Pipelines. Die praktischen Sofortmaßnahmen sind überschaubar: google-cloud-aiplatform auf mindestens 1.148.0 aktualisieren, explizite eigene Staging-Buckets konfigurieren, alte Notebook- und CI-Images prüfen und Modellartefakte wie sicherheitsrelevante Software behandeln. Wer AI produktiv betreibt, sollte den Fall als Erinnerung verstehen: Der schwächste Punkt liegt oft nicht im Modell, sondern auf dem Weg dorthin.
Quellen: Palo Alto Networks Unit 42, „Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE“, 16.06.2026; The Hacker News, „Google Vertex AI SDK Flaw Let Attackers Hijack Model Uploads via Bucket Squatting“, 16.06.2026.
