stake.link

Summary

There are some access control risks in _transfer related to relying on msg.sender.

Vulnerability Details

In the _transfer function on line 460 of SDLPool.sol, there is a check that the _from address passed in matches the owner of the lock ID being transferred: SDLPool.sol#Line 460

However, this assumes that _from cannot be spoofed or manipulated by the caller. The function relies on trusting msg.sender to have validated and passed in the correct _from address.

This introduces an access control risk because the msg.sender could actually specify any address for _from when calling _transfer. For example:

Here eve is able to initiate and approve an arbitrary transfer from alice to bob by directly specifying alice as _from.

Impact

This would allow an attacker to drain SDL rewards, erase staking lock history, and manipulate balances of arbitrary users without needing approval.

For example, an attacker could pass a victim address in _from and their own address as _to in consecutive calls. This would effectively steal the victim's funds and lock history.

The root cause stems from trusting input parameters passed by the msg.sender without properly validating access rights.

This can be triggered whenever _transfer is called, which happens on all transfer and transferFrom calls including CCIP incoming/outgoing reSDL transfers.

Tools Used

Vs

Recommendations

I would suggest using a modifier like onlyCCIPController for added protection.

• Add an access control modifier that checks _from matches msg.sender on transfers

• Use a proxy contract pattern and perform access validation in the proxy instead