Gondi — refinanceFromLoanExecutionData missing tokenId check

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 35206-h-04-function-refinancefromloanexecutiondata-does-not-check. Standalone Foundry PoC and full write-up: 35206-h-04-function-refinancefromloanexecutiondata-does-not-check_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/wrong-condition · vuln/direct-drain · vuln/access-roles

Reproduction: self-contained Foundry PoC with only forge-std — no fork, no RPC. Full trace: output.txt. PoC: test/35206-h-04-function-refinancefromloanexecutiondata-does-not-check.sol.

Key info#


Impact	HIGH — borrower refinances a junk-NFT loan using a blue-chip-only offer by spoofing `executionData.tokenId`; lender funds principal while only the junk NFT remains in escrow
Protocol	Gondi — NFT multi-source lending
Vulnerable code	`refinanceFromLoanExecutionData` passes `executionData.tokenId` into `_processOffersFromExecutionData` without requiring equality to `loan.nftCollateralTokenId`
Bug class	Missing collateral-id consistency check on refinance
Finding	Code4rena — Gondi, 2024-04 · #35206 · reporter minhquanym
Report	code4rena.com/reports/2024-04-gondi
Source	AuditVault
Status	Audit finding — confirmed and mitigated (`tokenIdCheck` added)
Compiler	`^0.8.24` (PoC)

TL;DR#

Refinance re-uses the NFT already in escrow (no transfer out/in).
Offer validation uses attacker-controlled executionData.tokenId.
No check that it matches the escrowed loan.nftCollateralTokenId.
Lender accepts a blue-chip id; escrow still holds junk → undercollateralized loan.

The vulnerable code#

SOLIDITY

// FIX would be: require(executionData.tokenId == loan.nftCollateralTokenId);
uint256 newLoanId = _processOffersFromExecutionData(
    loan,
    executionData.principalReceiver,
    executionData.tokenId, // @> VULN: unmatched with loan.nftCollateralTokenId
    newOfferId
);

Fix: require(executionData.tokenId == loan.nftCollateralTokenId).

Root cause#

Refinance optimizes by not moving the NFT, but still lets the borrower name a different token id for offer validation. Lenders' collateral constraints are checked against the spoofed id, not the asset actually secured by the protocol.

Attack walkthrough#

Open loan against junk NFT #999.
Post refinance offer requiring blue-chip #1.
Call refinance with executionData.tokenId = 1.
Offer validates; principal paid out; escrow still #999.

Diagrams#

flowchart LR A["Escrowed NFT #999 junk"] --> B["refinance executionData.tokenId = #1"] B --> C["Offer validators check #1"] C --> D["Principal paid to borrower"] D --> E["Escrow still #999"] E --> F["Lender undercollateralized"]

Impact#

Lenders can be forced into loans secured by collateral they never accepted. Principal is at risk of total loss relative to the blue-chip they thought they underwrote.

Taxonomy#

genome: wrong-condition, direct-drain, access-roles, liquidation-underwater, oracle-freshness, reward-accounting
sector: lending, nft, nft-lending, staking
severity: high
platform: code4rena

Sources#

AuditVault finding #35206
Code4rena report 2024-04-gondi
Reduced from code-423n4/2024-04-gondi refinanceFromLoanExecutionData / _processOffersFromExecutionData / _checkValidators

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 35206-h-04-function-refinancefromloanexecutiondata-does-not-check_exp (evm-hack-registry mirror).
AuditVault finding: 35206-h-04-function-refinancefromloanexecutiondata-does-not-check.

Alerts & third-party analyses

Web3Sec X hacked database: search.
Rekt leaderboard: search.
Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.

Source-level debugger — step opcodes and Solidity in sync