[HIGH] Delegatecall-exposed functions use `msg.sender` instead of `_msgSender()`, allowing relayers to receive funds or control flows when executing signed calls

[cygent-dev]

Security Finding

Field	Value
Severity	HIGH
Category	signature
Repository	1inch/solidity-utils
Confidence	50%

Description

The vulnerability is a signature/access-control mismatch caused by inconsistent sender semantics when executing signed delegatecalls. The BySig mixin enables EIP-712-signed calldata to be executed via delegatecall on behalf of an off-chain signer. It arranges this by pushing the signer address onto an internal _msgSenders stack and overriding _msgSender() so contract code that calls _msgSender() observes the signer as the effective caller during the delegatecall. This design requires all internal authorization and recipient logic to use _msgSender() rather than the raw msg.sender.

[Truncated - see PR for full details]

Location

• BySig.sol:L120-L129 in bySig (BySig)
• BySig.sol:L192-L201 in _msgSender (BySig)
• Rescuable.sol:L24-L29 in rescueFunds (Rescuable)
• UniERC20.sol:L59-L74 in uniTransfer (UniERC20 (library))

Impact

An attacker-relayer can drain funds by relaying signed calls: funds intended to be managed by the signer (owner) can be redirected to the relayer. Contracts combining BySig with functions that use msg.sender as recipient or critical identity are at risk. A single signed call can move arbitrary token/ETH amounts permitted by the function.

Recommendation

Replace all uses of msg.sender in functions that may be invoked via delegatecall under BySig with the mixin-aware _msgSender() and audit other modules for raw msg.sender usage. Ensure functions that transfer or charge parties receive an explicit recipient parameter or use _msgSender() consistently.

Apply the following minimal code change to Rescuable::rescueFunds:

[Truncated - see PR for full details]

---

Created by CARA Security Audit via Cygent