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 the security firm 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.

Here is the plain version of what went wrong.

A company might run several chatbots inside one Google Cloud project, which is basically a shared workspace on Google's cloud. Think of it as one office building with many tenants. In theory, each bot should stay in its own room. Varonis found that a person with permission to edit 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, the attacker could do three unpleasant things. They could listen in on live conversations between real users and the bots. They could steal whatever those users had typed, which for customer-service bots often includes names, account numbers, order details, and sometimes payment or health information. And they could 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," or request a one-time code, or push them to a fake payment page. Because the message comes from the real company's chatbot on the real company's website, most people would type the answer in without a second thought.

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

Multi-factor authentication, the extra code or app tap you use when logging in, would not have helped here. The attacker was already a legitimate user of the platform. The problem was on the permissions side, not the login side.

Should ordinary customers be worried?

Probably not, but there is a small lesson worth taking away. 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 do not need to change any passwords because of this specific bug.

The broader habit is the useful bit. If a chatbot on any website 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. Go to the company's main site or app in a fresh browser 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 is also a good moment to check who actually has edit rights on your agents, and to strip back permissions where they are wider than they need to be. The principle of least privilege, meaning give each person only the access they truly need, exists for exactly this kind of day.