Критична уязвимост в платформата Dialogflow CX на Google е можела да позволи на атакуващ с права за редактиране на един агент с активиран Code Block да компрометира други агенти с активиран Code Block в същия Google Cloud проект.

Оттам те биха могли да четат разговори в реално време, да крадат данни, споделени от потребителите, и да накарат ботовете да изпращат съобщения, написани от атакуващия, включително заявки за повторно въвеждане на парола.

Фирмата за сигурност Varonis открива пролуката и я нарича Rogue Agent. Уязвимостта засяга само организации, които изграждат агенти с Playbooks на Dialogflow и персонализирани Code Blocks, позволяващи на разработчиците да добавят собствен Python код. Това не е отдалечена атака без оторизация.

Изпълнението на атаката изисква разрешението dialogflow.playbooks.update за един такъв агент, което ограничава реалистичния атакуващ до злонамерен вътрешен човек или компрометиран акаунт на разработчик. От тази първоначална точка обаче достъпът се разширява до всеки агент в проекта.

Google отстрани проблема, като и Varonis, и Google заявяват, че няма доказателства уязвимостта да е била експлоатирана в реални атаки.

Един файл с права за писане е изпълнявал кодовите блокове на всеки агент

Функцията Code Blocks в Dialogflow позволява на разработчиците да добавят персонализиран Python код към потока от разговори на чатбота за проверка на въведените данни, контрол на поведението и извикване на дефинирани инструменти. Този код се изпълнява в управлявана от Google среда Cloud Run, като всеки агент, който използва Code Blocks в същия Google Cloud проект, споделя една и съща инстанция.

Google управлява тази среда, клиентите не могат да я виждат или контролират, а Varonis не открива реална изолация между отделните агенти в нея.

Когато агент изпълнява Code Block, кодът на разработчика се добавя към вътрешен код за настройка и се предава на функцията exec() на Python. Този код за настройка дефинира променливите и функциите, до които блокът има достъп. Променливите включват хронология на целия разговор и състояние на сесията (като идентификатор на сесията). Функциите включват respond(), която кара бота да отговори с определен низ.

Varonis открива, че файлът, който извършва това обвиване, code_execution_env.py, се намира в споделената среда с права за писане.

Поради тази причина един-единствен Code Block е можел да го замени. Този блок изтегля модифициран code_execution_env.py от контролиран от атакуващия сървър и пренаписва оригиналния файл в работещия контейнер.

От този момент нататък версията на атакуващия се изпълнява при всяко стартиране на Code Block във всички агенти, споделящи тази среда. Тя се намира в същия обхват като легитимния код и има същия достъп до хронологията, състоянието и функцията respond().

Това позволява на атакуващия да чете всеки разговор, тихо да го изпраща към свой сървър и да кара бота да публикува негови съобщения (например фишинг заявки за повторно потвърждаване на входни данни).

За да прикрие следите си, атакуващият възстановява оригиналния Code Block в конзолата на Dialogflow. Това променя само показаното в конзолата; пренаписаният файл вече работи в контейнера и продължава да се изпълнява под повърхността.

Изтичане на данни от пясъчника по още два начина

Varonis докладва за два свързани проблема, нито един от които не изисква пренаписване на файл. Първо, средата на Code Block е имала неограничен изходящ достъп до интернет. Използвайки вградената библиотека urllib, изследователите са изпратили данни директно към външен сървър и са успели да получат обратно команди.

Според Varonis това заобикаля VPC Service Controls – защитния периметър на Google Cloud, предназначен да спре изтичането на данни от защитени услуги.

Второ, средата е разкривала услугата за метаданни на инстанцията (IMDS) – вътрешна крайна точка, която издава облачни акаунти за самоличност. Запитването към нея е връщало токен за управляван от Google служебен акаунт с ниски привилегии.

Почти нищо не е записвано в регистрационните файлове (логовете)

Пренаписването е ставало в средата на Google, където клиентите нямат видимост, а Cloud Logging не е регистрирал промяната на файла или инжектирания код. Това прави откриването на атаката трудно, макар и не невъзможно, от страна на клиента чрез проверка на настройките и DATA_WRITE одит логовете за неочаквани актуализации на playbooks.

Varonis разкрива уязвимостта чрез програмата за награждаване на Google през ноември 2025 г. Google пуска първоначална корекция през април 2026 г. и напълно отстранява проблема през юни 2026 г. Не е присвоен CVE идентификатор.