Root + Impact

Description

• The protocol performs an external token transfer before updating internal accounting state, violating the Checks-Effects-Interactions pattern.

• This ordering creates a reentrancy window and potential state inconsistency, where an external token contract can reenter the protocol before critical state variables are updated.

  
  

  In DSCEngine.vy, the collateral redemption flow follows this structure:

Inside _redeem_collateral(), the token transfer to the user is executed before updating the user's deposited collateral balance.

Conceptually, the vulnerable ordering resembles:

This violates the standard secure pattern:

1. Validate

2. Update state

3. Interact externally

Instead, the contract:

1. Interacts externally

2. Updates state

If token_collateral_address is a malicious ERC20, it can:

• Reenter protocol functions

• Trigger additional redemptions

• Manipulate mint/burn flows

• Exploit stale accounting data

Because internal balances are not yet updated at the moment of transfer, the protocol state does not reflect the pending deduction.

As a result:

• State may become inconsistent

• Reentrancy protection assumptions may be broken

• Collateral accounting can be corrupted

• Health factor checks may operate on stale values

Risk

Likelihood: Medium

• Reason 1 External token calls are fully attacker controlled if a malicious collateral token is

• Reason 2 The transfer is executed before balance deduction.

• Reason 3 No explicit reentrancy guard is enforced at this interaction boundary.

Impact:

• Impact 1 Reentrancy could allow double-withdrawal of collateral.

• Impact 2 Internal accounting could desynchronize from actual token balances.

• Impact 3 Protocol solvency may be compromised if collateral can be extracted beyond tracked limits.

Severity: High

This directly affects core collateral accounting and can enable fund loss if exploited through a malicious token contract.

Proof of Concept

A malicious ERC20 token can override transfer():

Attack flow:

1. Attacker deposits malicious collateral token.

2. Attacker calls redeem_collateral().

3. Protocol transfers token before updating internal balance.

4. Malicious token reenters redeem_collateral().

5. Internal balance still shows full amount.

6. Double withdrawal becomes possible.

Expected behavior: Internal accounting updated before external call.
Actual behavior: External call happens before state mutation.

Recommended Mitigation

1.Reorder Operations

Update internal accounting before making the external transfer:

This ensures reentrancy cannot observe stale balances.

2.Add Reentrancy Guard (Defense-in-Depth)

Introduce a reentrancy lock for external entrypoints interacting with tokens:

deposit_collateral

redeem_collateral

liquidate

3.Enforce Strict Collateral Whitelisting

Ensure only trusted ERC20 tokens can be used as collateral:

4.Follow Secure Design Principle

All external state-changing functions must strictly follow:

Validate

Effects

Interactions

Never perform token transfers before updating protocol accounting.

Conclusion

The protocol executes external token transfers before updating internal state, introducing a reentrancy and inconsistent accounting vulnerability.

If exploited via a malicious collateral token, this can result in double withdrawals and protocol insolvency.

Reordering state updates before external interactions eliminates the vulnerability and restores protocol integrity.