Key Highlights
- Security researcher ExVul reported that a BNB Chain DEX router was exploited for approximately 62.28 WBNB.
- The researcher said 29 wallets were affected through existing token approvals.
- The reported attack involved a fake liquidity pool and a suspected failure to verify a Uniswap V3-style swap callback.
A DEX router on BNB Chain was reportedly exploited after an attacker found a way to use existing token approvals to withdraw assets from multiple wallets.
Security researcher ExVul reported the incident on X on September 7, saying approximately 62.28 WBNB was extracted and that 29 wallets were affected.
The router’s development team has not independently confirmed the claims, while the full scope of the incident, including potentially affected tokens and approvals, remains unclear.
Suspected exploit centered on router callback
According to ExVul’s analysis, the reported attack involved the router’s handling of a Uniswap V3-style swap callback.
The researcher alleged that the router’s uniswapV3SwapCallback function accepted a caller-supplied payer address and then used transferFrom() to move tokens from that address.
ExVul said the router did not sufficiently verify that the callback came from a legitimate V3 liquidity pool created through the expected factory.
The researcher also pointed to the router’s factoryV3 configuration being set to 0x0, which ExVul said prevented the expected pool verification.
If the assessment is correct, an attacker could create a contract that behaved like a V3 pool and use it to trigger the router’s callback.
The alleged mechanism would allow the attacker to use token allowances previously granted to the router without obtaining users’ private keys.
How the reported attack worked
ExVul described the transaction as a sequence of steps:
- The attacker obtained 1 WBNB through a PancakeSwap flash swap to cover gas costs.
- The attacker deployed or configured a contract designed to imitate a V3 pool.
- The attacker called the router’s swap function while specifying a victim address as the payer.
- The fake pool triggered the router’s uniswapV3SwapCallback() function.
- The router allegedly used the victim’s existing approval to execute transferFrom().
- The extracted tokens were transferred to the attacker’s address and exchanged for BNB.
- The initial flash-swap amount was repaid, leaving the remaining proceeds with the attacker.
ExVul said the same mechanism was used against multiple wallets and tokens during the transaction.
Existing approvals create the main user risk
The reported incident highlights the risk associated with persistent token approvals.
When users approve a DEX router to spend their tokens, that authorization can remain active until it is reduced or revoked. A flaw in the router could therefore potentially allow approved assets to be moved without compromising the wallet’s private key.
ExVul said the reported issue could affect addresses that had previously granted standing or unlimited approvals to the router.
Users who interacted with the reported contract should review their active token approvals and consider revoking permissions they no longer need while the incident is investigated.
Revoking an approval cannot recover assets that have already been transferred, but it can prevent a remaining allowance from being used in a future transaction.
No oracle or price manipulation reported
ExVul said the reported attack did not depend on several mechanisms commonly associated with DeFi exploits.
According to the researcher, the transaction did not require:
- Price manipulation
- Oracle manipulation
- A compromised private key
- Administrative access
- A conventional flash-loan price attack
Instead, the reported mechanism centered on the router’s callback handling and previously granted token permissions.
If confirmed, the incident would involve an authorization and caller-validation issue rather than a conventional market-manipulation attack.
BNB Chain activity provides broader context
The incident occurred on a network handling substantial transaction and trading activity.
A Dune dashboard referenced in the report showed approximately 13.86 million transactions over 24 hours, more than 100.79 million over seven days, and around 431.93 million over 30 days.
BNB Chain activity of September 7 | Source: Dune
The dashboard also recorded approximately 2.63 million daily active accounts, 11.35 million weekly active accounts, and 35.55 million monthly active accounts.
DEX activity included PancakeSwap and Uniswap, with several trading pairs recording substantial volumes.
These figures do not establish a connection between overall BNB Chain activity and the reported exploit.
Recent BNB Chain exploits show different attack patterns
The reported router incident follows other security incidents involving BNB Chain projects.
In August, security firm TenArmor reported an approximately $907,700 loss involving the MOKE token. On-chain activity showed movements involving MOKE, WBNB, and PancakeSwap liquidity-pool contracts.
The mechanism behind that incident remained unclear because a detailed post-mortem or confirmed root cause had not been released at the time.
The two incidents involved different reported attack patterns. The MOKE case centered on suspected liquidity-related manipulation, while the latest incident described by ExVul involves router permissions and callback validation.
On-chain details
ExVul identified the following addresses in its analysis:
- Attack transaction: 0x40eb22369da422a8275d5679054aa3a8c8906d93abc0bac3a3f2cad879389319
- Reported attacker: 0xB929C7215c0ec8EbAD5fBf73b1Da63bccfFf1896
- Reported router: 0xa331fde028e6F17425AB9333c39ae43722340d24
- Reported amount extracted: approximately 62.28 WBNB
- Reported affected wallets: 29
The transaction provides an on-chain reference for further analysis, while the technical conclusions are based primarily on ExVul’s assessment.
The Crypto Times has reached out to the teams behind the affected routers, Uniswap V3 and PancakeSwap, for clarification.
What users should check
Users who previously interacted with the reported router should review their wallet approvals associated with the contract.
They should check for:
- Active approvals granted to the reported router
- Unlimited or unusually large spending allowances
- Tokens that remain approved
- Wallets that previously interacted with the contract
Users should verify the contract address before taking action, particularly when revoking permissions or interacting with security tools.
Investigation continues
The key question is whether the router’s callback mechanism allowed previously granted spending permissions to be used for unauthorized transfers.
Further analysis of the transaction and a response from the affected project will be needed to determine the root cause, identify the full number of affected wallets, and establish whether other users remain exposed.
For now, the incident remains based primarily on ExVul’s analysis and the reported on-chain transaction.
Also Read: Coldcard Hacker Moves 45% of Wave 3 Bitcoin via THORChain and CoinJoins
