Een kritieke fout in Dialogflow CX van Google had een aanvaller met bewerkingsrechten op één agent die Code Block ondersteunt, andere agenten met Code Block in hetzelfde Google Cloud-project kunnen laten compromitteren.
Van daaruit konden ze live gesprekken lezen, de gegevens stelen die gebruikers deelden en de bots door de aanvaller geschreven berichten laten sturen, inclusief verzoeken om een wachtwoord opnieuw in te voeren.
Beveiligingsbedrijf Varonis vond het en noemde het Rogue Agent. De fout trof alleen organisaties die agenten bouwden met Dialogflow’s Playbooks en aangepaste codeblokken, waarmee ontwikkelaars hun eigen Python konden toevoegen. En het was geen afgelegen, niet-geauthenticeerde aanval.
Om dit voor elkaar te krijgen was de toestemming dialogflow.playbooks.update nodig voor een dergelijke agent, waardoor de realistische aanvaller beperkt blijft tot een kwaadwillende insider of een gecompromitteerd ontwikkelaarsaccount, en niet tot een vreemde op internet. Vanaf dat ene steunpunt breidde het bereik zich echter uit naar alle agenten in het project.
Google heeft het probleem opgelost en zowel Varonis als Google zeggen dat er geen aanwijzingen zijn dat de fout ooit bij een echte aanval is gebruikt.
Eén beschrijfbaar bestand bevatte de codeblokken van elke agent
Met de codeblokken van Dialogflow kunnen ontwikkelaars aangepaste Python toevoegen aan de gespreksstroom van een chatbot om invoer te controleren, gedrag te controleren en gedefinieerde tools aan te roepen. Die code wordt uitgevoerd in een door Google beheerde Cloud Run-omgeving, en elke agent die Code Blocks gebruikt in hetzelfde Google Cloud-project deelt één exemplaar ervan.
Google beheert die omgeving, de klant kan deze niet zien of controleren, en Varonis vond geen echte isolatie tussen de agenten erin.
Wanneer een agent een codeblok uitvoert, wordt de code van de ontwikkelaar toegevoegd aan de interne installatiecode en doorgegeven aan de functie exec() van Python. Die instelcode definieert de variabelen en functies die het blok kan aanraken. Variabelen omvatten de geschiedenis van het volledige gesprek en de status van sessiedetails zoals de sessie-ID. Functies omvatten respond(), waardoor de bot antwoordt met een bepaalde string.
Varonis vond het bestand dat deze verpakking doet, code_execution_env.py, in de gedeelde omgeving met schrijftoegang.
Omdat dat bestand beschrijfbaar was, kon een enkel codeblok het vervangen. Dat blok downloadt een gewijzigde code_execution_env.py van een door een aanvaller bestuurde server en overschrijft het origineel in de actieve container.
Vanaf dat moment wordt de versie van de aanvaller uitgevoerd voor elke codeblokuitvoering op elke agent die die omgeving deelt. Het valt binnen hetzelfde bereik als legitieme code, met dezelfde toegang tot geschiedenis, status en respond().
Hierdoor kan het elk gesprek lezen, het stilletjes naar de server van de aanvaller sturen en de bot door de aanvaller geschreven berichten laten posten. Een voorbeeld is phishing: de bot vraagt de gebruiker om een login opnieuw te verifiëren, en de aanvaller verzamelt wat hij typt.
Om de sporen uit te wissen, herstelt de aanvaller het originele codeblok in de Dialogflow-console. Dat verandert alleen wat de console weergeeft; het overschreven bestand draait al in de container en blijft daaronder worden uitgevoerd.
De sandbox lekte nog op twee manieren
Varonis rapporteerde twee gerelateerde problemen, en bij geen van beide hoefde het bestand te worden overschreven. Ten eerste had de Code Block-omgeving onbeperkte uitgaande internettoegang. Met behulp van de ingebouwde urllib-bibliotheek stuurden de onderzoekers gegevens rechtstreeks naar een externe server en konden ze opdrachten terugkrijgen.
Varonis zegt dat dit de VPC Service Controls omzeilt, de Google Cloud-perimeter die bedoeld is om te voorkomen dat gegevens beschermde services verlaten. De omgeving bevindt zich buiten die perimeter en kan het open internet bereiken, waardoor het een kanaal wordt voor zowel gegevensdiefstal als afstandsbediening.
Ten tweede, en minder ernstig, stelde de omgeving de Instance Metadata Service (IMDS) bloot, een normaal gesproken intern eindpunt dat cloudreferenties uitdeelt. Bij het uitvoeren van een zoekopdracht werd een token geretourneerd voor een door Google beheerd serviceaccount.
Dat account had weinig rechten, dus het directe risico was beperkt; het echte punt is dat een sandbox voor code-uitvoering IMDS helemaal niet zou moeten kunnen bereiken.
Bijna niets bereikte de boomstammen
Het overschrijven gebeurde in de omgeving van Google, waar klanten geen zicht hebben, en Cloud Logging heeft de bestandswijziging of de geïnjecteerde code niet geregistreerd.
Dat maakt het moeilijk, maar niet onmogelijk, om dit vanuit de klantkant te begrijpen. De instelacties laten nog steeds sporen achter, waar de onderstaande controles op vertrouwen.
Varonis maakte de fout in november 2025 bekend via het Vulnerability Reward Program van Google. Google bracht in april 2026 een eerste oplossing en loste deze volledig op in juni 2026, ongeveer zeven maanden van rapport tot oplossing. Er werd geen CVE toegekend.
Wat u moet controleren als u codeblokken heeft gebruikt
Als u vóór de oplossing Dialogflow CX-agents met Code Block Playbooks hebt uitgevoerd en wilt bevestigen dat u niet het doelwit bent, begin dan met toegang.
De toestemming dialogflow.playbooks.update is het hele toegangspunt, dus controleer welke rollen en accounts deze bevatten.
Dan:
- Controleer uw DATA_WRITE-auditlogboeken voor de Dialogflow API op onverwachte playbook-updates en correleer deze met ongebruikelijke gebruikers, IP-adressen of toegangstijden.
- Voer een Cloud Logging-query uit voor mislukte gebruikersverzoeken, waarbij de foutmeldingen uitzonderingen aan het licht kunnen brengen die door kwaadaardige codeblokken zijn gegenereerd.
- Open in de Dialogflow-console Playbooks voor elke agent en bevestig dat elk codeblok een codeblok is dat u heeft goedgekeurd.
Een ander soort AI-fout
Veel recente AI-beveiligingsfouten hebben geleid tot een misleiding van het model.
Varonis’ eigen Reprompt en SearchLeak veranderden een enkele klik in gegevensdiefstal in Microsoft’s Copilot. ForcedLeak van Noma Security verborg instructies in een Salesforce-webformulier om CRM-gegevens op te halen.
De onderzoekers van Microsoft lieten zien dat snelle injectie omslaat in code-uitvoering in het Semantic Kernel-framework. Rogue Agent heeft het model helemaal niet aangeraakt. Het maakte misbruik van een normale ontwikkelaarsfunctie en een gedeelde, onzichtbare runtime, bereikbaar met één gewone bewerkingsmachtiging.
In een dergelijke opzet is een toestemming die eruit ziet als een recht om inhoud te bewerken, feitelijk een recht om code uit te voeren. Iedereen die een codeblok kan toevoegen, kan willekeurige Python uitvoeren in een gedeelde omgeving die de klant niet kan inspecteren.
Behandel machtigingen voor het bewerken van agenten als de runtime-besturingselementen die ze zijn. Zelfs als de provider zegt dat er niets hoeft te worden gerepareerd, kunnen klanten nog steeds niet zelf in die runtime kijken.
