# FeeManager `receiveFee` and `trackVaultFee` functions allow anyone to call it with user-provided dvp/vault address and add any arbitrary feeAmount to any address, breaking fees accounting and temporarily bricking DVP smart contract

FeeManager's unauthenticated trackVaultFee and receiveFee let any contract spoof vault/baseToken, inflating fees to uint256.max and bricking DVP mints/burns.

- Payout: Contest reward
- Severity: medium
- Program: Smilee Finance
- Credited: 3docSec
- Disclosed: 2024-02-01
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-02-smilee-finance-judging/issues/43
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-02-smilee-finance%3AM-6
- Tags: domain:web3 impact:dos impact:integrity kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic vuln:dos vuln:fee-bypass

**Target:** FeeManager.sol (trackVaultFee, receiveFee)
**Root cause:** trackVaultFee and receiveFee trust msg.sender to implement vault()/baseToken() without any whitelist or role check, so any attacker-controlled contract can pass arbitrary vault addresses and fee amounts.
**Steps:**
1. Deploy attacker contract implementing vault() returning a real DVP's vault address.
2. Call `FeeManager.trackVaultFee(vault, type(uint256).max)` from it; vaultFeeAmounts[vault] overflows on subsequent additions.
3. All DVP mints/burns calling trackVaultFee now revert, bricking the DVP until FeeManager is swapped in AddressProvider.
4. Alternatively deploy contract with baseToken() returning a fake ERC20 and call `receiveFee(feeAmount)` to inflate senders[attacker] accounting.
**How found:** Manual review of FeeManager access control: noticed trackVaultFee/receiveFee only validate msg.sender via interface calls (vault(), baseToken()) rather than a whitelist, making the checks spoofable.
**Exploitation:** Attacker deploys a contract exposing vault()/baseToken(), calls trackVaultFee with uint256.max to overflow vault fee accounting and DoS DVP mints/burns, or receiveFee with a worthless self-issued token to fake fee credit withdrawable by admin.
**Escalation:** Inflating to uint256.max causes overflow reverts on every subsequent trackVaultFee call, bricking all DVP mints and burns protocol-wide.
**Insight:** When a contract authenticates callers by calling an interface method on msg.sender (vault(), baseToken()), any attacker contract can implement that method and pass the check; look for trust established via caller-supplied interface returns instead of a registry/whitelist.