A Fake Token Named After a Cartoon Toy Drained $16M From AlexLab's Vaults

Just over a year after a compromised private key cost it $4.3 million, AlexLab — Bitcoin's self-described finance layer — was hit again, this time for more than $16 million.

The second incident had nothing to do with stolen keys. On June 6th, an attacker exploited a flaw in the verification logic behind AlexLab's permissionless token-listing feature, turning that feature into a route for draining liquidity across several asset pools in a single transaction. AlexLab initially attributed the loss to Stacks blockchain's "inability to detect failed transactions," but on-chain evidence points to a design flaw inside AlexLab's own vault system rather than a blockchain limitation. In one transaction, the exploiter walked off with a mix of STX, aBTC, sBTC, ALEX tokens, and stablecoins — raising the question of how a protocol exploited twice in thirteen months, through two entirely different attack vectors, can call itself production-ready infrastructure.

01Timeline of the incident

The first public sign of trouble came Friday morning, June 6th, when Twitter user Reubs BTC posted a warning: "Hold on tight friends. Looks like ALEXLabBTC has been hacked." Minutes later, an account called Crusader tallied the damage: "62 $BTC, 8M $STX, 119m $Alex, $1.7M USDT. Not again."

AlexLab's own response followed shortly after, acknowledging only that "we are aware of the malicious activities at ALEX." The team suspended platform activity almost immediately and said a full post-mortem would come "as soon as possible."

Roughly two hours later, AlexLab confirmed the exploit outright, describing it this way: "The attacker exploited a flaw in verification logic in the self-listing function by referencing a failed transaction, allowing a malicious token to bypass checks and transfer funds from liquidity pools." In the same statement, the team pinned the root cause on Stacks itself, citing "a current on-chain limitation, specifically the inability to reliably detect failed transactions on Stacks."

A few hours after that, AlexLab published an official damage estimate of $8,373,227, spread across STX, sBTC, USDC/USDT, and WBTC, and pledged full reimbursement in USDC from the foundation's treasury, along with a compensation timeline and claims process.

02What the blockchain actually shows

The transaction record tells a considerably larger story than AlexLab's own figure.

Vault drained: SP102V8P0F7JX67ARQ77WEA3D3CFB5XW39REDT0AM.amm-vault-v2-01

Attacker's address: SP2VCNXGRZCBTP8E9MQ6DJPFVXRBPWBN63FE06A1M

Theft transaction: 0xe8b2ac705dcbb35d487a4efd7a0fe384bbad1d1d97ea970410ad82a3cd0d9daf

Assets that actually left the vault:

• 8,403,867 STX (≈$5.54M)
• 50.74 aBTC (≈$5.43M)
• 12.76 sBTC (≈$1.35M)
• 119,419,656 ALEX tokens (≈$2.12M)
• 1,748,327 sUSDT (≈$1.74M)

That totals more than $16.18 million — nearly double the $8.37 million figure AlexLab reported publicly.

03The mechanics of the exploit

The attack unfolded in four steps and had nothing to do with Stacks failing to detect a failed transaction — it was a deliberate abuse of AlexLab's own vault permission system. Security researcher Nolan of Exvul later published a breakdown confirming this reading of the attack.

First, the attacker deployed a malicious token labeled "ssl-labubu-672d3" — named, seemingly, after the popular collectible toy character — containing a forged transfer function built specifically to siphon assets from the vault. Second, they created a legitimate Labubu/STX trading pool, which automatically invoked AlexLab's set-approved-token function and, in doing so, granted the malicious token vault-level permissions. Third, the attacker flipped AlexLab's set-enable-farming flag to a value of 9, which activated the fake token's transfer capability. Fourth, a single swap-x-for-y call triggered the actual theft: when the vault contract invoked the malicious token's transfer function using as-contract, the transaction context shifted so that the vault itself — not the attacker — appeared to be the sender.

With those vault-level permissions in hand, the forged transfer function systematically moved out STX, aBTC, sBTC, ALEX, and sUSDT, sending everything directly to the attacker's address in one transaction. The entire vault was emptied in a single call.

04Where the audits fell short

AlexLab had, in fact, just gone through two security reviews — one from Clarity Alliance and one from CoinFabrik, both completed in May 2025. The catch: both audits covered AlexLab's forthcoming DAMM (Discrete Automated Market Maker) system, slated for a July release — not the live vault infrastructure that actually got drained. The auditors reviewed exactly what they were asked to review; the code that was exploited simply wasn't in scope.

05Two hacks, one pattern

Thirteen months separate AlexLab's two exploits, and the methods couldn't be more different: the first was a compromised private key that let an attacker seize vault admin rights and move roughly $4.3 million; the second was a code-level flaw, executed through a fabricated token, that moved close to four times as much. In both cases, AlexLab's public messaging leaned toward attributing blame elsewhere — first framing the initial breach around opsec failure, and this time pointing at supposed Stacks blockchain limitations — while the underlying transaction data showed a materially larger loss than what was first disclosed. The gap between the $8.37 million AlexLab pledged to reimburse and the $16.18 million actually taken leaves affected users short, and the fact that a fresh pair of audits covered an unreleased product rather than the system that was actually attacked underscores a mismatch between where AlexLab directed its security spending and where its real exposure was.