The withdraw function lacks a check for campaign success. The campaign creator is able to call withdraw and retrieve contributed funds even if the funding goal has not been reached. In other words, there is no validation that the campaign met its goal before allowing the creator to take the money. This oversight enables a malicious or impatient creator to steal contributions from a campaign that should have failed (where contributors expected refunds).
Normally, a crowdfunding contract should only allow withdrawal of funds after the campaign is successful (i.e., it raised at least the goal amount by the deadline). In RustFund’s withdraw handler, there is no requirement or condition verifying that fund.amount_raised >= fund.goal. The code likely simply transfers whatever has been raised to the creator, regardless of the goal.
In practice, this means if a campaign only raised, say, 50% of its goal by the deadline, the creator can still withdraw that 50% from the fund account. There is an authorization check that likely ensures only the campaign’s creator can call withdraw (e.g., a has_one = creator constraint or similar), so arbitrary users can’t withdraw. But the creator themselves is not restricted by campaign success.
This is a critical logic flaw. It violates the fundamental guarantee to contributors: if the campaign fails, they should get their money back. Instead, the creator can take all contributed funds from a failed campaign. The impact is effectively a theft of contributor funds under the guise of an unsuccessful campaign. Contributors have no on-chain recourse if this happens, because the contract itself permits it. A malicious campaign creator could exploit this by setting a high goal to attract contributions, then even if they don’t meet the goal, simply withdraw whatever was contributed. Even an honest but desperate creator might be tempted to withdraw funds despite failing, undermining the platform’s integrity. Contributors wouldn’t be able to claim refunds while the creator empties the fund, resulting in a complete loss for contributors. This issue would be classified as High severity because it enables direct and unauthorized loss of user funds.
Comparison of specification requirements with code analysis.
Manual analysis of logical branches in the withdraw function.
Add a check, for example: if fund.amount_raise < fund.goal or if the deadline has not yet arrived, withdrawal of funds should be prohibited.
Define an explicit campaign success condition and update the function logic according to this condition.
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.