Description

Gardens v2 is a modular governance framework that enables communities to create and manage multiple governance pools with customizable parameters and voting mechanisms. In 3e595f3 and prior, when a streaming proposal is funded, the cluster of streaming contracts moves real pool funds into the proposal's StreamingEscrow to back the Superfluid constant flow agreement (the CFA deposit, plus a 0.5 percent margin). cancelProposal then zeroes the escrow's GDA member units but never reclaims that parked balance, and the permissionless claim() forwards the escrow's entire balance, including the pool funded buffer, to the beneficiary. The beneficiary is chosen by the proposal submitter and defaults to the submitter. The only path that returns escrow funds to the pool is drainToStrategy, which is onlyStrategy and is reached solely from the dispute reject ruling, never from cancel or natural completion. At time of publication, there are no publicly known patches.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-03T16:17:26.250Z",
  "pubdate": "2026-09-03T16:17:26.250Z",
  "executiveSummary": "The vulnerability in Gardens v2 (commit 3e595f3 and prior) involves a critical flaw in the handling of streaming proposal funds within the StreamingEscrow contract.\nSpecifically, the protocol fails to reclaim pool funds parked in the StreamingEscrow upon proposal cancellation or completion.\nThis vulnerability is classified as an improper asset management and unauthorized fund withdrawal issue. An attacker can exploit this logic error to permanently drain funds from the governance pool.\nImpact includes a total loss of locked collateral designated for streaming agreements. Any user can trigger the permissionless claim() function, allowing an attacker to divert the pool's buffered funds—including the CFA deposit and a 0.5 percent margin—to an arbitrary beneficiary address.\nThe risk is critical, as there is currently no mechanism within the standard proposal lifecycle (cancel or completion) to return these assets to the pool treasury. Only a specific dispute reject ruling triggers the authorized drainToStrategy function, leaving the system highly vulnerable during normal operation.",
  "technicalDetails": "The vulnerability originates in the architectural handling of funds within the StreamingEscrow contract during the lifecycle of a streaming proposal. When a streaming proposal is funded, the system moves real pool funds into the StreamingEscrow to facilitate the Superfluid constant flow agreement (CFA), including a 0.5 percent margin buffer. The root cause is the failure of the cancelProposal function to reconcile these parked funds when a proposal is aborted.\nWhile cancelProposal successfully updates the escrow's GDA (General Distribution Agreement) member units to zero, it neglects to perform a transfer of the remaining underlying assets back to the governance pool. Consequently, these funds remain trapped in the StreamingEscrow contract balance but are disassociated from the proposal's active state.\nExploitation is made possible through the permissionless claim() function. This function is designed to forward the entire balance of the StreamingEscrow to a designated beneficiary. Because the system does not differentiate between the authorized streaming amount and the redundant pool-funded buffer, the claim() function indiscriminately sweeps all locked assets into the beneficiary account.\nAn attacker can exploit this via the following flow: 1) Initiate or wait for a streaming proposal to reach a state where it is either cancelled or naturally concludes without triggering a dispute. 2) Identify that the pool-funded buffer remains in the StreamingEscrow because the contract lacks a cleanup logic to return those funds to the main treasury. 3) Invoke the permissionless claim() function, providing an address controlled by the attacker as the beneficiary. 4) The contract executes the transfer, sending both the intended claim and the orphaned buffer funds to the attacker. Since the beneficiary is chosen by the proposal submitter and defaults to the submitter, the attacker can guarantee receipt of funds.\nThe vulnerability is exacerbated by the fact that the only remediation path, drainToStrategy, is protected by an onlyStrategy modifier and is accessible only through a dispute reject ruling. Under normal operating conditions, this function is unreachable, meaning there is no programmatic method to recover these funds once they have been parked in the escrow. This results in the complete loss of collateralized pool funds, impacting the protocol's liquidity and economic security."
}