There is a theoretical-gaming vulnerability in the project. Currently, users are able to set up a graph in which money should flow from one vertex to another. The user sets the split configuration on their account and there is a public function DripsHub.split() that must be called by someone in order for the money to flow to other users.
The users interested in calling DripsHub.split() are the ones who the splits are intended for. But currently, there is not enough money on the target account, so it is not profitable for the splitters to call this function as all the money will be consumed by gas.
And when there is a lot of money accumulating on the target account, the owner of the account has a motivation not to give the money and just change the split configuration to an empty array and take all the accumulated money for himself.
This creates a paradox.
To solve the problem, it is necessary for all the accumulated money, originally intended for the splitters, to be transferred to them before the configuration change.
Recommended Mitigation Steps
The Splits._setSplits() function should also accept the current split receivers configuration as an argument and call the Splits._split() function with it.
Lines of code
https://github.com/code-423n4/2023-01-drips/blob/9fd776b50f4be23ca038b1d0426e63a69c7a511d/src/Splits.sol#L212
Vulnerability details
Impact
There is a theoretical-gaming vulnerability in the project. Currently, users are able to set up a graph in which money should flow from one vertex to another. The user sets the split configuration on their account and there is a public function
DripsHub.split()
that must be called by someone in order for the money to flow to other users.The users interested in calling
DripsHub.split()
are the ones who the splits are intended for. But currently, there is not enough money on the target account, so it is not profitable for the splitters to call this function as all the money will be consumed by gas.And when there is a lot of money accumulating on the target account, the owner of the account has a motivation not to give the money and just change the split configuration to an empty array and take all the accumulated money for himself.
This creates a paradox.
To solve the problem, it is necessary for all the accumulated money, originally intended for the splitters, to be transferred to them before the configuration change.
Recommended Mitigation Steps
The
Splits._setSplits()
function should also accept the current split receivers configuration as an argument and call theSplits._split()
function with it.