Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
Permanent freezing of funds
Temporary freezing of funds for at least 1 hour
Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)
Description
Brief/Intro
The UnripeFacet.sol contract has a critical reentrancy vulnerability in its function implementations. If exploited, this vulnerability could allow an attacker to repeatedly call certain functions before state changes are committed, potentially leading to the total loss of user funds or causing other severe disruptions.
Vulnerability Details
The UnripeFacet.sol contract utilizes the nonReentrant modifier to guard against reentrancy attacks. However, reentrancy guards are not entirely foolproof. Sophisticated attackers may exploit this vulnerability if reentrant calls occur before state changes are finalized. This issue is critical because it allows attackers to manipulate contract states and potentially withdraw more funds than intended.
Code Example:
function chop(uint256 amount) external nonReentrant {
// Some logic here
externalContract.call{value: amount}(""); // External call
// State change here
}
In the above code, the external call is made before the state changes are committed. An attacker could reenter the chop function and exploit the state before it's updated.
Impact Details
If an attacker successfully exploits this reentrancy vulnerability, they could drain user funds or manipulate contract states, leading to a total loss of funds or unintended behaviors in the contract. Given the critical nature of this issue, it is classified as a Critical severity impact.
We have reviewed your submission, but unfortunately, we are closing the report for the following reasons:
The submission contains the output of an automated scanner without demonstrating that it is a valid issue.
The submission lacks the required information regarding the vulnerability's impact on the reported asset.
As per the bug bounty program's policy, we require all submissions to be accompanied by a Proof of Concept (PoC) that demonstrates the vulnerability's existence and impact. Since the submission doesn't provide any proof of the vulnerability's existence, we have decided to close it.
Please note that the project will receive a report of the closed submission and may choose to re-open it, but they are not obligated to do so.