On May 6, 2026, the security organization Blockaid disclosed that the AMM infrastructure project Ekubo Protocol had suffered an attack on its custom extension contracts on EVM chains such as Ethereum, with several media outlets subsequently citing its report claiming that about $1.4 million in assets had been stolen. Unlike the “core pool” that most people are familiar with, this incident involved the extension contracts that Ekubo had specifically deployed to adapt to the EVM environment, particularly a set of contracts responsible for Swap routing functions: the V2 extension contract and V3 extension contract on Ethereum, as well as the V3 extension contract on Arbitrum were all listed as affected. After the incident was revealed, the Ekubo team confirmed the security incident on social platforms, emphasizing that the core protocol and Starknet deployment were not affected, but also clearly reminded users to revoke authorization for the relevant extension contract addresses as soon as possible to cut off potential subsequent losses.

On the surface, this is just another case of an “attack resulting in $1.4 million being stolen,” but the details quickly reveal a more noteworthy layer: this incident did not stem from a collapse of the underlying matching logic but rather revolved around attack and defense concerning extension contract design and user authorization management. The attacker exploited the connection flaws between these extension contracts and existing token authorizations to leverage assets that users had “safely entrusted to the contract,” meaning the risk does not merely belong to a specific project but directly points to the security awareness boundaries of the habitual combination of “extension contracts + authorization” within the entire DeFi ecosystem.

From Starknet Star to EVM Being Hit

In the Starknet ecosystem, Ekubo has consistently played the role of “infrastructure”: it is not a single trading frontend, but a complete set of underlying components built around AMM, providing liquidity interaction capabilities for projects on Starknet while accumulating a solid reputation among developers and early users. Also, because its core protocol has run for a long time on Starknet, this system has, in the eyes of many participants, become almost equivalent to “the most reliable AMM building block on the new public chain,” with security more or less assumed to be tied to Starknet’s main deployment.

This time, however, what was hit was not this “main backbone.” According to public information, on May 6, 2026, the attack disclosed by security organization Blockaid explicitly targeted Ekubo's custom extension contracts on EVM chains such as Ethereum: the affected range was defined as the V2 extension contract and V3 extension contract on Ethereum, as well as the V3 extension contract on Arbitrum, with the core protocol itself and its Starknet deployment confirmed to be unaffected. In other words, the “Ekubo body” as users habitually recognize it is temporarily safe, while the EVM extension edges built around functions like Swap routing have been torn open.

Some analyses regard this event as a contrasting example of “mainnet security + extension being damaged”: the same brand and technology stack did not expose direct vulnerabilities at the core protocol level on Starknet but displayed significant shortcomings in the extension contracts within the EVM environment. This sense of split not only undermined external trust in Ekubo’s extension components but also placed a more realistic problem on the table—when a protocol begins to expand into multiple chains and versions, how deep is the security chasm between the core protocol and surrounding extensions, and how this chasm could be exploited again in the next attack is no longer a theoretical concern.

$1.4 Million Opened by IPayer Callback Gap

In Ekubo’s EVM extensions, `IPayer.pay` originally played the role of “payment collection and disbursement”: when users initiate a Swap in the routing contract, the actual deduction operation is delegated to this callback function. In theory, this step should be very “particular”—clearly stating who the payer is, who the payment is for, how much is to be paid, and checking these key parameters in the code one by one to ensure that the account being deducted from is indeed the one initiating the transaction or at least the pre-bound “transaction entity.” The problem lies here: the exposed extension contract did almost none of these security checks in the `IPayer.pay` callback; when the contract received a set of “payer parameters,” it chose to trust the source directly without asking, “Are you really the person?” This is akin to an automatic deduction system where, as long as someone provides your account number, the system will attempt to withdraw money from your account without verifying the relationship between the requester and the account holder.

The attacker took advantage of this gap to turn the risk from a “theoretical vulnerability” into a real financial loss. The precondition is that the victims had previously authorized the spending rights of certain tokens to Ekubo's V2 extension contract. This is very common in everyday use—users, in order to successfully complete transactions, grant a router or extension contract a large `approve` limit, allowing it to withdraw funds via `token.transferFrom`. Normally, this process would be protected by contract logic, only using the limit when users actively conduct transactions. However, in this incident, the attacker called the flawed extension contract interface themselves, disguising the “payer” parameter as the victim's address, while the contract in the `IPayer.pay` callback did neither verify the caller's identity nor validate whether this payment corresponded to a real order, directly executing `token.transferFrom` with the authorized limit at hand, transferring tokens from the victim's account. Users who had not granted relevant permissions to the V2 extension contract could not invoke `transferFrom` at all and thus would not become direct victims; meanwhile, a batch of addresses that had already granted authorization were “swept” in a short period, with public information indicating that this attack resulted in a cumulative loss of approximately $1.4 million in assets. In terms of attack paths, this resembles a precision strike around “extension callback + authorization management” design flaws rather than a rejection of Ekubo’s core AMM algorithm itself.

Authorization Blind Spot: Extension Contracts as a Weakness

In most DeFi scenarios, “Approve first, then interact” has become a mechanical action. Users are accustomed to granting a single contract extensive token usage rights without checking which address they are actually authorizing, nor do they differentiate between “core protocol contracts” and “extensions, routers, plugins.” In this incident involving Ekubo, the risk was accurately pinned to this gap: only users who authorized the Ekubo V2 extension contract as a token spender were directly exposed to the risk of the attacker calling `transferFrom`; those ordinary users who had never granted spending rights to this extension contract were generally considered by security organizations and the media not to be within the direct impact of this round of attacks.

After the incident was disclosed, Ekubo officials clearly advised users on social platforms to revoke authorization for the affected extension contract addresses to mitigate possible future risks; security organizations and several media repeatedly emphasized a detail—what is considered the “spender” here is not some “main contract” as users might imagine but a group of custom extension contracts in the EVM environment. In other words, the issue is not the single Swap itself but rather “to whom I have granted the right to spend my tokens.” This point, when amplified across the broader DeFi ecosystem, strikes at an old problem: routing contracts, aggregators, and various extension modules are often packaged behind smooth frontend interactions, but at the authorization level, each of them is an independent potential risk point. When users habitually grant these components long-term large authorizations, as long as any link among them has design flaws like the Ekubo extension contract, the entire authorization chain can transform into a weakness that attackers can directly exploit to access user assets.

Who Should Pay for Extension Security: Protocols and Audits

When routing, aggregating, and callbacks as “extensions” are broken down into independent contracts, an unavoidable question arises: whose responsibility is the security of these extensions. For users, as long as it is a contract that falls under the Ekubo name requiring them to authorize token spending, it is naturally viewed as part of the same infrastructure. This incident is locked into custom extension contracts associated with Swap routing in the EVM environment, with the vulnerability directly arising from the lack of critical parameter validation in the IPayer.pay callback, allowing the attacker to leverage existing authorization to move assets. Even though Ekubo previously emphasized that the core logic of the basic AMM and other deployments were unaffected, whether these extensions underwent complete threat modeling, code reviews, and targeted audits for callback scenarios during the design phase remains an unmissable focal point of responsibility for this incident.

In terms of post-incident processes, this attack also reflects the typical path of current DeFi security collaboration: on May 6, 2026, security organization Blockaid was the first to monitor and disclose the attack on Ekubo’s extension contracts on EVM chains, identifying the lack of validation in callbacks as the key defect; after the incident was exposed, the Ekubo team publicly acknowledged the incident on social platforms, reminding users to revoke authorization for the affected extension contract addresses promptly and stating that they were investigating the scope and planning to release a post-incident analysis report. This “third-party real-time monitoring + protocol party rapid communication and mitigation + post-incident review” process has become the norm for how leading projects handle security incidents, but it can only serve as a last line of defense and should not replace the systematic audits of extension contracts themselves before going live.

More practically cautionary, the problem this time is not an isolated “peripheral tool” but a Swap routing extension that directly participates in path planning and receives user authorization, serving as a wake-up call for all projects building AMM infrastructure and continuously adding extension modules across multiple chains: as long as extension contracts hold token authorizations and introduce complex callbacks, they must be included in the same level of security budget and audit standards as core protocols. Otherwise, even if the core AMM logic is robust, a single point of extension oversight is enough to drag the entire protocol brand into the same crisis of trust.

After $1.4 Million: DeFi Authorization and Extension Security

With confirmed losses of about $1.4 million, yet no compensation plan announced, and the official stance only providing “a post-incident analysis will be released,” this attack surrounding EVM extension contracts and authorization feels more like a systemic stress test occurring on “peripheral modules”: while the core logic is intact, users' real money has already vanished. In Ekubo's EVM extensions, the IPayer.pay callback lacking key parameter validation allowed the attacker to commandeer existing token authorizations, withdrawing assets directly from user accounts via token.transferFrom, targeting two weak links—extension contract design and authorization management. For the protocol parties, the lessons are clear: first, audit standards cannot solely focus on the main contract; all extensions, routers, and callback interfaces holding token control must be included in the same level of threat modeling and formal audits; second, callback interfaces should tighten at the design level—who is paying, where the money is coming from, and whether payment is allowed on behalf of others must be codified in function parameters and validation logic, with defaults being “prohibited” rather than “permitted”; third, contingency plans must be pre-prepared to at least have rapid disclosure, centralized authorization revocation guidance, risk control switches, and other action paths ready, rather than hastily piecing together a response manual after an incident occurs.

For ordinary users, this incident starkly exposes a commonly overlooked fact: you think you are “trusting a specific protocol”, only to have signed contracts scattered across various chains and different versions. Once an extension is authorized as a token payer, it stands on the same level as the core contract in terms of being able to manipulate your balance. Improvements in habitual practices are far more valuable than post-incident panic: regularly check and clean up old authorizations in wallets, clearly distinguish between the protocol’s main contract, routing contracts, and various extension contracts, and avoid granting “unlimited” authorizations to unfamiliar addresses. When trying new features or multi-chain expansions, prioritize smaller limits and shorter durations for authorizations. This attack surrounding EVM extensions and authorizations currently lacks broader on-chain quantitative secondary effects, but on a cognitive level, it has already presented a conclusion for everyone: the next stage of DeFi will not only compete on innovation speed but also on who can set stricter bottom lines for authorization and extension security.

Join our community to discuss and grow stronger together!
Official Telegram community: https://t.me/aicoincn
AiCoin Chinese Twitter: https://x.com/AiCoinzh
AiCoin on-chain: https://aicoin.com/hyperliquid
AiCoin exclusive Hyperliquid benefits: https://app.hyperliquid.xyz/join/AICOIN88
AiCoin exclusive Aster benefits: https://www.asterdex.com/zh-CN/referral/9C50e2

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。