Aperture Finance, a DeFi platform, lost about $3.67 million in a smart contract exploit. Blockchain security firm PeckShieldAlert said the attacker has already moved part of the stolen assets into ETH and sent roughly 1,242 ETH, valued in the source at about $2.4 million, to Tornado Cash.
V3 and V4 contracts were exploited through existing approvals
According to PeckShieldAlert, the attack took place on January 25, 2026 and involved weaknesses in Aperture Finance’s V3 and V4 smart contracts, along with token permissions users had granted earlier. In DeFi, users commonly approve contracts to manage ERC-20 tokens or liquidity position NFTs so trading and strategy functions can run automatically. In this case, the exploiter found a flaw in how those permissions and function calls were handled.
The attack did not rely on compromised wallets or stolen private keys. Instead, the exploiter used the contract’s own logic to trigger unauthorized transfers. Because many users had already approved the contracts, the attacker did not need fresh signatures to move assets tied to those token and liquidity position approvals.
Stolen funds were broken up and sent to Tornado Cash
After extracting about $3.67 million, the attacker converted a large portion into ETH and routed the funds through Tornado Cash to make tracing harder. The source says the transfers were split into multiple smaller transactions, including batches of 10 ETH and 100 ETH. That pattern is commonly seen in laundering flows after crypto thefts, as it makes on-chain tracking and recovery more difficult.
Users were told to revoke both token and NFT approvals
Following the exploit, Aperture Finance issued an emergency notice and published a list of affected contract addresses. Users were urged to immediately revoke approvals connected to those risky addresses, covering both ERC-20 token approvals and ERC-721 liquidity position approvals. If those approvals remain active after a contract has been compromised, user assets can stay exposed.
The incident details also make clear that private keys were not stolen in the breach. The risk came from abused smart contract permissions, leaving approved funds vulnerable even though users’ wallets themselves were not directly hacked.