Google Chatbot Flaw Let Attackers Hijack Other Bots and Read User Chats

Key points

• Researchers at Varonis found a critical flaw in Google Dialogflow CX, the platform companies use to build customer-service chatbots.
• An attacker with edit rights on one chatbot could jump to other chatbots in the same Google Cloud project, according to the Varonis disclosure.
• The flaw let attackers read live conversations, steal data users typed in, and make bots send fake messages, including password re-entry prompts.
• Google has fixed the issue; no confirmed abuse in the wild has been reported.
• The bug affected chatbots that used Code Blocks, a feature that lets developers run custom code inside a bot's conversation flow.

Google has patched a serious flaw in Dialogflow CX, its cloud service for building customer-service chatbots, that let one rogue chatbot quietly take over its neighbours.

The bug was found by Varonis and first reported by The Hacker News. It affected bots that used a feature called Code Blocks, which lets developers drop small pieces of custom code into a chatbot's conversation flow to do things like look up an order or check a balance. Varonis has been busy: we covered their earlier work chaining three Copilot Enterprise Search weaknesses into a full data-exfiltration path in our 19 June story.

A company might run several chatbots inside one Google Cloud project, a shared workspace on Google's cloud. Think of it as one office building with multiple tenants. In theory, each bot stays in its own room. Varonis found that a person with edit rights on just one Code Block-enabled bot could walk through the walls and reach every other Code Block-enabled bot in that same project.

Once inside, an attacker could listen in on live conversations and steal whatever users had typed, which for customer-service bots often includes names, account numbers and payment details. They could also put words in the bot's mouth, making it send messages the company never wrote.

That last part is the dangerous one. A hijacked support bot could politely ask a customer to "re-enter your password to continue," request a one-time code, or push them toward a fake payment page. Because the message comes from the real company's chatbot on the real company's website, most people would answer without hesitation.

This is a classic mix-up between authentication, meaning proving who you are, and authorisation, meaning what you're allowed to do once you're in. The Dialogflow system knew who the developer was. It just gave them access to more than it should have.

Multi-factor authentication would not have helped here: the attacker was already a legitimate platform user with the problem sitting entirely on the permissions side. It's the same cross-tenant logic that burned Google's Vertex AI SDK, which we reported in June: a principal scoped to one resource quietly reaching another.

Should ordinary customers be worried?

Probably not. Google has fixed the flaw, and Varonis says it has no evidence anyone abused it before the patch. Customers of companies that use Dialogflow CX don't need to change passwords because of this specific bug.

The broader habit is what counts. If a chatbot suddenly asks you to re-enter your password, hand over a one-time code, or move to a different payment page, stop. Close the chat. Open the company's main site in a fresh tab and log in the normal way. A real support bot almost never needs your password to help you.

For companies running Dialogflow CX, the Varonis writeup is worth a careful read. It's also a good moment to audit who holds edit rights on your agents and strip permissions back where they're wider than necessary. The principle of least privilege, give each person only the access they truly need, exists for exactly this kind of day.