AI Support Chatbots Found Vulnerable to MFA Bypass and OTP Theft

Security researchers Ayoub and Inti De Ceukelaire demonstrated at DEF CON 34 that AI customer service agents can be manipulated to bypass multi-factor authentication, leak one-time passwords, and take unauthorized account actions, earning over $50,000 in bug bounties. The flaws stem from weak email header validation and inconsistent authentication parsing, enabling attackers to impersonate customers and exfiltrate data. The researchers urge companies to treat AI support systems as privileged applications with their own attack surface.

Security researchers have shown that AI https://www.kobaran.com/tag/AI customer service agents deployed by companies to handle support inquiries can be manipulated into bypassing identity verification, leaking one-time passwords, and taking unauthorized actions on customer accounts. The findings, presented at Bug Bounty Village during DEF CON 34, matter now because businesses are rapidly handing these bots access to inboxes, billing systems, and account controls without rethinking how identity gets verified in an AI-mediated workflow. Researchers Ayoub and Inti De Ceukelaire earned more than $50,000 in bug bounties across several weekends of testing, uncovering flaws that stretch well beyond the prompt injection risks most companies already screen for. Their work points instead to a messier problem: the seams between email systems, authentication protocols, backend APIs, knowledge bases, and human review queues, where an AI agent ends up trusting signals no security team would trust on their own. The implications extend past any single vendor’s product. As more companies route support through autonomous AI, the researchers argue these systems need to be treated as privileged applications with their own attack surface, not as simple chat widgets bolted onto a help desk. Email Headers Become a Weak Point A common feature in AI-powered support platforms lets customers receive chat transcripts by email or keep a conversation going from their inbox. That convenience turned out to be exploitable. In one case the researchers documented, an AI agent validated a message’s “From” field so loosely that an attacker could impersonate a victim simply by spoofing that header. Once impersonated, the compromised agent could be induced to send a phishing email from a legitimate, trusted support address, which is worse than an ordinary phishing attempt because it arrives with the credibility of a real company mailbox. Tool Access Raises the Stakes The danger grows sharply once an agent is connected to tools that update account profiles, view billing history, issue refunds, or move data. If a bot authorizes those actions based on an email header an attacker can forge, rather than a verified account identity, it can end up executing commands as though the attacker were the legitimate customer. The researchers also found that simply adding an attacker’s address to a message’s CC field could cause an agent to route confidential account information straight to that address. A Mismatch Between Authentication and Trust A separate problem involves how agents parse multiple header fields inconsistently. Email authentication protocols like SPF and DKIM might validate one sender field, while the AI agent uses a different “From” or “Sender” value to decide whose account it is looking at and where to send a reply. That mismatch means a message can pass legitimate delivery authentication checks while still tricking the agent into pulling up, or sending, another user’s data. Bypassing Multi-Factor Authentication The research also uncovered several ways to get around MFA protections built into these support agents. | Bypass Method | How It Works | Limiting Factor | |---|---|---| | Email normalization quirks | Rate-limit tracking treats minor variations of the same address as separate identities, allowing extra OTP guesses | Fails if OTPs regenerate per attempt or rate limits tie to the account itself | | Cross-channel inconsistency | A chatbot enforces strict OTP attempt limits while a phone-based IVR system opens a fresh, weaker verification flow for the same account | Depends on the IVR relying on caller ID, guessable knowledge questions, or reusable OTPs | | OTP exfiltration via inbox agents | An attacker primes an inbox-monitoring AI with hidden instructions disguised as a message from a trusted sender, then waits for a genuine reset code to arrive | Requires the agent to have both inbox access and autonomous action permissions | Voice Channels Can Undercut Web Security Even when a company’s web-based MFA is solid, a parallel phone system can undo it. If an IVR system falls back on caller ID verification, easily guessed security questions, or OTPs that can be reused, attackers can route around stronger protections simply by switching channels. Exfiltrating One-Time Passwords The researchers describe what may be the most serious scenario: priming a support inbox’s AI agent with malicious instructions dressed up as routine correspondence from a source the system already trusts. When a real password reset code later lands in that inbox, the agent can act on the planted instruction and forward the code to an attacker-controlled destination. Asymmetric Messaging and Poisoned Knowledge Bases A related technique, which the researchers call asymmetric messaging, exploits the fact that a human reviewer may see a harmless HTML-formatted email while the AI system processes a separate plain-text version of the same message containing hidden injected instructions. A comparable risk applies to Retrieval-Augmented Generation systems: poisoned comments or attacker-controlled web pages that get indexed into a company’s knowledge base can end up being treated by the AI as verified, official company content. What Companies Are Being Told to Fix The researchers laid out a set of defensive priorities for any organization running AI in customer support, starting with the premise that these agents should be treated as privileged applications rather than chat interfaces: - Tie every sensitive action to a normalized, server-verified account identity with a fresh authorization check, not to whatever header the request arrived with - Treat email display names, caller ID, quoted email threads, and anything the model “remembers” from earlier in a conversation as unverified, not proof of who someone is - Require additional step-up verification before allowing profile edits, refunds, financial transactions, or the disclosure of personal data - Keep OTPs and other security-related emails walled off from any inbox an autonomous agent can read or act on - Limit what tools an agent can call, validate everything it sends those tools, and log every action the agent takes - Keep user-generated content separate from official company material before either gets indexed into a RAG knowledge base - Run regular tests against indirect prompt injection, mismatched MIME content, header-parsing differences, and authentication gaps between channels The researchers were also blunt about a common assumption many companies rely on: having a human sign off on an AI agent’s actions is not a real safeguard if that human reviewer and the AI system are looking at different versions of the same message, or if the agent has been granted more authority than a support tool should ever need.