All incidents
Loading report...
Overview
Code Analysis
Execution Trace
Root Cause Analysis
Rendering incident details
0x614da880bd46e98131accd9a83917abf3d56dac94caf13ae98eeff504eea37040x05c2dd9cf547c6cccf91245346e6e1bc9926cae7BSC0xf5a32e5e54a771b9d3c853143db74449b721c03bBSCAn unprivileged BSC account exploited WXETA in transaction 0x614da880bd46e98131accd9a83917abf3d56dac94caf13ae98eeff504eea3704 by calling a permanently reusable initialize(uint256) entrypoint through the live token proxy at 0x05c2dD9cf547C6cCCF91245346E6E1BC9926cae7. That call rewrote privileged WXETA facet state, changed the supply cap from 5000000000000000000000000000 to type(uint256).max, granted the attacker authorization, and enabled arbitrary minting. The attacker then minted 1000000000000000000000000000000000 WXETA directly into the WXETA/BUSD PancakeSwap pair at 0xF5a32e5E54a771B9d3C853143db74449B721C03B, drained 49847502413020099894895 BUSD, routed the proceeds through PancakeRouter into WBNB, and exited with 88290457843955339022 wei of net profit.
The root cause is a broken one-time initializer: initialize(uint256) checks !s.initialized but never flips s.initialized to true. Because the live token delegates into this facet, any caller could repeatedly seize owner-like privileges, authorize itself, raise maxSupply, and mint arbitrary WXETA.
WXETA is the token at 0x05c2dD9cf547C6cCCF91245346E6E1BC9926cae7. Its callable token logic delegates into the verified facet at , so writes performed inside the facet affect the live token storage.
0x7c83Dc9221CfD48aC760710B7f1Cd7b76fF6Fcc2The relevant liquidity venue is the PancakeSwap V2 pair 0xF5a32e5E54a771B9d3C853143db74449B721C03B, where WXETA is token0 and BUSD is token1. Before exploitation, the pair held 16980465070589468509660116 WXETA and 49848502413020099894895 BUSD. In a V2 pair, if one side of inventory is artificially increased, the pair will release the opposite reserve as long as the invariant check passes after the swap.
The exploit did not require privileged keys, governance, flash loans, or private orderflow. The required ingredients were public access to initialize, post-reinitialization mint authority, and public WXETA/BUSD liquidity on PancakeSwap.
WXETA's vulnerability is a public reinitialization flaw that reopens privileged state forever. The facet stores owner, initialized, _maxSupply, and authorized in a fixed storage namespace, then exposes initialize(uint256), mint(address,uint256), and setAuthorized(address,bool). The intended safety invariant is that after the first initialization, owner, authorization, and maxSupply must no longer be publicly mutable except through the explicit owner-gated admin path. That invariant fails because initialize(uint256) never writes s.initialized = true after passing require(!s.initialized, "WXETA: already initialized"). As a result, any caller can overwrite owner, set authorized[msg.sender] = true, and replace the finite cap with an arbitrary value. Once the attacker becomes authorized, mint(address,uint256) is sufficient to create pool-side WXETA inventory and drain BUSD from the PancakeSwap pair. This is an application-level access-control failure and correctly classified as ATTACK.
The verified victim code shows the exact bug:
function initialize(uint256 max) public {
WXETASTORAGE storage s = getWXETAStorage();
require(!s.initialized, "WXETA: already initialized");
s._maxSupply = max;
s.owner = msg.sender;
s.authorized[msg.sender] = true;
s.name = "Wrapped Xeta";
s.symbol = "WXETA";
s.decimals = 18;
}
initialize never closes its own guard. Because the live token delegates into this facet, every later caller can re-run the initialization body against the live token's storage.
The exploit trace confirms that behavior in the live system. During the attacker transaction, the created helper contract called 0x05c2dD9cf547C6cCCF91245346E6E1BC9926cae7::initialize(type(uint256).max), which delegated into the facet and changed both the owner slot and max-supply slot:
0x05c2...cae7::initialize(type(uint256).max)
0x7c83...fcc2::initialize(...) [delegatecall]
storage changes:
owner: 0x...b071bac7... -> 0x...11bffb96...
_maxSupply: 5000000000000000000000000000 -> 0xffff...ffff
authorized[helper]: 0 -> 1
Once authorized, the helper called mint and created 1e33 WXETA directly in the pair:
0x05c2...cae7::mint(0xF5a3...C03B, 1000000000000000000000000000000000)
0x7c83...fcc2::mint(...) [delegatecall]
That artificial inventory injection changed the pair's accounting enough to let the attacker request almost the entire BUSD reserve. The trace then shows:
0xF5a3...C03B::swap(0, 49847502413020099894895, 0x11Bf...604E, 0x)
After the swap, the pair's BUSD balance was reduced to 1000000000000000000 wei of BUSD, which matches the balance-diff artifact. The attacker-approved PancakeRouter at 0x10ED43C718714eb63d5aA57B78B54704E256024E, swapped the drained BUSD through the BUSD/WBNB market, withdrew native BNB, paid 0.01 BNB to 0x4848489f0b2bedd788c696e2d79b6b69d7484848, and self-destructed the remaining balance back to the originating EOA.
The critical exploit conditions were all public and permissionless:
initialize through the live token,authorized[msg.sender] = true,maxSupply high enough to support arbitrary minting,The adversary-controlled EOA was 0x57ecf40b596274a985967e3f698437ae0a9600a0. It created helper contract 0x11bffb96daa9b0c47fef01401eb089549e87604e inside the exploit transaction. That helper contract executed the entire state-takeover and monetization flow in one transaction.
Stage 1 was state takeover. The helper called initialize(type(uint256).max) on the live WXETA token. Because initialize remained callable, this replaced the previous owner 0xB071BaC7A7139a5427B234BeF33Da5c9b61b9Efd, marked the helper as authorized, and raised the cap from 5000000000000000000000000000 to type(uint256).max.
Stage 2 was artificial inventory injection. The helper minted 1000000000000000000000000000000000 WXETA into the WXETA/BUSD pair and then called pair.swap(0, 49847502413020099894895, helper, ""). Because the pair now observed enormous WXETA inventory, it transferred out nearly all BUSD liquidity.
Stage 3 was monetization and exit. The helper approved PancakeRouter, swapped the stolen BUSD for 88302060368955339022 wei of WBNB via the BUSD/WBNB market, withdrew to native BNB, paid 10000000000000000 wei to 0x4848489f0b2bedd788c696e2d79b6b69d7484848, and self-destructed 88292060368955339022 wei back to the originating EOA. The originating EOA's balance diff shows a net increase of 88290457843955339022 wei after gas.
The measurable loss was borne by the WXETA/BUSD PancakeSwap pool, not by any legitimate attacker inventory. The pair lost 49847502413020099894895 BUSD and was left with only 1000000000000000000 BUSD. Because the attacker minted WXETA out of thin air after seizing authorization, the pool effectively exchanged real BUSD reserves for unbacked inventory.
The directly observed loss record is:
{
"token_symbol": "BUSD",
"amount": "49847502413020099894895",
"decimal": 18
}
The attacker realized profit in native BNB terms, with the originating EOA ending the transaction 88290457843955339022 wei above its starting balance net of gas.
0x614da880bd46e98131accd9a83917abf3d56dac94caf13ae98eeff504eea3704 on BSC block 422841620x05c2dD9cf547C6cCCF91245346E6E1BC9926cae70x7c83Dc9221CfD48aC760710B7f1Cd7b76fF6Fcc20xF5a32e5E54a771B9d3C853143db74449B721C03B0xe9e7CEA3DedcA5984780Bafc599bD69ADd087D560xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c0x10ED43C718714eb63d5aA57B78B54704E256024E