# Frontrunning for unallowed minting of Short and Long tokens

PrePOMarket mint() had no access control until governance set the mintHook, letting anyone frontrun setMintHook to mint Long/Short tokens.

- Payout: Contest reward
- Severity: medium
- Program: prePO
- Credited: zaskoh
- Disclosed: 2023-01-27
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-12-prepo-findings/issues/93
- Library page: https://bugbountylibrary.com/r/c4%3A2022-12-prepo%3AM-03
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:race-window technique:source-review vuln:access-control vuln:business-logic

**Target:** PrePOMarket.sol mint()/setMintHook on EVM
**Root cause:** mint() relies solely on the _mintHook for access control, but _mintHook is unset at deployment and only set later via setMintHook, leaving a window where mint() is unrestricted.
**Steps:**
1. Deploy market via PrePOMarketFactory (mintHook unset).
2. Attacker observes pending setMintHook tx in mempool.
3. Attacker submits `prePOMarket.mint(TEST_MINT_AMOUNT)` with higher gas, after approving collateral.
4. mint() succeeds since _mintHook is address(0)/unset; attacker receives Long and Short tokens.
5. Governance setMintHook lands afterward; subsequent mint() reverts for attacker.
**How found:** Code reading: noticed _mintHook not set in constructor and docs state minting should be governance-only; hypothesized a frontrun window before setMintHook.
**Exploitation:** Attacker frontruns the governance setMintHook transaction, calling mint() with approved collateral to obtain Long and Short tokens before access control activates, then can redeem/sell them.
**Insight:** When access control is delegated to a hook set post-deployment, check the constructor for unset hooks—any privileged setter creates a frontrunnable window where the guarded function is open.