# 0xf340: missing access control in initVRF drains LINK

Unprotected initVRF on 0xf340 contract let attacker set a storage address, then a hidden selector drained LINK tokens to them for ~4k USD.

- Payout: Real-world hack
- Severity: high
- Program: 0xf340
- Credited: DeFiHackLabs
- Disclosed: 2025-08-27
- Write-up quality: 6/10
- Original: https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/2025-08/0xf340_exp.sol
- Library page: https://bugbountylibrary.com/r/dhl%3A20250827-0xf340
- Tags: domain:web3 impact:funds-loss kind:incident platform:defihacklabs sev:high tech:evm tech:solidity technique:source-review vuln:access-control

**Target:** Ethereum smart contract (VRF/LINK-handling contract)
**Root cause:** initVRF lacks access control, allowing anyone to write an arbitrary address into storage that a later function (selector 0x607d60e6) uses as the LINK recipient.
**Steps:**
1. Fork mainnet at block 23232612.
2. Call `victim.initVRF(address(this), address(link))` to set attacker address and LINK token in storage.
3. Loop 80 times calling `victim.call(0x607d60e6, 0)` to trigger LINK transfers to attacker.
4. Approve LINK to Uniswap V2 router and `swapExactTokensForETH` LINK->WETH to realize ETH.
**How found:** Likely source review of the contract revealing initVRF had no caller restriction and that a separate function used the stored address to send LINK.
**Exploitation:** Attacker set themselves as recipient via unprotected initVRF, then repeatedly invoked the payout selector 0x607d60e6 to siphon LINK held by the contract, swapping to ETH via Uniswap V2.
**Insight:** On contracts holding tokens, look for initializer/setter functions without access control that write addresses later used as transfer recipients; then enumerate unknown selectors that consume that storage.