Autheo THEO Exploit: How a Single Trusted Relayer Key Drained $1.76M on Base | PandaSecurity
Web3 Security

Autheo THEO Exploit: How a Single Trusted Relayer Key Drained $1.76M on Base

PandaSecurity Team •
#Hyperlane#Cross-Chain Bridge#DeFi Exploit#TrustedRelayerIsm#Base
Illustration of a cross-chain bridge exploit involving unbacked token minting on Base

On October 12, 2026, Autheo’s THEO token suffered a sharp 92% drawdown after an attacker minted 19 million tokens on Base without any corresponding lock or burn on the origin chain. The tokens were then sold into thin liquidity, yielding roughly 700 ETH (about $1.76 million at the time). The funds were subsequently bridged to Ethereum.

The incident was not a classic smart-contract bug or a compromised admin key on the token itself. Instead, it stemmed from a deliberate but high-risk security configuration on Autheo’s Hyperlane Warp Route: the use of TrustedRelayerIsm.

What Actually Happened

THEO on Base is implemented as a Hyperlane HypERC20 Warp Route. In a normal flow, tokens are locked or burned on the origin chain (Autheo mainnet, domain 2127), and an equivalent amount is minted on the destination chain after the interchain message is verified.

In this case, the attacker submitted a Hyperlane message that triggered a mint of 19 million THEO directly to their address (0x3048b4Ee...). The transaction (0x4fdbbc5e...) shows the tokens coming from the zero address, which is the standard pattern for a fresh mint. No matching lock was observed on the origin chain.

Shortly afterward, the same address used a series of orchestrated swaps—routing through THEO/USDC pools, Uniswap v4, and Hydrex—to convert the newly minted tokens into WETH, USDC, and cbBTC. One of the larger extraction transactions alone returned approximately 189 ETH to the attacker.

Why TrustedRelayerIsm Enabled This

Hyperlane’s Interchain Security Modules (ISMs) are meant to be modular. Applications can choose different verification models depending on their risk tolerance. TrustedRelayerIsm is one of the simplest options. Its verify function only checks whether the address that called process on the Mailbox matches a single pre-configured trustedRelayer.

Key code from Hyperlane’s repository:

contract TrustedRelayerIsm is IInterchainSecurityModule {
    address public immutable trustedRelayer;

    function verify(bytes calldata, bytes calldata message) external view returns (bool) {
        // The only check: was this message processed by the trusted relayer?
        return mailbox.processor(message.id()) == trustedRelayer;
    }
}

There is no check that the message corresponds to an actual state change on the origin chain, no multisig quorum, and no economic security. If the private key controlling that one relayer address is available to an attacker, they can deliver arbitrary messages. In the case of a HypERC20, an arbitrary message can mean an arbitrary mint.

This is not a hidden vulnerability in Hyperlane’s codebase. The TrustedRelayerIsm contract is intentionally minimal. The risk comes from using it to secure a token that has real market value and thin exit liquidity. Once the relayer key was under the attacker’s control, the rest of the attack followed the normal Warp Route code path.

Broader Lessons

Single-point-of-trust models remain common in early-stage cross-chain deployments because they are easy to operate. They also concentrate failure. When the trusted party is compromised—whether through key leakage, infrastructure access, or operational error—the blast radius is the full value of the bridged asset.

A few practical takeaways stand out from this incident:

At PandaSecurity we see similar patterns repeatedly: the most expensive cross-chain incidents are rarely novel zero-days. They are usually the result of a security model that was understood in theory but accepted in practice because it was convenient. TrustedRelayerIsm is a useful tool for testing and low-value routes. It is a poor default for assets that users can trade.

Looking Ahead

Autheo has stated that it is investigating the incident and has advised users to avoid trading or bridging THEO until further notice. The exact path by which the relayer key was controlled has not been publicly detailed. Regardless of whether the root cause was an external compromise or an internal operational failure, the outcome was the same: an unbacked mint that the destination chain accepted as valid.

For other teams running Hyperlane Warp Routes, this episode is a reminder to re-evaluate which ISMs are attached to value-bearing contracts. The cost of switching to a stronger model is usually lower than the cost of explaining an unbacked mint to users and liquidity providers.

PandaSecurity monitors cross-chain infrastructure and token bridges for misconfigurations and emerging risks. If your team is reviewing Hyperlane deployments or Warp Route security settings, we can help assess the practical blast radius of the current ISM choices.

Related articles

← Back to Blog