# TrustPad: missing sender check in receiveUpPool inflates rewards

TrustPad staking contract lacked msg.sender verification in receiveUpPool, allowing attacker to repeatedly deposit and withdraw to inflate rewards and steal ~$155K.

- Payout: Real-world hack
- Severity: high
- Program: TrustPad
- Analysis by: DeFiHackLabs
- Disclosed: 2023-11-06
- Write-up quality: 7/10
- Original: https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/2023-11/TrustPad_exp.sol
- Library page: https://bugbountylibrary.com/r/dhl%3A20231106-trustpad
- Tags: area:web3 domain:web3 impact:funds-loss kind:incident platform:defihacklabs sev:high tech:evm technique:source-review vuln:access-control vuln:business-logic

**Target:** LaunchpadLockableStaking contract on BSC
**Root cause:** The receiveUpPool function did not verify that the caller was an authorized pool contract, allowing anyone to credit arbitrary amounts to any account.
**Steps:**
1. Attacker obtains 1 DDD token and approves it to the attack contract.
2. Attacker calls `receiveUpPool(address(this), withdrawAmount)` to credit TPAD balance without actual transfer.
3. Attacker calls `withdraw(withdrawAmount)` to withdraw the credited TPAD, which also updates reward debt.
4. Repeat steps 2-3 multiple times to inflate pending rewards.
5. Call `stakePendingRewards()` to compound rewards, then withdraw all TPAD.
**How found:** Likely identified by reviewing the contract's functions and noticing that receiveUpPool lacked access control, allowing arbitrary balance manipulation.
**Exploitation:** Attacker used a helper contract to repeatedly call receiveUpPool and withdraw, manipulating the staking balance and reward debt to accrue excessive rewards, then withdrew the inflated TPAD tokens.
**Insight:** In staking contracts, functions that update user balances or rewards must verify the caller is a trusted pool or the user themselves; otherwise, attackers can inflate balances and drain rewards.