> For the complete documentation index, see [llms.txt](https://etherfi.gitbook.io/etherfi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://etherfi.gitbook.io/etherfi/security/security-and-risks/incident-management/sep-11-incident-legacy-atomicqueue-exploit.md). # Sep 11: Incident - legacy AtomicQueue exploit (Veda) On September 11, 2026, an attacker exploited a missing authorization check in the legacy Veda AtomicQueue contract, a withdrawal helper that Liquid vaults stopped using roughly a year ago. The contract let the caller name any wallet as the paying party of a settlement without that wallet's consent. Wallets that still held an old ERC-20 approval to the contract, and whose wallet software accepted an unexpected callback, had liquidETH, USDC and other Liquid tokens transferred out. **No vault, treasury or protocol-held assets were affected.** Realized user loss was approximately $40K on Ethereum across a small number of wallets, plus approximately 2,257 sETHFI on Arbitrum. All affected users are being reimbursed in full. **Who was exposed:** A wallet was only at risk if all four conditions were true at the same time: | Condition | Who | | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | Holds a Liquid token such as liquidETH | Any Liquid user | | Still has an old approval to the legacy queue (`0xd45884b592e316eb816199615a95c182f75dea07`) | Used the old asynchronous withdrawal flow and never revoked | | Smart wallet whose code accepts unknown calls | Coinbase Smart Wallet, Ambire, and their EIP-7702 delegated forms | | Token not yet on the vault's operator denylist | Everyone, until each token was blocked on Sep 11 | Standard wallets with no contract code, Gnosis Safe and ether.fi Cash accounts were not exploitable through this path, even with an old approval. Base deployments use a different queue with an off switch and were not affected. **How the exploit worked:** 1. The attacker deployed a worthless token and created valid queue requests offering it in exchange for liquidETH at an arbitrary price. 2. They called the queue's `solve()` function, naming an unrelated holder as the "solver". The solver is both the callback recipient and the account that pays. 3. The queue transferred the worthless token to the holder and called `finishSolve` on their wallet. Wallets with no code fail this call, so the transaction reverts and nothing is taken. Coinbase Smart Wallet and Ambire accept the call without a signature. 4. Because the callback succeeded, the queue executed `transferFrom` against the holder's old approval and sent their liquidETH to the attacker's request address. The victim signs nothing and no key is compromised. The flaw is an access-control gap: `solve()` never checks that the paying account agreed to the settlement. It is not a reentrancy issue and does not require the victim to have an open request. **Core vaults were not integrated with this contract.** Our active Liquid vaults moved off the AtomicQueue roughly a year ago. We made that move deliberately: the queue's model required users to approve a contract and then wait several days for a withdrawal to settle, and we did not like the security implications of open approvals sitting against a permissionless contract for that long. At the time of the incident, the only vaults still wired to the queue were deprecated vaults with no TVL. The exposure came from approvals that users had granted in the past and never revoked, not from any live vault integration. The contract was deployed roughly 2.5 years ago as a permissionless helper. It has no owner, no pause and no upgrade path, so it cannot be patched or switched off. Liquid vaults can pause deposits and new withdrawals but not token transfers. The available controls were per-token operator denylists on each vault's transfer hook, and user allowance revocation. **Timeline (UTC):** * **07:20:11** — First exploit transaction, block 25,952,624. 14.4455 liquidETH from 9 wallets and 7.05 USDC from 2 wallets. The attacker swapped the proceeds for 15.4536 ETH. Our monitoring partner Hypernative detected the transaction and raised an automated alert in the same minute. * **07:51** — First public report of the exploit by a third-party security firm. * **07:54** — Copycat transactions began using the same mechanism against other Liquid tokens. * **09:30** — Internal incident declared. Response call opened with Veda and Hypernative. Fork simulation confirmed that denying the queue as an operator reverts the exploit path. * **10:29:59** — liquidETH operator denylist executed by the Liquid Safe, block 25,953,571. Exploit path closed for liquidETH. * **10:43** — Public confirmation that the issue was contained and affected users would be reimbursed. * **11:24** — Denylists executed for sETHFI, liquidBTC, weETHs and eUSD on Ethereum, and for sETHFI on Arbitrum. liquidUSD exposure handled per address. A legacy Plume approval revoked. * **13:20** — No new exploit activity for three hours. Incident marked stable. Cleanup and verification continued. **Response and mitigation:** * **Operator denylists.** Each affected Liquid vault's transfer hook now denies the legacy queue as an operator. This blocks queue-initiated transfers of that token, including legitimate settlements through the old queue. Current withdrawals do not use this contract. * **liquidUSD.** Its hook supports per-address denial only. Exposed addresses were individually restricted and contacted. The largest exposed holder revoked their approval the same day. * **eBTC.** Mitigation was queued behind the vault's 5-day timelock and executes on September 16. * **Legacy sweep.** Every deprecated vault, queue deployment and approval surface across chains is being inventoried, and any frontend path that still creates requests on the legacy queue is being removed. * **Successor design.** Any replacement settlement contract must bind the paying account's explicit authorization to the specific settlement. Callback success is not consent. **What users should do:** If you ever used Liquid withdrawals before the current flow, check your wallet for an approval to `0xd45884b592e316eb816199615a95c182f75dea07` on Ethereum (and the Arbitrum AtomicQueue) using [revoke.cash](https://revoke.cash) or your wallet's approvals view, and revoke it. Operator denylists protect specific tokens, not your allowance. Revoking does not affect your vault position. Affected wallets do not need to file a claim; reimbursement transactions will be published when reconciliation is complete. **Transactions and addresses:** | Item | Reference | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Legacy AtomicQueue (Ethereum) | [`0xd45884b592e316eb816199615a95c182f75dea07`](https://etherscan.io/address/0xd45884b592e316eb816199615a95c182f75dea07#code) | | Vulnerable function | `solve(address,address,address[],bytes,address)`, selector `0xd93fc203` | | Original exploit tx, 07:20:11 | [`0x7cbe0b43…5599b`](https://etherscan.io/tx/0x7cbe0b4349513fed6d03ba8bf9ed708e10e07a501d10b5f344a25ae10595599b) | | Attacker sender | [`0xa5cc6e490bce9185fa47b421f2eac677a83b64ea`](https://etherscan.io/address/0xa5cc6e490bce9185fa47b421f2eac677a83b64ea) | | Copycat tx, 09:09:59 | [`0xccfadbb8…e1f4`](https://etherscan.io/tx/0xccfadbb8090ceab24afd9ab7b33a6245131a3dae03264332eaf978dc577fe1f4) | | liquidETH denylist mitigation, 10:29:59 | [`0x7c4dc551…5717`](https://etherscan.io/tx/0x7c4dc551d60828bd44e5b7dbfadfc5b689c7846517887d8187c3703787935717) | | liquidETH transfer hook | [`0x9aa79c84b79816ab920bbce20f8f74557b514734`](https://etherscan.io/address/0x9aa79c84b79816ab920bbce20f8f74557b514734) | | Liquid Safe | [`0xcea8039076e35a825854c5c2f85659430b06ec96`](https://etherscan.io/address/0xcea8039076e35a825854c5c2f85659430b06ec96) | Arbitrum transaction hashes and reimbursement transactions will be added when reconciliation is complete. Thank you to Veda for building and signing the mitigations, to [Hypernative](https://www.hypernative.io/) for detection and analysis, and to [SlowMist](https://x.com/SlowMist_Team/status/2098344499923784048) and [ExVul](https://x.com/exvulsec/status/2098318467556692298) for fast, accurate public reporting. We're glad to report that no vault or protocol funds were lost, the exploit path was closed the same day, and every affected user will be made whole. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://etherfi.gitbook.io/etherfi/security/security-and-risks/incident-management/sep-11-incident-legacy-atomicqueue-exploit.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.