A third-party integration built on top of Aave drained 114 ETH from Safe wallets, according to an incident report circulated this week by CryptoRank.

The figure, disclosed in CryptoRank's headline, represents the cumulative losses attributed to a single exploit vector targeting users of the Safe multisig infrastructure through an external Aave adapter. The 114 ETH, worth roughly several hundred thousand dollars at recent market levels, moved out of Safe accounts that had interacted with the third-party adapter rather than directly with Aave's core lending markets.

What was an exploit?

The incident targeted a third-party Aave adapter — a contract wrapper that lets developers route deposits, borrows or migrations through Aave's liquidity pools without building the integration from scratch. Adapters of this kind have proliferated across the Aave ecosystem, where the protocol's open architecture invites external teams to build user interfaces, automation layers and migration tools on top of its lending markets.

CryptoRank's headline frames the event strictly as an exploit of a "third-party" component, distinguishing it from any compromise of Aave's audited core contracts. The outlet's summary did not specify which adapter was affected, the deployment chain, the attack vector or whether the funds have been traced on-chain.

How does the loss split between Aave and Safe?

Aave, one of the largest decentralized lending markets by total value locked, runs a set of permissionless pool contracts that have been the subject of multiple independent audits and bug bounties. Safe provides multisignature wallet infrastructure used to secure treasuries, protocol operations and individual user funds across Ethereum and other networks. Neither Aave's lending pools nor Safe's core smart contracts appear to have been directly compromised in the incident as described.

The breach sits in the layer between them — the adapter that translates user intent into the underlying Aave positions. That distinction matters operationally: it limits the blast radius to users who approved the specific adapter contract, and it places responsibility for the exploit with the team that deployed and maintained that wrapper rather than with the protocol maintainers themselves.

Who is exposed?

CryptoRank did not enumerate affected addresses or quantify the number of Safe wallets drained. Without on-chain confirmation, the 114 ETH figure functions as the floor of the incident rather than a comprehensive tally. Investigators and the adapter's maintainers will need to publish transaction hashes and a post-mortem before user-level exposure can be reconstructed.

What are the operational consequences?

For Aave, the incident reinforces a familiar governance posture: third-party integrations remain outside the protocol's direct security perimeter. Aave's documentation and prior forum posts have placed responsibility for adapter risk on the deploying team and on interface providers such as aggregators and portfolio dashboards.

For Safe, the episode adds to a string of front-end and integration-layer incidents that have moved user balances over the past two years without compromising the Safe contract itself. The pattern has become familiar: attackers target the wrappers, signers or operational scripts that sit between a multisig and a DeFi protocol rather than the underlying vault.

CryptoRank's report leaves several questions open, including the identity of the adapter, the attack mechanism and whether any recovery or negotiation channel is in play. Until the maintainer publishes a post-mortem with on-chain evidence, the 114 ETH figure stands as the only quantified element of the incident — and the only verified boundary of the damage.