Dialogflow's Rogue Agent Flaw Is a Very Old Bug Class

Varonis published on Monday a writeup of a Google Cloud Dialogflow CX flaw they have been calling the “Rogue Agent” — a stored code-execution issue in the platform’s Code Block feature that let any user with dialogflow.playbooks.update permission compromise every other Code Block-enabled agent in the same Google Cloud project by writing to a single shared file. The Hacker News reprinted the disclosure yesterday. Google shipped an initial fix in April 2026 and the full remediation in June, per Varonis’ timeline, and both parties say there is no evidence the bug was ever used against a real Dialogflow tenant.

There is no CVE. The disclosure went through Google’s Vulnerability Reward Program in November 2025 and, since Dialogflow CX is a first-party Google Cloud service that customers do not patch themselves, it did not get a MITRE identifier on the way out. That is defensible. It is also worth noting up front, so that anyone searching later for a number they can hand to their vulnerability-management workflow understands they are not going to find one.

I want to write about it anyway, because the shape of the bug is not new — it is, on reasonable inspection, a bug class old enough to have graduated shared hosting — and the reason it matters is the class more than the individual case.

What the bug did

Varonis’ walkthrough describes Dialogflow CX Code Blocks as a feature that lets a chatbot builder attach small pieces of Python to a conversational agent’s flow: read a variable, do an arithmetic thing, hit an internal endpoint, decide what the bot says next. In the shipped implementation, every Code Block-enabled agent inside a single Google Cloud project ran against the same Cloud Run instance, and every block’s Python was executed inside that instance by a shared file called code_execution_env.py. The file was writable. It was invoked via exec().

The consequence is what you would expect from that sentence. A user with permission to edit one agent’s Code Block could overwrite code_execution_env.py — from inside their own Code Block, at runtime — and from that point on, their code ran every time any Code Block in the project fired, on any agent. Varonis’ summary describes the achievable payload: read live conversations across agents, exfiltrate whatever session data those agents had access to, and rewrite bot responses to ask the user to re-enter their password. Console-visible Code Blocks could be restored to look benign while the overwritten runtime kept doing what the attacker put in it. The GUI stayed clean.

The permission gate is worth being honest about. dialogflow.playbooks.update is not something a random unauthenticated internet user has. It is a real IAM permission granted, typically, to developers and consultants inside the project. The realistic exploitation population — as Google and Varonis both note — is a malicious insider or a compromised developer account. That does not make the bug uninteresting. It makes it the same bug your service-account theft investigation would have surfaced a decade ago, with a chatbot builder rendered on top.

Where I have seen this before

Shared hosting spent the late 1990s and early 2000s learning that a single writable file executed on behalf of every tenant is not a runtime, it is an escape hatch. mod_php shipped multiple variants of the problem before per-user PHP-FPM pools and mpm-itk were widely deployed. PHP include directives pointed at writable directories inside a shared docroot were, for a long stretch, the standard cross-account compromise on cheap web hosts — the whole reason open_basedir exists as a runtime knob. WordPress plugin ecosystems replayed the same failure a few years later inside single-tenant sites: one plugin’s writable wp-content directory hosting the require() targets for every plugin’s execution path.

The class predates the web. The setuid-shell papers of the 1980s described the same pattern in Unix: an executable running as another principal, mediated by a mutable input that a lower-privileged user could write to. The class had a name and a body of literature before most Dialogflow CX customers were born.

This is the same mistake, different decade. AI-agent products are being built at the pace of a demo, and they are inheriting the runtimes that spent twenty-five years learning where the boundaries actually go. When those boundaries get relearned inside a new product surface, it looks like a novel disclosure — a “Rogue Agent” attack, a first-of-its-kind cross-agent escape — but the actual finding is that a specific class of isolation error got shipped inside a specific product because the product’s runtime is younger than the class.

Varonis’ framing is not wrong for calling it what it is. The class is what it is because we already named it.

What was actually fixed

Google’s remediation, per the disclosure, went out in two passes. An initial fix in April 2026 that Varonis’ team was not fully satisfied with, and a complete resolution in June. Neither pass got a CVE number, for the reason above, and Varonis waited until July to publish — three months past the vendor closing the case. That is a reasonable disclosure cadence for a fully-remediated first-party service, and consistent with how Google’s VRP has handled its other recent Cloud disclosures.

Neither Google nor Varonis has surfaced evidence the flaw was exploited before the fix. Both parties are explicit about that. If any customer of Dialogflow CX has telemetry to the contrary they should tell Google; nothing in the current record suggests they will.

What to actually take from this

If you run Dialogflow CX Code Blocks in a Google Cloud project with more than one developer or third-party consultant holding dialogflow.playbooks.update, review the IAM grants against that permission today. You have already been patched by the vendor — the concern is not this specific bug, it is that the permission gate is one of the boundaries your future audit is going to care about, and this disclosure is the moment to notice it exists.

If you do not run Dialogflow CX Code Blocks, the take-home is different. The AI-agent builder categories — Dialogflow, Bedrock Agents, Copilot Studio, and their peers — are early enough in their runtime lifecycle that the isolation-error backlog is still being written. The Orchid IGA writeup from earlier this week argued the identity-governance layer around agents is fifteen years behind; this disclosure suggests the execution-isolation layer is roughly the same distance behind. Neither of those gaps closes because a specific product ships a specific fix. They close because the runtime authors work through the class the way shared hosting had to.

Which is to say: expect more of these. Not because Dialogflow is bad, or because Varonis will keep finding them, but because a lot of code that executes user input on shared infrastructure got written on top of runtimes that have not read the earlier chapters yet.

The dashboard will not tell you that. Someone has to.

Sources

• Ravie Lakshmanan. Rogue Agent Flaw Could Have Let Attackers Hijack Google Dialogflow CX Chatbots. The Hacker News, July 7, 2026.
• Varonis Threat Labs disclosure via Google’s Vulnerability Reward Program, November 2025; initial fix April 2026; full remediation June 2026 (per the Hacker News summary of Varonis’ timeline).
• Google Cloud. Dialogflow CX documentation.