CVE-2026-53924 in Gardens
Summary
by MITRE • 09/03/2026
Gardens v2 is a modular governance framework that enables communities to create and manage multiple governance pools with customizable parameters and voting mechanisms. Prior to 0xc9d4e0dacd937364793278180551e59d93cd43f9, StreamingEscrow.claim() correctly rejects withdrawals while an escrow is disputed, but the permissionless syncOutflow() path performs the same excess-balance transfer without checking disputed. After a streaming proposal is challenged, anyone can call syncOutflow() to transfer escrowed SuperTokens to the proposal beneficiary while the dispute is pending. If the proposal is later rejected, those tokens cannot be recovered by drainToStrategy(). This issue has been patched in 0xc9d4e0dacd937364793278180551e59d93cd43f9.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The Gardens v2 governance framework operates as a modular system designed to allow communities to establish and manage multiple governance pools with customizable parameters and voting mechanisms. Within this architecture, the StreamingEscrow contract plays a critical role in managing token distributions over time, ensuring that funds are released according to predefined schedules while maintaining security against unauthorized or premature withdrawals. A significant logical flaw was identified in the interaction between dispute handling mechanisms and specific utility functions within the smart contract codebase, specifically affecting the integrity of escrowed assets during active governance disputes.
The core technical vulnerability stems from an inconsistency in how different entry points handle disputed states. The StreamingEscrow.claim() function correctly implements a check to reject withdrawals if an associated escrow is currently under dispute, thereby preserving the status quo until the resolution process concludes. However, the permissionless syncOutflow() path fails to perform this same validation check for the disputed state. This oversight creates a critical gap in access control logic where the contract allows external actors to bypass the intended restrictions on fund movement during active disputes.
The operational impact of this vulnerability is severe and directly affects financial security within the governance ecosystem. Once a streaming proposal enters a challenged or disputed state, any third party can invoke syncOutflow() to transfer escrowed SuperTokens to the designated beneficiary of that proposal. This action occurs while the dispute is still pending, effectively draining assets before their legitimacy has been confirmed by the community vote. If the subsequent governance decision results in the rejection of the proposal, the tokens transferred via this exploit cannot be recovered through standard recovery mechanisms like drainToStrategy(), leading to permanent loss or misallocation of funds that were intended for other purposes or held in reserve.
This issue represents a classic case of inconsistent state validation across multiple functions within a single contract module. It aligns with CWE-20 Improper Input Validation, as the system failed to adequately validate the dispute status before allowing asset transfers through an alternative code path. Furthermore, from a threat modeling perspective using MITRE ATT&CK for ICS or general cyber frameworks, this vulnerability facilitates unauthorized financial transactions and can be categorized under techniques related to resource hijacking or improper access control exploitation in decentralized systems. The attacker does not need privileged keys but rather exploits the public interface of the contract to manipulate fund flows during a period of uncertainty.
The vulnerability has been addressed in commit 0xc9d4e0dacd937364793278180551e59d93cd43f9, which likely involves adding the necessary dispute state checks to the syncOutflow() function to ensure parity with the claim() logic. For organizations utilizing this framework or similar modular governance structures, it is imperative to conduct thorough code audits focusing on edge cases in multi-path functions. Developers should implement consistent validation layers across all entry points that interact with sensitive assets, ensuring that security constraints such as dispute locks are enforced uniformly regardless of the function invoked. Regular testing against state-transition scenarios involving disputes and rejections is essential to prevent similar logical flaws from impacting asset safety.