Essentially, the user calls the constructor from the Pot contract via the ContestManager contract and the createContest
function to create a contest. The problem is that in the Pot contract, the owner is initialized as msg.sender
. Since the constructor from the Pot contract is called this way, msg.sender
is not the user creating the contest, but rather the ContestManager contract.
Place the following test in the test/TestMyCut.s.sol file:
The test does the following:
The user starts a prank session to simulate a user's actions.
The user calls the createContest function on the ContestManager contract, which in turn calls the Pot contract's constructor.
The test then checks the owner of the Pot contract and asserts that it is not the user, but rather the ContestManager contract.
The issue lies in the Pot contract's constructor, where the owner is initialized as msg.sender
. Since the Pot contract's constructor is called from the ContestManager contract, msg.sender
is the ContestManager contract, not the user who is creating the contest.
The owner of the Pot contract is not the user who created the contest, but the ContestManager contract. This could lead to the not intended behavior.
Manual Code Review, Foundry Test
The recommended mitigation is to pass the user's address as a parameter to the Pot contract's constructor, instead of using msg.sender
to initialize the owner. This way, the user who creates the contest will be the owner of the Pot contract, as expected.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.