Skip to main content
• 5 min read

Ekubo Protocol Custom Extension Exploit
Drains $1.4M via Payment Callback Authorization Gap

Ekubo Protocol was hit by an Ethereum exploit against a specific v2 custom extension contract, with public alerts reporting about $1.4 million drained. The issue centered on insufficient payment callback authorization: users who had approved the affected v2 contract as an ERC-20 spender were at immediate risk, while general Ekubo users were not reported to be broadly exposed.

AUTOSEC.DEVAUTOSEC.DEV
Ekubo Protocol Custom Extension Exploit Drains $1.4M via Payment Callback Authorization Gap
  • Incident Date: May 6, 2026
  • Target: Ekubo Protocol v2 custom extension contract on Ethereum
  • Target Overview: Ekubo is a DeFi trading and liquidity protocol. The publicly reported incident did not describe a broad compromise of all Ekubo users; the immediate risk was tied to a specific v2 contract that some users had approved as an ERC-20 spender.
  • Total Loss: ~$1.4 million
  • Attack Vector: Payment Callback Authorization Gap / ERC-20 Allowance Drain / transferFrom Abuse

Incident Review & Technical Details​

1. Attack Path​

  1. Exploit Detected in Progress: Blockaid reported an ongoing exploit against an @EkuboProtocol custom extension contract on Ethereum, with approximately $1.4 million drained at the time of the alert.
  2. Risk Concentrated in a Specific v2 Spender: Blockaid stated that general Ekubo users were not at risk. The immediate exposure was limited to users who had approved the specific v2 contract as a spender for any token.
  3. Payment Callback Authorization Gap: Phemex's report attributed the issue to the extension contract failing to properly verify whether the payer in a payment callback was the lock initiator or an otherwise authorized payer.
  4. Allowance-Based Drain Primitive: Once the callback path accepted an attacker-influenced payer, the vulnerable flow could use transferFrom against users who had already granted allowances to the affected contract.
  5. Token-Agnostic Exposure: Because the core primitive relied on ERC-20 allowances, the risk was not limited to one token type. Any token approved to the affected spender could become reachable if the vulnerable callback path was triggered.
  6. Funds Obfuscation: TenArmor reported an attack transaction on Ethereum and stated that the attacker deposited funds into Tornado Cash after the drain.

2. Impact Scope​

  • Direct Losses: Public alerts and reporting put the loss at approximately $1.4 million.
  • Affected Network: Ethereum mainnet.
  • Affected Component: A specific Ekubo v2 custom extension contract, according to public monitoring reports.
  • At-Risk Users: Users who had granted ERC-20 allowances to the affected v2 contract as a spender. Blockaid emphasized that this could apply to any token approved to that contract.
  • Unaffected or Unconfirmed Scope: Public reporting did not establish that all Ekubo users or the broader Ekubo protocol were at immediate risk. The known exposure was approval-based and tied to the identified v2 spender.
  • Attack Transaction: TenArmor identified 0x770bc9a1f7c32cb63a5002b9ceb5c7994cd3af0fc6b2309cb32d3c46f629daa0 as the attack transaction.

3. Root Cause​

The incident fits a common but high-impact callback authorization failure:

  • Callback Trusted Too Much Caller-Controlled Context: A payment callback path appears to have accepted a payer value without proving that the payer initiated the relevant lock or explicitly authorized the payment.
  • Allowance Authority Became the Real Asset Boundary: ERC-20 approvals gave the affected contract permission to move user tokens. Once the contract could be induced to call transferFrom with an attacker-selected payer, those approvals became drainable value.
  • Extension-Level Bug, Protocol-Level Blast Radius: Custom extension contracts can hold powerful settlement privileges even when they are not the core AMM. A single missing invariant in an extension can still expose users who approved it.
  • Approval Reuse Amplified Loss: Users often leave unlimited or long-lived ERC-20 allowances in place. That operational habit increases the blast radius of any spender-contract bug.

The key invariant should have been simple and strict: a payment callback must only pull funds from the lock initiator or from a payer that has been explicitly authorized for that exact payment context.

4. Mitigation and Response​

Immediate actions for affected or potentially affected users:

  • Revoke approvals to the specific Ekubo v2 custom extension contract identified by official Ekubo, Blockaid, or other trusted monitoring channels.
  • Review all ERC-20 approvals associated with recent Ekubo v2 interactions, not only the token involved in the visible drain.
  • Avoid interacting with third-party links or unsigned instructions claiming to assist with revocation; verify spender addresses through trusted sources.

Recommended remediation for protocols and extension developers:

  • Enforce payer == lockInitiator unless an explicit, scoped authorization record proves otherwise.
  • Bind payment callbacks to a unique lock/session identifier, expected token, expected amount, and authorized payer.
  • Treat every transferFrom in callback code as a high-risk asset movement and test unauthorized payer cases directly.
  • Use bounded, expiring approvals where possible instead of asking users for broad unlimited allowances.
  • Add monitoring for abnormal transferFrom calls where the spender is an extension contract and the payer differs from the active lock initiator.
  • Provide users with a clear spender address and revocation guidance during incident response.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

Hook-based and extension-based DeFi systems often fail at the boundary between "valid callback" and "authorized payment." AUTOSEC.DEV helps teams turn those implicit assumptions into audited, testable invariants.

  1. Smart Contract Logic Audit: We review callback flows, lock/session state machines, payer validation, settlement code, and ERC-20 transfer paths for authorization bypasses.
  2. Extension & Hook Security Review: We test custom extension contracts for unsafe assumptions around caller identity, callback origin, token approvals, and delegated execution.
  3. Allowance Risk Assessment: We map spender permissions, unlimited approvals, treasury/operator exposure, and user-facing revocation requirements.
  4. Incident Response (IR): AUTOSEC.DEV provides rapid exploit triage, transaction tracing, user-risk scoping, revocation guidance, and post-incident hardening support.

Service Content​

Reference​

https://x.com/blockaid_/status/2051757787714118125