#47159 [SC-Insight] Lack of Access Control on `triggerInstructions()` Allows Unauthorized Transfers Post-Deletion

Submitted on Jun 9th 2025 at 09:43:25 UTC by @Pig46940 for Audit Comp | Flare | FAssets

  • Report ID: #47159

  • Report Type: Smart Contract

  • Report severity: Insight

  • Target: https://github.com/flare-foundation/fassets/blob/main/contracts/assetManager/implementation/CoreVaultManager.sol

  • Impacts:

    • Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield

    • Theft of unclaimed yield

    • Permanent freezing of funds

    • Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Description

Brief/Intro

The CoreVaultManager contract allows transfers to predefined destination addresses. However, due to insufficient access control logic during triggerInstructions(), later removed allowed addresses from the allowed list—yet still trigger the transfers. User or Agent can send funds to an unauthorized address and possibly vanish the funds.

Vulnerability Details

Root Cause

The function triggerInstructions() does not revalidate whether the destination addresses in queued transfer requests are still present in the allowed destination address list. As a result, once a request is added with an allowed address, it remains executable even if the address is later removed.

Exploit Scenario

  1. A privileged user adds destinationAddress1 and destinationAddress2 to the list of allowed destination addresses.

  2. Transfer requests are created using requestTransferFromCoreVault() for those addresses.

  3. The same user removes the addresses from the allowed list using removeAllowedDestinationAddresses().

  4. The function triggerInstructions() is called by user or agent, and executes the queued transfers to the now unauthorized destination addresses.

This violates the assumption that only currently allowed addresses should ever receive funds, potentially allowing malicious or unintended fund transfers.

Impact Details

Transfers to removed destination addresses are executed, even when such addresses are no longer authorized. This enables:

  • Griefing: Governance can’t cancel transfers even if the destination becomes invalid or compromised.

  • Policy Bypass: Violates destination allowlist enforcement.

  • Loss of Trust: Funds may be irreversibly sent to addresses that are no longer permitted.

References

Proof of Concept

Proof of Concept

Setup and run

PoC code

Was this helpful?