Summary
A missing independent authorization check in MultiversX's multisig reference implementation allows an account with only the Proposer role to execute actions that should require additional approval.
An attacker with proposer privileges may move the contract's EGLD or ESDT funds alone, potentially draining the entire balance through a small number of transactions without collecting the required signatures.
A missing independent authorization check in MultiversX's multisig reference implementation allows an account with only the Proposer role to execute actions that should require additional approval.
An attacker with proposer privileges may move the contract's EGLD or ESDT funds alone, potentially draining the entire balance through a small number of transactions without collecting the required signatures.
Affected context
The vulnerability occurs in the on-chain multisig smart contract logic when role-based permissions are used to distinguish proposers from authorized signers. It becomes risky where sensitive operations are accepted after checking proposer access but without independently verifying the required multisignature threshold or action-specific authorization.
The vulnerability occurs in the on-chain multisig smart contract logic when role-based permissions are used to distinguish proposers from authorized signers. It becomes risky where sensitive operations are accepted after checking proposer access but without independently verifying the required multisignature threshold or action-specific authorization.
Exploit preconditions
- Attack surface: Public smart contract endpoints that propose, approve, or execute multisig actions
- Required access: An account holding the Proposer role, or control of such an account
- Trigger point: Execution of a fund-transfer or otherwise restricted multisig action
- Why exploitation is possible: The execution path does not independently enforce the authorization requirement for barred actions, allowing proposer access to substitute for the required signatures
- Attack surface: Public smart contract endpoints that propose, approve, or execute multisig actions
- Required access: An account holding the Proposer role, or control of such an account
- Trigger point: Execution of a fund-transfer or otherwise restricted multisig action
- Why exploitation is possible: The execution path does not independently enforce the authorization requirement for barred actions, allowing proposer access to substitute for the required signatures
Why this happens
The underlying bug is an incomplete authorization model in which role possession is treated as sufficient for operations that require separate signer approval.
This maps primarily to CWE-862: Missing Authorization because the contract fails to enforce an authorization check for a protected action. It is also related to CWE-863: Incorrect Authorization, since the implemented role-to-operation relationship permits a proposer to perform actions outside the intended permission boundary.
The underlying bug is an incomplete authorization model in which role possession is treated as sufficient for operations that require separate signer approval.
This maps primarily to CWE-862: Missing Authorization because the contract fails to enforce an authorization check for a protected action. It is also related to CWE-863: Incorrect Authorization, since the implemented role-to-operation relationship permits a proposer to perform actions outside the intended permission boundary.
Potential impact
- An unauthorized proposer may transfer EGLD or ESDT assets
- The contract balance could be partially or completely drained
- Legitimate multisignature governance controls may be bypassed
- Users and organizations relying on the contract could suffer permanent financial loss
- Trust in dependent applications or token-management workflows may be reduced
- An unauthorized proposer may transfer EGLD or ESDT assets
- The contract balance could be partially or completely drained
- Legitimate multisignature governance controls may be bypassed
- Users and organizations relying on the contract could suffer permanent financial loss
- Trust in dependent applications or token-management workflows may be reduced
General mitigation guidance
Mitigation generally focuses on making authorization checks explicit, independent, and action-specific.
Common defensive patterns include:
- Requiring the configured signer threshold before executing every protected operation
- Separating proposal, approval, and execution permissions
- Applying deny-by-default authorization for transfers and other high-impact actions
- Treating proposer status as insufficient for execution unless the policy explicitly permits it
- Validating authorization state on-chain at the final execution point rather than relying only on earlier workflow steps
- Using least-privilege roles and limiting contract-held balances where practical
- Adding invariant and negative tests covering every prohibited role/action combination
Mitigation generally focuses on making authorization checks explicit, independent, and action-specific.
Common defensive patterns include:
- Requiring the configured signer threshold before executing every protected operation
- Separating proposal, approval, and execution permissions
- Applying deny-by-default authorization for transfers and other high-impact actions
- Treating proposer status as insufficient for execution unless the policy explicitly permits it
- Validating authorization state on-chain at the final execution point rather than relying only on earlier workflow steps
- Using least-privilege roles and limiting contract-held balances where practical
- Adding invariant and negative tests covering every prohibited role/action combination
How teams detect issues like this
Detection can include static and behavioral review of smart contract authorization paths.
Useful approaches include:
- Searching for execution functions that check proposer identity without checking signer count, approval state, or authorization thresholds
- Reviewing every asset-transfer path for an independent authorization decision at execution time
- Flagging role checks that grant broad permissions to proposal-management accounts
- Testing forbidden role/action combinations, including a proposer attempting to execute without signatures
- Monitoring contract events and balance changes for transfers executed with no corresponding approval quorum
- Enforcing policy checks in code review and automated smart contract analysis tools
Detection can include static and behavioral review of smart contract authorization paths.
Useful approaches include:
- Searching for execution functions that check proposer identity without checking signer count, approval state, or authorization thresholds
- Reviewing every asset-transfer path for an independent authorization decision at execution time
- Flagging role checks that grant broad permissions to proposal-management accounts
- Testing forbidden role/action combinations, including a proposer attempting to execute without signatures
- Monitoring contract events and balance changes for transfers executed with no corresponding approval quorum
- Enforcing policy checks in code review and automated smart contract analysis tools
Sources
| Source | Link |
|---|---|
| gist. | gist.github.com/ |
| github. | github.com/ |
