Decentralized exchange aggregator Dexible Finance suffered a significant security breach on February 17, 2023, when an attacker exploited a critical vulnerability in the platform’s v2 smart contracts, siphoning approximately $2 million worth of tokens from user accounts. The incident underscores the persistent risks lurking in DeFi protocols, even those that have undergone prior security audits, and raises urgent questions about the adequacy of access control mechanisms in decentralized trading platforms.
The Exploit Mechanics
The attack targeted the selfSwap function within Dexible’s v2 smart contracts. This function is designed to enable users to perform token swaps without the involvement of an affiliate or automatic discounts. The vulnerability lay in the absence of proper validation for the router address (routerID) provided in the swap request object. Because the contract did not verify the router on-chain, the attacker was able to pass their own malicious contract address as the router, effectively hijacking the swap execution path.
Once the attacker supplied their custom router, the fill function performed a delegate call using the attacker’s provided routerData. This allowed the malicious contract to execute a transferFrom operation, moving approved tokens directly from victim accounts to the attacker’s wallet. The exploit required minimal capital — only enough gas to execute the transactions — making it an exceptionally efficient attack vector.
Affected Systems
The breach impacted a total of 17 user accounts across multiple chains. On the Ethereum mainnet, four users lost a combined 930.6 ETH, valued at approximately $1.5 million at the time. According to on-chain analysis, all of the Ethereum losses originated from a single address belonging to BlockTower Capital, a prominent cryptocurrency investment firm. An additional $450,000 in tokens was drained from accounts on Arbitrum and Binance Smart Chain.
With Bitcoin trading around $24,565 and Ethereum near $1,694 on the day of the attack, the broader crypto market was in a recovery phase, making the losses particularly painful for affected users who had positioned themselves for potential upside.
The Mitigation Strategy
Upon detecting the exploit, Dexible took immediate action by pausing all affected smart contracts and publicly urging users to revoke token authorizations granted to the platform. The team posted instructions across social media channels, advising anyone who had previously approved Dexible to manage their tokens to immediately revoke those permissions using tools like Revoke.cash or Etherscan’s token approval checker.
The attacker laundered the stolen funds through Tornado Cash, the privacy-focused mixer protocol, before transferring them to unknown wallets on the BNB Chain. This obfuscation made recovery virtually impossible, highlighting the challenges DeFi platforms face in tracing and recovering stolen assets.
Lessons Learned
The Dexible hack offers several critical takeaways for the DeFi ecosystem. First, the vulnerability was an access control issue — one of the most common yet preventable exploit categories. The selfSwap function should have validated the router address against a whitelist of approved DEX routers before executing any delegate call. This single check would have neutralized the attack entirely.
Second, the incident highlights the danger of unlimited token approvals. Users who had granted Dexible broad permission to manage their tokens suffered maximum losses. Limited approvals, where users authorize only the exact amount needed for each transaction, would have constrained the damage significantly.
Third, despite Dexible having been audited by Solidified in August 2021, the vulnerability was introduced in the v2 contracts after the audit. This pattern — post-audit code changes introducing new vulnerabilities — is a recurring theme in DeFi exploits and underscores the need for continuous security review processes.
User Action Required
If you have ever interacted with Dexible or any DeFi platform and granted token approvals, take immediate steps to review and revoke unnecessary permissions. Use dedicated tools like Revoke.cash, Etherscan’s Token Approvals, or similar services on the chains you use. Consider adopting hardware wallets for storing significant holdings and limiting smart contract approvals to the minimum amounts required for each transaction. The DeFi landscape rewards vigilance — complacency can be costly.
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.
no router validation at all? in a v2 contract that supposedly had audits? the selfSwap function is literally just trusting whatever address you pass it
The fill function executing with a user-set router is a fundamental design flaw, not a bug. This architecture was broken from the start.
the architecture was not broken, it was never built properly. skipping router validation in a swap function is day-one stuff
selfSwap without router validation is a textbook access control failure. Certik and Quantstamp both missed it apparently
Yara Osei Certik and Quantstamp both missed it because audits check for known attack patterns not missing business logic. router validation should be day one stuff
trashpanda42 no router validation in a swap function is not even a subtle bug. this is like a bank vault with no lock on the door
2 mil gone because of a missing require statement. devs need to stop shipping first and auditing second
audits are theater if the auditor does not check every external-facing function for input validation. this was low hanging fruit
selfSwap without router validation is textbook access control failure. one if statement would have saved 2M
the fill function just executed whatever router address the attacker supplied. how does that pass any review
the fact that selfSwap didnt validate the router address is wild. thats like letting someone fill in their own bank routing number without checking it
Certik and Quantstamp both signing off on a contract with no router validation. tells you everything about audit quality in 2023
Ingrid its worse than just signing off. both firms issued clean reports on a v2 contract. at least with a bug you can say it was subtle. this was just not checking
two named auditors missed a missing require statement on a router address. the audit industry needs its own audit at this point
Sofie Brandt two named auditors and neither checked if the router address was validated. audits are snapshots not guarantees, but missing basic access control is embarrassing
require_check_ you nailed it upstream. access control on a swap router should be the first thing tested, not an afterthought. $2M tuition fee
selfSwap function with zero router validation passed two named audits. Certik and Quantstamp basically rubber stamped a contract where anyone could set their own router address
router_skep_ one if statement checking routerID against a whitelist would have saved 2M. the audit firms charged more than the exploit
Bram V. one if statement checking routerID against a whitelist would have saved 2M. the audit firms charged more than the exploit cost. sums up the audit industry perfectly
router_skep_ Certik and Quantstamp both signed off on a contract where the selfSwap function had zero router validation. at some point we need to admit named audits are marketing not security