Rust Fund

AI First Flight #9
Beginner FriendlyRust
EXP
View results
Submission Details
Severity: high
Valid

refund has no goal-not-met check — contributors can drain a successful campaign

Root + Impact

The refund function only verifies that the deadline has passed. It does not
check whether the campaign actually failed. A contributor can request a refund
from a fully-funded, successful campaign — draining the creator's withdrawable
balance after the deadline expires.

Description

Refunds are only supposed to be available when a campaign fails to reach its
goal by the deadline. The deadline check is present but the goal check is
completely absent:

pub fn refund(ctx: Context<FundRefund>) -> Result<()> {
let amount = ctx.accounts.contribution.amount;
// @> only checks deadline — no check that goal was NOT met
if ctx.accounts.fund.deadline != 0 &&
ctx.accounts.fund.deadline > Clock::get()?.unix_timestamp as u64 {
return Err(ErrorCode::DeadlineNotReached.into());
}
// @> executes even when fund.amount_raised >= fund.goal (campaign succeeded)
**ctx.accounts.fund... -= amount
**ctx.accounts.contributor... += amount
ctx.accounts.contribution.amount = 0;
Ok(())
}

Once the deadline passes, every contributor can call refund regardless of
whether the campaign succeeded or failed.

Risk

Likelihood:

  • After a campaign reaches its goal and the deadline passes, every contributor
    can call refund before the creator calls withdraw, draining the fund

  • The window between deadline expiry and creator withdrawal is exploitable on
    every successful campaign — no special setup required

Impact:

  • Successful campaigns can be completely drained by contributors after the
    deadline, leaving the creator with nothing despite meeting the funding goal

  • Breaks the fundamental protocol invariant: goal met → creator gets paid

  • Creates a race condition between creator withdraw and contributor refund
    on every successful campaign

Proof of Concept

The attack is straightforward: wait for a successful campaign to reach its
deadline, then call refund before the creator withdraws. Since there is no
goal check, the refund succeeds even though the campaign met its target.

// 1. Campaign: goal = 10 SOL, deadline = now + 7 days
// 2. Contributors deposit total of 10 SOL — goal met ✓
// 3. Deadline passes
// 4. Before creator calls withdraw, contributor calls refund
refund()
// fund.deadline check passes (deadline has passed) ✓
// goal check → MISSING ✗
// Contributor recovers their SOL
// Creator's withdrawable balance reduced to 0
// Creator calls withdraw → receives 0 SOL despite successful campaign

Recommended Mitigation

A goal-not-met check must be added before the lamport transfer executes.
This ensures refunds are only available when the campaign has actually failed —
i.e., the deadline passed without reaching the funding target.

pub fn refund(ctx: Context<FundRefund>) -> Result<()> {
+ require!(
+ ctx.accounts.fund.amount_raised < ctx.accounts.fund.goal,
+ ErrorCode::GoalAlreadyMet
+ );
let amount = ctx.accounts.contribution.amount;

Also add the new error variant:

+ #[msg("Campaign goal already met, refunds are not available")]
+ GoalAlreadyMet,
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 9 hours ago
Submission Judgement Published
Validated
Assigned finding tags:

[H-04] Inadequate Refund Conditions

## Description the refund mechanism only verifies that the current time has passed the campaign deadline, without checking whether the campaign has failed to meet its funding goal.This oversight may result in refunds being issued even if the campaign was, in principle, successful, potentially undermining the trust and financial integrity of the platform. &#x20; ## Vulnerability Details The refund function in the contract is designed to return funds to contributors if a campaign fails. However, it only checks whether the campaign deadline has been reached (or passed) before allowing a refund, without verifying if the campaign's funding goal was met. In other words, the function solely relies on a time-based condition and does not incorporate the additional logic required to determine if a campaign has been unsuccessful. **Code Analysis:**\ The refund function contains the following check: ```Rust if ctx.accounts.fund.deadline != 0 && ctx.accounts.fund.deadline > Clock::get().unwrap().unix_timestamp.try_into().unwrap() { return Err(ErrorCode::DeadlineNotReached.into()); } ``` This condition ensures that refunds are only triggered after the deadline has passed. However, there is no subsequent verification that compares `fund.amount_raised` to the `fund.goal` to determine whether the campaign failed to meet its funding target. As a result, even if the campaign has met or exceeded its goal, contributors could potentially request refunds simply because the deadline has passed. ## proof Of Concept ```typescript it("Allows refund on a successful campaign due to missing goal check", async () => { // Define campaign parameters with a near-future deadline (5 seconds from now) const fundName = "refund flaw"; const description = "Test for refund vulnerability on a successful campaign"; const goal = new anchor.BN(1000000000); // 1 SOL goal // Set deadline to 5 seconds from now const deadline = new anchor.BN(Math.floor(Date.now() / 1000) + 5); // Generate PDA for the fund using the campaign name and creator's public key let [fundPDA, fundBump] = await PublicKey.findProgramAddress( [Buffer.from(fundName), creator.publicKey.toBuffer()], program.programId ); // Create the fund campaign await program.methods .fundCreate(fundName, description, goal) .accounts({ fund: fundPDA, creator: creator.publicKey, systemProgram: anchor.web3.SystemProgram.programId, }) .rpc(); // Set the campaign deadline await program.methods .setDeadline(deadline) .accounts({ fund: fundPDA, creator: creator.publicKey, }) .rpc(); // Airdrop lamports to otherUser so they can contribute const airdropSig = await provider.connection.requestAirdrop( otherUser.publicKey, 2 * anchor.web3.LAMPORTS_PER_SOL // e.g., 2 SOL ); await provider.connection.confirmTransaction(airdropSig); // Generate PDA for the contribution account using fund's PDA and otherUser's public key let [contributionPDA, contributionBump] = await PublicKey.findProgramAddress( [fundPDA.toBuffer(), otherUser.publicKey.toBuffer()], program.programId ); // otherUser contributes 1 SOL, meeting the campaign goal const contributionAmount = new anchor.BN(1000000000); // 1 SOL await program.methods .contribute(contributionAmount) .accounts({ fund: fundPDA, contributor: otherUser.publicKey, contribution: contributionPDA, systemProgram: anchor.web3.SystemProgram.programId, }) .signers([otherUser]) .rpc(); // Verify the campaign is successful by checking that amountRaised >= goal let fundBeforeDeadline = await program.account.fund.fetch(fundPDA); expect(fundBeforeDeadline.amountRaised.gte(goal)).to.be.true; // Wait until after the deadline has passed await new Promise((resolve) => setTimeout(resolve, 6000)); // otherUser calls refund despite the campaign being successful // (a correct implementation should disallow this refund) let refundTxSucceeded = true; try { await program.methods .refund() .accounts({ fund: fundPDA, contribution: contributionPDA, contributor: otherUser.publicKey, systemProgram: anchor.web3.SystemProgram.programId, }) .signers([otherUser]) .rpc(); } catch (err) { refundTxSucceeded = false; } // The vulnerability: refund call is erroneously allowed even though the campaign met its goal. expect(refundTxSucceeded).to.be.true; // check the contributor's balance change to further demonstrate the refund was processed. const balanceAfterRefund = await provider.connection.getBalance( otherUser.publicKey ); console.log("Contributor balance after refund:", balanceAfterRefund); }); ``` ## Impact - **Financial Discrepancies:**\ The improper refund mechanism result in successful campaigns losing funds that were meant to be retained by the campaign creator, leading to financial imbalances within the contract. - **Erosion of Trust:**\ Contributors and creators rely on the refund logic to be fair and accurate. The absence of a funding goal check in the refund function erode trust in the platform, as users could experience unexpected fund reversals or disputes over campaign success. - **Operational Risks:**\ Campaigns that meet their funding goals still be subject to refund requests, creating operational inefficiencies and potential disputes between creators and contributors. This undermines the intended crowdfunding model and could deter future participation. &#x20; ## Recommendations Update the refund function to include a check that verifies whether the campaign's funding goal has been met. Refunds should only be processed if both the deadline has passed and the `amount_raised` is below the `goal`.&#x20; &#x20; ```Solidity if ctx.accounts.fund.deadline != 0 && ctx.accounts.fund.deadline > Clock::get().unwrap().unix_timestamp.try_into().unwrap() { return Err(ErrorCode::DeadlineNotReached.into()); } if ctx.accounts.fund.amount_raised >= ctx.accounts.fund.goal { return Err(ErrorCode::CampaignSuccessful.into()); } ```

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!