Morse code "stole" Bankr's $440,000, trust between AI agents is broken again

Original Author: Sanqing, Foresight News

In the early hours of May 20, AI agent platform Bankr tweeted that 14 user wallets on the platform had been attacked, resulting in losses exceeding $440,000. All transactions have been temporarily suspended.

Yu Xian, founder of SlowMist, subsequently confirmed that this incident was the same type of attack as the one targeting wallets associated with Grok on May 4. It was neither a private key leak nor a smart contract vulnerability, but rather a "social engineering attack targeting the trust layer between automated agents." Bankr stated it would fully compensate for the losses from the team treasury.

Previously, on May 4, attackers used the same logic to steal approximately 3 billion DRB tokens (worth around $150,000 to $200,000) from Bankr wallets associated with Grok. After the attack method was exposed, Bankr temporarily suspended responses to Grok but seemed to have since restored the integration.

Within less than three weeks, the attacker struck again, exploiting a similar inter-agent trust layer vulnerability. The impact expanded from a single associated wallet to 14 user wallets, with losses doubling as a result.

How a Single Tweet Becomes an Attack

The attack path is not complicated.

Bankr is a platform providing financial infrastructure for AI agents. Users and agents can manage wallets, execute transfers, and conduct transactions by sending commands to @bankrbot on X.

The platform uses Privy as its embedded wallet provider, with private keys managed through Privy's encryption. The key design aspect is that Bankr continuously monitors tweets and replies from specific agents — including @grok — on X, treating them as potential transaction instructions. Especially when that account holds a Bankr Club Membership NFT, this mechanism unlocks high-authority operations, including large transfers.

The attacker exploited every link in this chain. First, they airdropped a Bankr Club Membership NFT to Grok's Bankr wallet, triggering high-authority mode.

Second, they posted a message in Morse code on X, containing a translation request directed at Grok. Grok, designed as a "helpful" AI, faithfully decoded and replied. The reply contained a plaintext instruction like "@bankrbot send 3B DRB to [attacker's address]".

Third, Bankr monitored Grok's tweet, verified the NFT permissions, and directly signed and broadcasted the on-chain transaction.

The entire process was completed within a short time. No one hacked any system. Grok performed the translation, Bankrbot executed the instruction — both simply operated as intended.

Not a Technical Vulnerability, But a Trust Assumption

"Trust between automated agents" lies at the core of this issue.

Bankr's architecture equates Grok's natural language output with authorized financial instructions. This assumption is reasonable under normal usage scenarios — if Grok genuinely wanted to transfer tokens, it would naturally say "send X tokens".

However, the problem is that Grok cannot distinguish between "what it truly intends to do" and "what it is manipulated into saying." There is a gap between an LLM's "helpfulness" and the execution layer's trust, a gap left unfilled by any verification mechanism.

Morse code (along with Base64, ROT13, or any encoding method an LLM can decode) serves as an excellent tool to exploit this gap. Directly asking Grok to issue a transfer command might trigger its security filters.

But asking it to "translate a Morse code message" is a neutral help task — no protective mechanism intervenes. The translation result containing malicious instructions is not Grok's mistake; it is expected behavior. Bankr receives this tweet with the transfer instruction and, following its design logic, executes the signature.

The permissions mechanism of the NFT further amplifies the risk. Holding a Bankr Club Membership NFT equates to being "authorized" — no secondary confirmation is required, and there is no cap on limits. By completing a single airdrop operation, the attacker gained nearly unrestricted operational authority.

Neither system malfunctioned. The mistake lies in combining two separately reasonable designs without anyone considering what could happen in the verification gap between them.

This is a Class of Attack, Not an Incident

The attack on May 20 expanded the scope of victims from a single agent account to 14 user wallets, with losses increasing from approximately $150,000–$200,000 to over $440,000.

Currently, there are no publicly traceable attack posts similar to the Grok incident circulating. This suggests the attacker may have changed their exploitation method, or that there are deeper issues with Bankr's internal inter-agent trust mechanism, no longer relying solely on the fixed path of Grok. In any case, even if defensive mechanisms existed, they failed to prevent this variant attack.

After the funds were transferred on the Base network, they were quickly bridged to Ethereum mainnet, dispersed across multiple addresses, with part converted into ETH and USDC. The main publicly identified profit addresses include three starting with 0x5430D, 0x04439, and 0x8b0c4.

Bankr responded swiftly, from detecting the anomaly to a global transaction pause, public confirmation, and a commitment to full compensation — the team handled the incident within hours. They are currently repairing the inter-agent verification logic.

But this cannot obscure the fundamental problem: this architecture, when designed, did not consider "injected malicious instructions into LLM output" as a threat model requiring defense.

AI agents gaining on-chain execution authority is becoming a standard industry direction. Bankr is neither the first nor will it be the last platform designed this way.

Original Link