# maxSumOfPrices check is broken

rentAllCards checks _maxSumOfPrices before applying the forced 10% bid increase, so total bids can exceed the user's stated cap, risking foreclosure.

- Payout: Audit contest
- Severity: medium
- Program: Reality Cards
- Found by: 0xRajeev
- Disclosed: 2021-08-02
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-06-realitycards-findings/issues/87
- Library page: https://bugbountylibrary.com/r/c4%3A2021-06-realitycards%3AM-07
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic

**Target:** rentAllCards() in Reality Cards rental contract
**Root cause:** The _maxSumOfPrices check is performed on the pre-increase rental prices, but a forced 10% increase is applied afterward when the sender doesn't own the card, so the actual sum of bids exceeds the user-specified cap.
**Steps:**
1. Call `rentAllCards()` with `_maxSumOfPrices` = 101 for a market with two cards at winning rental 50 each.
2. Check on L643 passes since 50+50=100 <= 101.
3. Forced 10% increase on L650 (sender not owner of either card) makes each new rental 55.
4. `newRentals` is called with 55 per card, totaling 110 > 101.
**How found:** Reading the Natspec @param comment stating _maxSumOfPrices limits the sum of bids for front-run protection, then comparing the check location against the later 10% increase logic.
**Exploitation:** User specifies a max sum they can afford; the contract places bids exceeding that cap, potentially leaving the user under-deposited and subject to foreclosure or impacting other bids/markets.
**Insight:** When a function documents a user-supplied cap for front-run protection, verify the cap is enforced against the final post-adjustment values, not intermediate ones—any later fee/percentage bump can silently breach it.