# old borrowing key is used instead of `newBorrowingKey` when adding old loans to the newBorrowing in LiquidityBorrowingManager.takeOverDebt()

In takeOverDebt, old borrowing key was passed to _addKeysAndLoansInfo instead of newBorrowingKey, corrupting tokenId-to-borrowingKey mapping for taken-over loans.

- Payout: Contest reward
- Severity: high
- Program: Real Wagmi
- Credited: 0xMAKEOUTHILL
- Disclosed: 2023-10-07
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-10-real-wagmi-judging/issues/53
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-10-real-wagmi%3AH-1
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** LiquidityBorrowingManager.takeOverDebt()
**Root cause:** After deleting old borrowing storage and creating newBorrowingKey via _initOrUpdateBorrowing, the code calls _addKeysAndLoansInfo with the stale old borrowingKey instead of newBorrowingKey, so old loans' tokenIds get mapped to the deleted key.
**Steps:**
1. Call takeOverDebt on an existing borrowing.
2. Observe _removeKeysAndClearStorage deletes old borrowing credentials.
3. _initOrUpdateBorrowing creates newBorrowingKey for the taker.
4. _addKeysAndLoansInfo is invoked with old borrowingKey (L440-441) rather than newBorrowingKey.
5. tokenIdToBorrowingKeys for old loans now points to the deleted key, breaking subsequent loan lookups/repayment.
**How found:** Code reading of takeOverDebt flow: noticed _removeKeysAndClearStorage deletes the old key, then _addKeysAndLoansInfo was passed the old key variable instead of the freshly returned newBorrowingKey.
**Exploitation:** Not a direct theft path; state corruption of tokenIdToBorrowingKeys causes taken-over loans to reference a deleted borrowing key, breaking accounting and potentially locking or misattributing loan state.
**Insight:** In takeover/refinance flows, trace every variable passed after storage deletion—stale keys reused post-delete silently corrupt reverse-index mappings (tokenId->key) even when the primary struct is recreated.