# #47091 \[SC-Insight] \`setWorkAddress()\` enables front-running attacks to hijack work addresses **Submitted on Jun 8th 2025 at 21:28:27 UTC by @danvinci\_20 for** [**Audit Comp | Flare | FAssets**](https://immunefi.com/audit-competition/audit-comp-flare-fassets) * **Report ID:** #47091 * **Report Type:** Smart Contract * **Report severity:** Insight * **Target:** * **Impacts:** * Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol) ## Description ## Description The AgentOwnerRegistry contract implements a `setWorkAddress()` function that allows an agent to designate a secondary "work" address associated with their management address. However, the current implementation does not sufficiently validate ownership or authority over the work address, creating a front-running vector that allows malicious agents with no potential risk (active vault) to hijack work addresses before legitimate owners can claim them. This introduces a critical denial-of-service condition and opens up potential for targeted griefing attacks against agents attempting to onboard or reconfigure their setup. ```solidity function setWorkAddress(address _ownerWorkAddress) external { require(isWhitelisted(msg.sender), "agent not whitelisted"); require(_ownerWorkAddress == address(0) || workToMgmtAddress[_ownerWorkAddress] == address(0), "work address in use"); // ... } ``` The function checks that the work address is currently unused, creating a room for hijacking the work address of legitimate agent and preventing them for setting their configuration. ## Impact Details Malicious agent `Alice` can keep frontrunning whitelisted agent `Bob` when she notice `Bob` wants to set work address to specific value. This leads to denial-of-service attack on `Bob` indefinitely. ## Recommendations I think it's better to introduce an off-chain mechanism to oversee the setting of the `workAddress` rather than allowing a specific agent to set up the `workAddress` from their end, this gives a constraint to random and frequent change of the `workAddress`. ## Proof of Concept ## Proof of Concept Consider this straightforward attack scenario: 1. A legitimate agent attempts to register their work address: ``` agent.setWorkAddress(0xLegitimateWorkAddress); ``` 2. A malicious actor monitors the mempool and sees this transaction. 3. The malicious actor quickly front-runs the transaction: ``` attacker.setWorkAddress(0xLegitimateWorkAddress); ``` 4. The original agent’s transaction reverts with "work address in use". This allows the attacker to indefinitely block the legitimate agent from using their desired work address. --- # 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/47091-sc-insight-setworkaddress-enables-front-running-attacks-to-hijack-work-addresses.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.