We do not have a reliable USD price for the recorded assets yet.
0x109ea28dbdea5e6ec126fbc8c33845dfe812a300BSC0x12180bb36ddbce325b3be0c087d61fce39b8f5a4BSCOn BNB Smart Chain, an unprivileged attacker cluster exploited Hunny Finance by combining attacker-deployed reward helpers, a small CAKE/WBNB LP position in CakeFlipVault, and direct CAKE transfers into HunnyMinter. In the profit transaction 0x765de8357994a206bb90af57dcf427f48a2021f2f28ca81f2c00bc3b9842be8e at block 7968483, the attacker swapped BNB into CAKE, donated CAKE into HunnyMinter at 0x109ea28dbdea5e6ec126fbc8c33845dfe812a300, triggered two helper reward claims through CakeFlipVault at 0x12180bb36ddbce325b3be0c087d61fce39b8f5a4, received freshly minted HUNNY, and sold that HUNNY back into the public HUNNY/WBNB market for a net native profit.
The root cause is an accounting bug in HunnyMinter.mintFor(): the function mints rewards based on the contract's entire current CAKE balance rather than only the fee tokens just pulled from the authorized vault caller. That design lets third-party CAKE donations become reward input for the next authorized mintFor() call and therefore lets an attacker turn donated CAKE into attacker-owned HUNNY.
The relevant Hunny Finance flow is the reward-claim path for the CAKE/WBNB LP vault. CakeFlipVault is configured for staking token 0x0ed7e52944161450477ee417de9cd3a859b14fd0 and reward token 0x0fcd52fd40b77e28062cf9889dc3779c31c171fe, and it is authorized to call . A normal vault user can deposit LP into , later call , and receive HUNNY minted on the basis of vault fees.
0x765de8357994a206bb90af57dcf427f48a2021f2f28ca81f2c00bc3b9842be8eHunnyMinter.mintFor(...)CakeFlipVaultgetReward()The attacker did not need protocol privileges. The two helper contracts at 0x515fb5a7032cdd688b292086cf23280beb9e31b6 and 0x5794bafeaf459397883bb62cffcd95fd6c462a01 are ordinary attacker-owned contracts that stake LP in CakeFlipVault, call getReward(), and forward the resulting HUNNY back to the attacker-controlled caller. The orchestration wrapper at 0xb9b0090aaa81f374d66d94a8138d80caa2002950 exists only to automate LP creation, CAKE donation, reward claims, and the HUNNY sale.
Because LP creation, vault deposit, direct CAKE transfer, reward claiming, and exit swaps are all permissionless, the opportunity is an ACT-style exploit that can be reproduced by any fresh unprivileged actor on the same public state.
The vulnerability is a reward-accounting flaw in HunnyMinter, not a missing access-control check. The intended invariant is that each mintFor(flip, _withdrawalFee, _performanceFee, to, ...) call should mint HUNNY only from the fee tokens collected from the authorized caller during that same call. Unsolicited CAKE transferred into HunnyMinter outside the fee-collection path should not increase the HUNNY minted to the current reward claimant.
The verified source breaks that invariant inside mintFor():
function mintFor(address flip, uint _withdrawalFee, uint _performanceFee, address to, uint) override external onlyMinter {
uint feeSum = _performanceFee.add(_withdrawalFee);
IBEP20(flip).safeTransferFrom(msg.sender, address(this), feeSum);
uint hunnyBNBAmount = tokenToHunnyBNB(flip, IBEP20(flip).balanceOf(address(this)));
address flipToken = hunnyBNBFlipToken();
IBEP20(flipToken).safeTransfer(hunnyPool, hunnyBNBAmount);
IStakingRewards(hunnyPool).notifyRewardAmount(hunnyBNBAmount);
uint contribution = helper.tvlInBNB(flipToken, hunnyBNBAmount).mul(_performanceFee).div(feeSum);
uint mintHunny = amountHunnyToMint(contribution);
mint(mintHunny, to);
oracle.update();
}
The critical breakpoint is IBEP20(flip).balanceOf(address(this)). That expression includes not only the newly transferred vault fee but also any CAKE already sitting in HunnyMinter. An attacker can therefore pre-load CAKE into the minter and make the next authorized reward claim convert that donated balance into HUNNY for the attacker's own reward recipient.
The attack has two deterministic phases. First, the attacker establishes ordinary vault-user identities by deploying two fresh helper contracts and depositing a small CAKE/WBNB LP position for each helper into CakeFlipVault. The helper decompilations show that one function approves and deposits all held CAKE/WBNB LP into the vault, while another function requires tx.origin to equal the stored owner, calls CakeFlipVault.getReward(), then transfers any HUNNY held by the helper to the caller.
Representative helper logic from the decompilation is:
require(tx.origin == (address(store_a)));
address(0x12180bb36ddbce325b3be0c087d61fce39b8f5a4).call(...); // CakeFlipVault.getReward()
address(0x565b72163f17849832a692a3c5928cc502f46d69).call(...); // HUNNY.transfer(msg.sender, balance)
Second, in the exploit transaction, the attacker swaps BNB into CAKE, transfers CAKE directly into HunnyMinter, and immediately calls each helper's reward function. The seed trace shows the exact reward path:
0x515Fb5...::getReward()
0x12180BB...::getReward()
0x109Ea28...::mintFor(CAKE, 0, 142603, 0x515Fb5..., 1622686342)
HunnyPool::notifyRewardAmount(67542479851940232358)
The same trace then shows the second helper repeating the same pattern. Because mintFor() measures the entire CAKE balance held by HunnyMinter after the fee transfer, the attacker's donated CAKE is consumed inside the reward-minting path instead of remaining isolated from rewards. The resulting HUNNY is minted to attacker-controlled helper recipients, forwarded to the attacker, and sold through the public HUNNY/WBNB pair.
The invariant is broken before oracle.update() runs. The failure occurs when mintFor() converts ambient CAKE balance into hunnnyBNBAmount, computes contribution from that inflated quantity, and mints HUNNY to the to address. The later oracle update is merely a follow-on effect.
The adversary flow is fully permissionless and consists of four public transactions:
0x8022243451c218cb0f110e08092c90ad397bd7987c55e74e5cd628946d5908f8 deploys helper contract 0x515fb5a7032cdd688b292086cf23280beb9e31b6.0xf4e2dfc314351e02bf53c44b7700d4266491ef3c93f35b151fc6d70ca430702d deploys helper contract 0x5794bafeaf459397883bb62cffcd95fd6c462a01.0xae8bb771423fd385b076fdf22ccf5a2d58080e9236f6fa64f43a2fd7746ad237 creates a small CAKE/WBNB LP position and stakes it into CakeFlipVault through the helpers so each helper becomes a reward claimant.0x765de8357994a206bb90af57dcf427f48a2021f2f28ca81f2c00bc3b9842be8e performs the profitable sequence: buy CAKE with BNB, donate CAKE to HunnyMinter, trigger two reward claims, receive newly minted HUNNY, and dump HUNNY for BNB.The wrapper decompilation corroborates this behavior. It buys CAKE through PancakeRouter, transfers CAKE to HunnyMinter, calls each helper reward function, checks the resulting HUNNY balance, and then swaps HUNNY back to WBNB/BNB through the same router.
The attacker cluster is:
0x0ef50be29c82ecf2158ec1886dc6692a2b0db4110x515fb5a7032cdd688b292086cf23280beb9e31b60x5794bafeaf459397883bb62cffcd95fd6c462a010xb9b0090aaa81f374d66d94a8138d80caa2002950The victim-side components are HunnyMinter, CakeFlipVault, the HUNNY token contract, and the public PancakeSwap liquidity used for entry and exit.
The measurable protocol-side loss in the seed exploit transaction is 20877839635694049632000 raw HUNNY units, which is 20,877.839635694049632000 HUNNY at 18 decimals. The seed balance-diff artifact attributes that exact delta to the HUNNY/WBNB LP-side circulation change caused by the exploit-driven mint and dump.
The attacker EOA also ends the transaction with a net native gain of 3370298538354152266 wei after gas. The native balance diff records:
{
"address": "0x0ef50be29c82ecf2158ec1886dc6692a2b0db411",
"before_wei": "147640433869305577270",
"after_wei": "151010732407659729536",
"delta_wei": "3370298538354152266"
}
The exploit therefore both inflated HUNNY supply to attacker-controlled recipients and realized immediate exit liquidity through the public HUNNY/WBNB market.
0x765de8357994a206bb90af57dcf427f48a2021f2f28ca81f2c00bc3b9842be8e0x8022243451c218cb0f110e08092c90ad397bd7987c55e74e5cd628946d5908f8, 0xf4e2dfc314351e02bf53c44b7700d4266491ef3c93f35b151fc6d70ca430702d0xae8bb771423fd385b076fdf22ccf5a2d58080e9236f6fa64f43a2fd7746ad237HunnyMinter 0x109ea28dbdea5e6ec126fbc8c33845dfe812a300, CakeFlipVault 0x12180bb36ddbce325b3be0c087d61fce39b8f5a4, HUNNY 0x565b72163f17849832a692a3c5928cc502f46d690x0e09fabb73bd3ade0a17ecc321fd13a19e81ce82, WBNB 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c, CAKE/WBNB LP 0x0ed7e52944161450477ee417de9cd3a859b14fd0, HUNNY/WBNB LP 0x36118142f8c21a1f3fd806d4a34f56f51f33504f