Stolen Vault Admin Keys Drain $4.3M From AlexLab's BNB Bridge

A hijacked private key cost AlexLab, which bills itself as Bitcoin's finance layer, $4.3 million after attackers broke into the XLink bridge deployed on the BNB network.

CertiK Alert flagged an unusual transaction touching AlexLab on May 14th, with early signs pointing toward a compromised private key. AlexLab itself stayed quiet until the following day, when it publicly acknowledged the breach and said the misappropriated assets had already been traced to major exchanges, where they were subsequently frozen.

The team put up a reward equal to 10% of the stolen amount, set to lapse May 18th at 08:00 UTC — though it's worth asking why a full day passed before the incident was made public at all.

01How the attacker got in

Per AlexLab's own security update, the intrusion traced back to a phishing attack that handed over private keys, which the attacker then used to seize admin control of one of the vaults tied to the ALEX liquidity pool.

Once inside, the attacker pulled roughly 13.7 million STX out of the affected vault. About 3 million of those STX were immediately routed to multiple centralized exchanges in an apparent rush to cash out. The AlexLab team was able to claw back aBTC, sUSDT, xBTC, xUSD, ALEX, atALEX, and several other vault assets before they left — but a meaningful portion of the STX made it past the exchanges before freezes could be applied.

Separate analysis from ImmuneBytes traced four malicious upgrades to the proxy contract behind AlexLab, all originating from a deployer address. Those upgrades redirected the bridge's endpoint contract to unverified bytecode — the mechanism that let the theft proceed.

Attacker address: 0x27055aE433E9DCb30f6EbCC1A374Cf5CC03C484E

Within roughly an hour of the contract upgrade, two withdrawal transactions executed the theft:

Transaction 1: 0x94746d33792aeb27d2066b6d8f3c8a8c7410fe15c9500059f35e0b21c9bfb416

Transaction 2: 0x47e123af93add709bc2516f6a5db057dfbb1d66a75b693cd7980cd3eb28c7357

In total, $4.3 million in assets ended up at two destination addresses:

Destination 1: 0xA747aF2a527E72cE303353b458a1c51eBCd53188

Destination 2: 0x27055aE433E9DCb30f6EbCC1A374Cf5CC03C484E

02Recovery efforts and aftermath

A portion of the stolen funds has already been located and is reportedly in the process of being clawed back from one exchange, and AlexLab says it continues to coordinate with additional centralized exchanges toward the same end, having shared forensic tracing data with them.

Given no guarantee that every dollar will be recovered, AlexLab said it is weighing whether to tap ALEX reserves held by the AlexLab Foundation to seed a treasury grant program for the affected community. A second, more unusual option under discussion: asking the Stacks community to burn the unrecovered STX still sitting in the attacker's wallets and mint replacement tokens for the users who lost funds.

AlexLab has also said it is preparing a full post-mortem for release.

Notably, ImmuneBytes and Chain Aegis both flagged that the same attacker appears connected to an earlier Mars DeFi 412 incident — a price manipulation attack that netted roughly $100,000 on April 16th.

For context, AlexLab's own security audit page states its Bitcoin Bridge — contracts and backend alike — has been audited by CoinFabrik, and the smart contracts sit under an active Immunefi bug bounty. None of that mattered once an admin private key fell into the wrong hands.

The open question is still how the exploiter obtained those vault keys in the first place — phishing, insider access, or something else entirely remains unresolved. AlexLab has recovered some assets and frozen part of the trail, but millions remain in attacker-controlled wallets, and its proposed remedies — grants and token reissuance — don't erase the underlying lapse in key-management hygiene that made the breach possible. The day's delay before disclosure only adds to the unease. Whether this turns out to be external phishing or something closer to home, the incident is a reminder that a single point of failure in key custody can undo every audit and bounty program layered on top of it — especially when the same attacker may already be moving on to the next target.