How did Cardex get exploited of $400K?

On 19th February, an exploit targeting Abstract wallets linked to Cardex resulted in the theft of approximately $400,000 in ETH across 9,000 wallets.

The attack leveraged session key mismanagement and an exposed session signer private key on Cardex’s frontend, allowing the attacker to drain funds by impersonating users.

This was not a network-wide issue but rather a targeted exploit against users who had granted session key permissions to Cardex.

• Cardex requires users to create session keys, allowing the platform to execute transactions on their behalf without requiring approvals for each action.
• These session keys had permissions to call buyShares, sellShares, and transferShares functions.

• Instead of assigning unique session signers per user, Cardex used a single session signer wallet for all users.
• The private key of this session signer was exposed in the Cardex frontend (rookie mistake).

• Step 1: Attacker identifies an active session from a victim.
• Step 2: Uses the compromised session signer to call buyShares and purchase shares on behalf of the victim.
• Step 3: Transfers those shares to their own wallet using transferShares.
• Step 4: Dumps the shares on Cardex’s bonding curve to steal ETH.

• Attacker Contract: 0xee580828b426b6cc33817bCE419DaF65a516aA7e
• Funds Dispersed Across Wallets:
  • 0x57D81b6bFd64ACB54529d2e938c8BA43C138F7d8
  • 0xF9c5Bb27aA8AA62c98A9672B8A24Beef5C35D7FD
  • 0x14D4DEaa4aeC28A6387A1805Ff853F1F06C909f3

• The stolen funds first passed through 0x0000000000000000000000000000000000008001 (a bootloader address used for gas payments) before being redirected to the attacker’s wallets.
• The attacker didn’t use a contract with callable functions, instead, they directly executed transactions from users' wallets, making it harder to track and flag malicious activity.

• Single Session Signer for All Users: Every user on Cardex shared the same session signer, a horrible security practice.
• Private Key Exposure: The session signer’s private key was leaked in the frontend, allowing attackers to hijack active sessions.
• Poor Session Key Implementation: Instead of properly scoping session keys per user, Cardex left an open door for attackers.
• No Session Key Revocation Visibility: Users had no easy way to monitor or revoke active session keys.

• ~$400K stolen across ~9000 wallets.
• Only ETH was affected, ERC20 tokens and NFTs remained safe due to function-level restrictions.

For Users:

• Disconnect Abstract Wallets from Cardex.

• Revoke all session keys using tools like revoke.cash.

• Avoid interacting with Cardex until they confirm a fix.

• Monitor your transactions for suspicious activity.

For Developers

• Never use a shared session signer for all users. Each user should have a dedicated session signer.

• Do not expose private keys in frontend code. Use secure backend storage & encryption.

• Session keys must have strict, limited scopes. They should not allow arbitrary transactions.

• Provide users with visibility & control over session keys. Implement a dashboard for session revocation.

• Conduct full-stack security audits, not just contract audits. This was an infrastructure-level failure, not a smart contract bug.

Session keys are a powerful UX tool, but they must be implemented with security in mind.

This attack wasn’t just a one-off blunder, it exposed a systemic issue in how Web3 projects handle session keys.

With better practices, this entire exploit could have been avoided.

While Abstract and Cardex will likely implement fixes, this incident is a wake-up call for any dapp using session keys.

The next exploit might not just drain ETH, it could target ERC20s, NFTs, or even governance permissions.

Stay vigilant, revoke approvals, and never trust blindly, especially when the keys to your funds are in someone else’s hands.

Stay SAFE.