The Bitcoin-focused decentralized finance platform ALEX Protocol suffered a devastating security breach on June 6, 2025, when an attacker exploited a critical vulnerability in its self-listing verification logic, draining approximately \$8.3 million in digital assets from the protocol built on the Stacks blockchain. The incident, which highlighted persistent weaknesses in DeFi permission management, sent shockwaves through the Stacks ecosystem as Bitcoin traded near \$105,793 and Ethereum held at \$2,510.
The Exploit Mechanics
The attacker deployed a carefully crafted malicious token named ssl-labubu-672d3 on the Stacks mainnet. This token contained a deceptive transfer function hidden within its smart contract code. The attacker then created a liquidity pool on ALEX Protocol pairing this malicious token with legitimate Stacks (STX) tokens, setting the trap for the protocol’s automated systems.
The core vulnerability lay in ALEX Protocol’s insufficient verification controls for self-listed tokens. When the attacker invoked the set-approved-token function, the protocol unintentionally granted the malicious contract vault-level access — a catastrophic permission escalation that should never have been possible through a self-listing mechanism. With these elevated permissions, the attacker activated the set-enable-farming function, which enabled the malicious transfer capability embedded in the token contract.
During routine swap-x-for-y operations, ALEX Protocol’s legitimate contracts inadvertently triggered the malicious transfer function. Weak internal validation checks caused the protocol to misidentify the vault itself as the initiator of the transfers, allowing the attacker to systematically drain tokens from the protocol’s reserves.
Affected Systems
The breach impacted multiple asset pools within the ALEX Protocol ecosystem. Stacks (STX) tokens bore the brunt of the attack, with approximately 8.4 million STX tokens stolen, equivalent to roughly \$5.69 million at the time of the exploit. The attacker also made off with 21.85 Stacks Bitcoin (sBTC) tokens valued at approximately \$2.24 million, along with stablecoins USDC and USDT totaling around \$149,850 and 2.8 Wrapped Bitcoin tokens worth approximately \$287,000. Some reports from blockchain analysts suggested total losses could reach as high as \$16.18 million when accounting for additional stolen aBTC, STX, sUSDT, and ALEX tokens.
The Mitigation Strategy
Following the discovery of the breach, ALEX Lab Foundation moved swiftly to contain the damage. The team halted all platform operations to prevent further exploitation and began coordinating with centralized exchanges to trace and potentially freeze stolen funds that had been moved to trading platforms. The foundation pledged full reimbursement to all affected users using USDC from its treasury reserves.
Reimbursement calculations were based on average on-chain exchange rates recorded between 10:00 AM and 2:00 PM UTC on the day of the exploit, ensuring fair valuation for affected users. By June 8, 2025, all affected wallets had received private on-chain claim notifications, with users required to submit completed claim forms by June 10. Reimbursements were scheduled to be distributed within seven business days after verification.
Lessons Learned
This incident exposed a fundamental flaw in how DeFi protocols handle permission management for self-listed assets. The ability for an externally deployed token to gain vault-level access through a standard listing function represents a critical architectural failure. Protocols must implement multi-layered verification that independently validates token contract behavior before granting any elevated permissions. The attack also underscores the importance of real-time monitoring systems that can detect anomalous token behavior patterns before significant funds are drained.
User Action Required
Users who interacted with ALEX Protocol between June 5 and June 7, 2025, should verify their wallet balances and check for on-chain claim notifications. Any user who received a claim notification must submit their completed claim form before the deadline. Additionally, DeFi participants across all platforms should remain vigilant about interacting with newly listed tokens and avoid providing token approvals to unverified contracts. As the broader crypto market continues to grow — with Bitcoin’s market cap exceeding \$2.1 trillion — the incentive for sophisticated attacks will only increase, making personal security hygiene more critical than ever.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Always conduct your own research before engaging with any DeFi protocol.
The composability of DeFi is something TradFi can never replicate
Composability means nothing if a single malicious token can drain the vault. The Stacks ecosystem needs better security tooling before it can credibly claim Bitcoin-grade anything.
composability without access control is just an open vault. Stacks needs to decide if permissionless listing is worth repeated drain events
Permissionless lending is still the most powerful use case in crypto
DeFi insurance protocols are maturing — that’s a bullish sign
Smart contract audits have improved dramatically since 2022
ssl-labubu getting vault access through a self-listing function is embarrassing. basic token verification should be step 1 of any DeFi protocol audit
0xSentinel.eth exactly. if set-approved-token gives vault access without checks then the audit process failed before the protocol even launched
Another ‘sophisticated’ exploit that’s really just a massive logic fail in a basic feature. Stacks keeps preaching about Bitcoin-grade security, but $8.3M draining because of a self-listing bug is a huge L for the ecosystem. At this point, post-mortems are the only thing ALEX bags are actually holding.
calling it a logic fail is generous. set-approved-token granting vault access to unverified contracts is a design flaw that should have been caught in internal review
bugbounty_max calling it a design flaw is right. set-approved-token without verification is like leaving your front door open and calling it architecture. any competent audit should flag unrestricted vault access
Hard disagree on that take. Self-listing is the heart of permissionless DeFi, you can’t nuke the whole concept just because one implementation was sloppy. If we start gatekeeping listings because we’re scared of bugs, we might as well just stick to CEXs and call it a day.
nobody is saying nuke permissionless listings. but ssl-labubu getting vault access without proper verification is a textbook access control failure, not a design tradeoff
ssl-labubu is such a meme name for a token that drained 8.3M. feels like every few months a new chain finds out the hard way why token verification matters