# TRANSFERING KIBToken TO YOURSELF INCREASES YOUR BALANCE

KIBToken._transfer writes _baseBalances[from] then _baseBalances[to]; self-transfer overwrites the debit, minting balance from nothing.

- Payout: Contest reward
- Severity: high
- Program: KUMA Protocol
- Credited: bin2chen
- Disclosed: 2023-06-23
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-02-kuma-findings/issues/3
- Library page: https://bugbountylibrary.com/r/c4%3A2023-02-kuma%3AH-01
- Tags: domain:web3 impact:funds-loss impact:integrity kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error

**Target:** KIBToken ERC20 _transfer override (Solidity)
**Root cause:** _transfer computes newFromBaseBalance and newToBaseBalance from the same starting balance and assigns _baseBalances[from] then _baseBalances[to]; when from==to the second write overwrites the debit, so balance grows by amount.
**Steps:**
1. Deploy KIBToken; mint 10 ether to alice.
2. As alice call `_KIBToken.transfer(_alice, 5 ether)`.
3. Observe balanceOf(alice) == 15 ether instead of 10.
**How found:** Code review of the overridden _transfer noticed balance updates routed through temporary variables newFromBaseBalance/newToBaseBalance; the author reasoned that if from==to the second assignment clobbers the first, then wrote a Foundry test to confirm.
**Exploitation:** Any holder calls transfer(self, amount) repeatedly; each call increases their balance by amount, allowing infinite minting of KIBToken and draining protocol liquidity/value backed by the token.
**Insight:** In ERC20 overrides that recompute balances via temp variables, always test from==to; the second storage write silently overwrites the debit. Grep for patterns assigning balance[from] then balance[to] from a shared snapshot.