Varonis zufolge lag das Kernproblem in der Art, wie Dialogflow CX benutzerdefinierten Python-Code in Code Blocks ausführt. Diese Code Blocks erlauben es Entwicklern, die Gesprächslogik eines Chatbots anzupassen, Eingaben zu prüfen, Verhalten zu steuern und definierte Werkzeuge aufzurufen. Der Code läuft in einer von Google verwalteten Cloud-Run-Umgebung. Alle Agents in demselben Google-Cloud-Projekt, die Code Blocks verwenden, teilen sich dabei dieselbe Instanz dieser Laufzeitumgebung.
Nach Angaben von Varonis fehlte innerhalb dieser gemeinsamen Umgebung eine wirksame Trennung zwischen den einzelnen Agents. Wenn ein Agent einen Code Block ausführt, wird der Entwicklercode an internen Initialisierungscode angehängt und an Pythons Funktion exec() übergeben. Dieser Initialisierungscode definiert die Variablen und Funktionen, auf die der Block zugreifen darf. Dazu gehören unter anderem der vollständige Gesprächsverlauf, Sitzungszustände wie die Session-ID sowie die Funktion respond(), mit der der Bot Antworten senden kann.
Die Forscher entdeckten in der geteilten Umgebung die Datei code_execution_env.py mit Schreibrechten. Dadurch konnte ein einzelner Code Block diese Datei ersetzen. Laut Varonis ließ sich eine manipulierte version von einem vom Angreifer kontrollierten Server herunterladen und in dem laufenden Container über das Original schreiben. Anschließend lief die manipulierte Fassung bei jeder Ausführung von Code Blocks über sämtliche Agents hinweg, die dieselbe Umgebung nutzten.
Damit hätte ein Angreifer jede laufende Unterhaltung mitlesen, die von Nutzern übermittelten Daten abgreifen und Bots dazu bringen können, fremdverfasste Nachrichten zu verschicken. Varonis nennt als Beispiel Phishing: Der Bot fordert Nutzer zur erneuten Bestätigung einer Anmeldung auf, während der Angreifer die Eingaben entgegennimmt. Um Spuren zu verwischen, konnte der ursprüngliche Code Block in der Dialogflow-Konsole wiederhergestellt werden. Laut Varonis änderte das jedoch nur die Anzeige in der Konsole; die überschriebene Datei lief im Container weiter.
Zusätzlich meldete Varonis zwei verwandte Probleme, die kein Überschreiben von Dateien voraussetzten. Erstens verfügte die Code-Block-Umgebung über uneingeschränkten ausgehenden Internetzugang. Mit der eingebauten Bibliothek urllib konnten die Forscher Daten direkt an einen externen Server senden und von dort Befehle empfangen. Varonis erklärt, dies umgehe VPC Service Controls, also den Google-Cloud-Perimeter zum Schutz vor Datenabfluss aus geschützten Diensten. Die Umgebung liege außerhalb dieses Perimeters und könne das offene Internet erreichen.
Zweitens war laut Varonis auch der Instance Metadata Service zugänglich, ein normalerweise interner Endpunkt zur Ausgabe von Cloud-Anmeldedaten. Eine Abfrage lieferte ein Token für ein von Google verwaltetes Dienstkonto. Dieses Konto war nur mit geringen Rechten ausgestattet, weshalb das unmittelbare Risiko begrenzt gewesen sei. Varonis betont jedoch, dass eine Sandbox für Codeausführung den Dienst grundsätzlich nicht erreichen sollte.
Die Änderungen fanden in einer von Google betriebenen Umgebung statt, in die Kunden keinen Einblick haben. Außerdem zeichnete Cloud Logging weder die Dateiveränderung noch den eingeschleusten Code auf. Das erschwert laut Varonis die Erkennung aus Kundensicht, auch wenn vorbereitende Schritte Spuren hinterlassen.
Varonis meldete die Schwachstelle im November 2025 über Googles Vulnerability Reward Program. Google stellte im April 2026 zunächst einen Fix bereit und behob das Problem im Juni 2026 vollständig. Eine CVE-Nummer wurde nicht vergeben. Varonis und Google erklären übereinstimmend, dass es keine Hinweise auf eine Ausnutzung in realen Angriffen gibt.