1. TL;DR – What Happened in the KiloEx Hack?

On April 14, 2025, a crypto trading platform called KiloEx was hacked, and over $7.4 million was stolen across multiple blockchains (Base, BNB Chain, opBNB, etc.). This platform allows people to trade cryptocurrency using leverage, meaning they can borrow money to potentially generate larger profits.

The attacker found a security weakness in a part of KiloEx’s system that was supposed to control who was allowed to do what. That system failed to properly check whether the person giving an order was actually allowed to do so, and so the hacker pretended to be a trusted system admin.

Using this fake identity, the hacker tricked the system into accepting fake price updates for crypto assets like ETH. They set the price low, bought in, and then raised the price way up and sold, pocketing millions. It’s like faking the price of a stock, buying it cheap, and selling it at a fake high price, all without anyone stopping you.

The weakness was in the protocol’s MinimalForwarder contract, which was supposed to safely forward users' transactions, but it didn’t check identities correctly. That opened the door for the hacker to impersonate a system admin (called a "Keeper") who was supposed to set prices.

The system assumed that messages coming through the forwarding tool were always from trusted entities, and that assumption was wrong. In the end, the hacker abused the trust built into the system's code and drained millions from the platform.

2. Introduction

On April 14, 2025, KiloEx, a decentralized perpetual trading platform on BNB Chain, Base, and Taiko networks, suffered a major exploit that led to the loss of over $7.4 million. The breakdown of the losses included approximately $3.3 million on Base, $1 million on BSC, and $3.1 million on opBNB. The root cause was traced to a critical access control vulnerability in the MinimalForwarder contract, which failed to adequately verify the legitimacy of forwarded calls. This enabled the attacker to initiate transactions that appeared authorized, despite being forged.

KiloEx enables leverage trading on various crypto assets through perpetual contracts. Its trading infrastructure relies on smart contracts to manage risk, execute trades, and maintain up-to-date pricing via oracle feeds. Liquidity pools provide the capital for traders to open positions, and these mechanisms require strong access controls to prevent abuse. Given the complexity and the value at stake, such systems are often targeted by malicious actors who seek to exploit overlooked permission settings or flawed trust assumptions in contract logic.

In this case, the attacker exploited the MinimalForwarder by forging a signature and injecting a spoofed from address, allowing them to impersonate trusted Keeper roles. This unauthorized access granted them control over the setPrices() function in the KiloPriceFeed contract. By artificially lowering and later inflating the oracle price of an asset like ETH, the attacker opened a leveraged long position at a deflated price and closed it at a heavily inflated one. This price manipulation loop allowed them to extract substantial profits from the liquidity pools, resulting in a multi-chain drain of protocol funds.

Attack Transactions

Base:

• Transaction 1 ($3.13M): 0x6b378c84aa57097fb5845f285476e33d6832b8090d36d02fe0e1aed909228edd

• Transaction 2 ($187k): 0xde7f5e78ea63cbdcd199f4b109db2a551b4462dec79e4dba37711f6c814b26e6

• Transaction 3 ($11k): 0xf0fcce0807a82041d050a60461e187f0e81a6f7fbda69bb600c04049d924e138

BNB:

• Transaction ($893k): 0x1aaf5d1dc3cd07feb5530fbd6aa09d48b02cbd232f78a40c6ce8e12c55927d03

• Transaction 2 ($10k): 0x38b25be14b83fd549d5e0b29ba962db83d41f5f9072d0eac4f692fa8e7110bc0

opBNB:

• Transaction 1 ($2.9M): 0x79eb28ae21698733048e2dae9f9fe3d913396dc9d93a0e30d659df6065127964

• Transaction 2 ($205.5k): 0xcfc679a66f1d2966dbe83bb827409c40f29f881c20128107ae73e93ab55c65e4

• Transaction 3 ($14k): 0x783d56ce53af6d59c7c4be374ff48a66257733fadf5905526b5862a54917889f

Taiko:

• Transaction ($41k): 0x9bce6e105cea138fe9fb1e4bfb63fe90d21817db9d2cc6d1bf7697317430215b

Manta:

• Transaction ($100k): 0x06074831103a1e91c7b6dcb3b641cf4b79bfa208ea75e99cf9b5100d60a82df5

Addresses

Attacker Address:

• 0x00faC92881556A90FdB19eAe9F23640B95B4bcBd - Ethereum

• 0x00faC92881556A90FdB19eAe9F23640B95B4bcBd - Base

• 0x00faC92881556A90FdB19eAe9F23640B95B4bcBd - BNB

• 0x00faC92881556A90FdB19eAe9F23640B95B4bcBd - opBNB

• 0x00faC92881556A90FdB19eAe9F23640B95B4bcBd - Taiko

• 0xd43b395efad4877e94e06b980f4ed05367484bf3 - Manta

Victim’s Address:

• 0xdf5ACC616cD3ea9556EC340a11B54859a393ebBB

3. The Core Vulnerability

The root cause of the KiloEx exploit was a flaw in the access control mechanism implemented within the MinimalForwarder contract — a contract intended to facilitate meta-transactions, allowing users to interact with the protocol by relaying signed messages without directly paying gas. However, the design lacked critical verification logic, particularly around identity enforcement and signature validation.

At the center of the vulnerability was the execute() function of the MinimalForwarder contract. While this function correctly decoded the provided ECDSA signature parameters (v, r, s) and used ecrecover to reconstruct the signer’s address, it failed to enforce that the recovered signer matched the from address specified in the transaction payload. In doing so, it allowed any entity to:

• Forge a valid-looking signature using their own private key.

• Specify an arbitrary address in the from field, including that of a trusted Keeper.

• Relay transactions as though they originated from that trusted address, effectively bypassing authentication and role-based access control.

This allowed the attacker to take on the role of a Keeper (a role trusted to feed external price data into KiloEx’s oracle system) without possessing the actual Keeper's private key or credentials.

Once the attacker had assumed this role, they were able to invoke privileged functions downstream, particularly the setPrices() function exposed by the KiloPriceFeed contract, and manipulate oracle prices to their advantage during trading operations.

The exploit unfolded across multiple interlinked smart contracts, each of which played a role in enabling the unauthorized action:

1. MinimalForwarder Contract:

• Designed to relay user-signed transactions using meta-transactions.

• Lacked enforcement to confirm that the signer of the transaction (via ecrecover) matched the from address.

• Allowed an attacker to send a transaction that appeared to come from a legitimate Keeper address, though it was actually signed by the attacker.

• Became a vulnerability gateway, forwarding malicious calls to other protocol components under the guise of trusted identities.

2. PositionKeeper Contract:

• Managed user trading positions, including opening and closing long/short positions.

• Exposed functions that could be invoked through forwarded calls from MinimalForwarder.

• Contained function selector 0xac9fd279, which acted as a passthrough to the Keeper system, this allowed the maliciously forwarded request to reach the oracle update layer.

3. PositionKeeper Contract:

• Tasked with feeding real-time price data into the protocol’s oracle.

• Interfaced with the setPrices() function to update asset pricing.

• Relied on the assumption that only authorized Keeper addresses could invoke its logic — an assumption invalidated by the MinimalForwarder flaw.

4. KiloPriceFeed Contract:

• Oracle contract responsible for maintaining and distributing token price data across the platform.

• Hosted the setPrices() function, which was manipulated repeatedly by the attacker.

• Price updates were blindly trusted by the protocol once submitted by what appeared to be a valid Keeper, leading to malicious price feeds being accepted and acted upon.

Through this multi-contract interaction, the attacker conducted a series of trades that profited from manipulated oracle data, repeatedly setting prices via fake Keeper calls and executing trades on artificially inflated or deflated prices.

4. Attack Flow

The attacker self-funded their address through Tornado Cash, commonly used to obscure the origin of funds. This initial step allowed them to hide their on-chain identity before executing the exploit.

The attack chain then began with the attacker using the flawed forwarder to call a function in the PositionKeeper contract. This function (identified by selector 0xac9fd279) is designed to handle position and price operations by communicating with the Keeper contract.

The forwarder met the only access control in place—require(msg.sender == trustedForwarder)—and so the call proceeded. Internally, PositionKeeper then invoked a privileged function on the Keeper contract (selector 0x7a498a61), believing that the request originated from a legitimate keeper via the trusted forwarder. This assumption was false, but due to the flawed call chain validation, the protocol treated the request as valid.

The Keeper contract then subsequently called the KiloPriceFeed::setPrices() function, which is only callable by the Keeper. This function is responsible for updating the oracle’s recorded asset prices and is gated by the onlyKeeper modifier, which checks that msg.sender is the Keeper contract. Since this condition was satisfied, the attacker’s rogue price values were accepted without further validation.

Through this multi-step chain, the attacker effectively gained the ability to update KiloEx’s oracle prices at will. They called the execute() function of the MinimalForwarder contract to submit a forged request targeting the PositionKeeper contract, which accepted artificially lowered price data. This manipulation set the price of ETH to an extremely low level, around $100, allowing the attacker to open a large leveraged long position at this depressed price. By doing so, the attacker positioned themselves to gain significantly from any subsequent price increase.

With the low price locked in as the entry point, the attacker then executed a second setPrices() call, this time inflating ETH’s price to approximately $10,000. This artificial price spike caused the attacker’s position to become highly profitable on paper.

Immediately afterward, the attacker closed the long position, locking in profits derived from the manipulated spread. On the Base chain alone, this sequence of events allowed the attacker to drain around $3.3 million from the protocol. The core mechanism relied entirely on impersonating a trusted keeper and abusing the trust assumptions embedded within each contract.

The vulnerability was not isolated to a single deployment. KiloEx had been deployed on multiple chains, including Base, BSC, and opBNB, and each of these instances relied on the same flawed meta-transaction forwarder and permission model. The attacker repeated the exploit across these chains using the same forged call path, which consistently bypassed access controls by exploiting the spoofed from field in the meta-transactions. The result was a cross-chain extraction of funds that totalled approximately $7.5 million in losses.

5. Impact of the Attack

Total Loss: ~$7.4 million

Impact by Chain:

Base: ~$3.3M

BSC: ~$1M

opBNB: ~$3.1M

• Before attack

• After attack

Also, the TVL in the KiloEx protocol fell by approximately 21.53%, reflecting a sharp reduction in the amount of capital held within the protocol, likely due to a combination of direct fund losses from the attack and subsequent user withdrawals driven by a loss of confidence in the platform’s security.

6. How the Protocol Responded

Following the exploit, KiloEx responded swiftly with a series of actions aimed at damage control and transparency. On April 15, 2025, the team publicly acknowledged the incident through a Security Incident Announcement shared on X (formerly Twitter). In the statement, they confirmed the vault exploit and shared the attacker’s wallet address to maintain transparency with the community. Users were warned not to interact with the affected contracts until further notice.

In the aftermath, KiloEx engaged multiple security and blockchain investigation partners to aid in tracing and recovering the stolen funds. These partners are assisting with transaction tracing, forensic analysis, and intelligence gathering to help identify the attacker and potentially retrieve lost assets.

In addition to working with external partners, KiloEx also issued a public bounty to the attacker. They offered 10% of the stolen funds as a reward for the safe return of the remainder, with a promise of no legal action if the attacker complied. This form of ultimatum is becoming increasingly common in defi, where traditional legal recourse can be slow or ineffective. By offering a bounty, KiloEx hopes to incentivize partial recovery while maintaining open channels of communication with the attacker, if only temporarily.

7. How the Attack Could Have Been Prevented

Below are key security practices and design principles that, if implemented, would likely have prevented the exploit:

1. Enforce Signature Ownership Validation: While the MinimalForwarder.execute() function used ecrecover to extract the signer from a signature, it did not check whether the recovered address matched the from field in the meta-transaction. This missing require(recovered == from) check enabled the attacker to impersonate the identity of a trusted keeper. Adding this simple condition would have ensured that only the rightful signer could execute forwarded calls on their behalf, rendering the forged requests invalid.

2. Add Price Sanity Checks and Rate Limiting: The setPrices() function in the PriceFeed contract accepted arbitrary price inputs without any sanity checks or rate-limiting mechanisms. It trusted that the Keeper would always provide accurate data. Instead, the function should have included protections such as:

   ⭢Rejecting new prices that deviate significantly from previous values (e.g., >10% in a short time).

   ⭢Preventing rapid successive updates to the same asset.

   ⭢Requiring multiple trusted sources to agree on price data before updating.

3. Thorough Audits, Testing, and Forensic Preparedness: A comprehensive audit would have flagged the missing signature verification in MinimalForwarder, improper reliance on fields that can be impersonated, and the lack of validation in setPrices().

Additionally, in cases where breaches occur despite precautions, timely and professional post-incident analysis is essential. Chainvestigate offers critical value, providing clear, courtroom-ready investigation reports, decoding complex on-chain behavior, and collaborating with legal firms to support recovery and enforcement.

8. Conclusion

The KiloEx exploit highlights how a single point of failure in access control can compromise an entire protocol’s integrity. The attacker took advantage of weak signature verification to pose as an authorized Keeper, manipulating oracle prices to extract millions in profit across several chains.

Incidents like this underscore the importance of rigorous smart contract design, layered permission checks, and continuous monitoring of meta-transaction components.

At Chainvestigate, we specialize in uncovering complex exploit chains like this by combining on-chain forensics with protocol-level analysis. Our tools and expertise help teams identify critical vulnerabilities, trace stolen funds, and stay ahead of emerging threats in the evolving DeFi space.

Image generated via Leonardo.ai