# LienToken.transferFrom There is a possibility of malicious attack

LienToken.transferFrom blocks transfers to existing PublicVaults, but an attacker can front-run a vault's creation and transfer a lien to its predicted address, corrupting vault accounting.

- Payout: Contest reward
- Severity: medium
- Program: Astaria
- Credited: bin2chen
- Disclosed: 2023-05-22
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-01-astaria-findings/issues/571
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-astaria%3AM-04
- Tags: domain:web3 impact:dos impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:race-window vuln:access-control vuln:accounting-error vuln:business-logic

**Target:** LienToken ERC721 transferFrom / PublicVault accounting
**Root cause:** transferFrom only checks _isPublicVault(to) at transfer time; a not-yet-deployed PublicVault address is not recognized, so a lien can be transferred to a predicted future vault address. Vault accounting then reads ownerOf(lienId) and misattributes yIntercept/slope/last/epochData updates.
**Steps:**
1. Alice creates a PrivateVault and mints LienTokens owned by it.
2. Alice observes Bob's AstariaRouter.newPublicVault() tx and computes the CREATE address from Bob's address + nonce.
3. Alice front-runs, calling LienToken.transferFrom(privateVault, predictedPublicVaultAddr, lienId) before the vault exists; _isPublicVault(to) returns false so it passes.
4. Bob's PublicVault deploys at the predicted address and issues loans.
5. Alice calls makePayment()/buyoutLien()/payDebtViaClearingHouse() on the lien; the vault mutates yIntercept, slope, last, epochData based on the lien it now owns, corrupting accounting.
**How found:** Code review of transferFrom's _isPublicVault(to) guard; noticed the check is time-of-transfer only and that CREATE addresses are predictable, so a pre-deployment transfer bypasses it.
**Exploitation:** Attacker front-runs vault deployment to plant a lien on the future PublicVault address, then triggers payment/buyout paths so the vault applies lien math to state it never legitimately acquired, breaking vault invariants and DoS-ing normal operation.
**Insight:** Address-prediction checks on 'is this a contract/known role' are bypassable by acting before deployment; look for guards that validate recipient state at transfer time rather than binding to an immutable origin recorded at mint.