ether.fi Liquid / Veda AtomicQueue — Unauthenticated `solver` Drain

Source & credit. Crypto Training original detection and analysis (live Twitter/X security-alert intake — not from DeFiHackLabs). Standalone Foundry PoC, offline anvil_state.json, and full write-up: 2026-09-EtherFiVedaAtomicQueue_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/access-control/missing-auth · vuln/logic/missing-validation · vuln/dependency/unsafe-external-call

Reproduction: Foundry fork replay at Ethereum block 25952623 (one before 0x7cbe0b43…5599b). EtherFiVedaAtomicQueueExploit.attack() mints a worthless ERC20, opens a self-request on the Veda AtomicQueue, and names each prior approver as solver so want.safeTransferFrom pulls their liquidETH (and dust USDC). Offline anvil_state.json + _shared/run_poc.sh [PASS] (output.txt). Alert: @exvulsec.

Key info#

TL;DR#

1. ether.fi Liquid withdrawals on Ethereum share a Veda AtomicQueue (AtomicQueue.sol). Users who want to sell liquidETH (or other vault shares) for a want asset approve the queue and open an AtomicRequest.

2. solve(offer, want, users, runData, solver) is permissionless. The last argument is an unauthenticated address. The queue (a) pulls offer from each listed user to solver, (b) calls IAtomicSolver(solver).finishSolve(...), then (c) pulls want from solver to each user via want.safeTransferFrom (AtomicQueue.sol:230).

3. Step (c) reuses the same allowance users granted so the queue could take their offer tokens. Nothing binds that allowance to "only when I am the request owner". Naming a prior approver as solver spends it as want.

4. finishSolve is a high-level interface call. On this 0.8.21 bytecode an empty-code EOA reverts (extcodesize == 0), but the live victims were EIP-7702 smart accounts / tiny wallets whose unknown-selector path was a no-op. The queue then continues as if a real solver had sourced want.

5. The attacker needed no capital. They minted a worthless ERC20, opened a self-request offering that junk and wanting liquidETH at atomicPrice = 1e18 (1:1 in 18-decimal space), sized offerAmount to each victim's min(balance, allowance), and passed solver = victim. assetsToUser = 1e18 * offerAmount / 1e18 = offerAmount.

6. Eleven approvers were drained in one transaction: 14.445541086626480232 liquidETH from nine holders and 7.047848 USDC from two more (output.txt:9–output.txt:10). The live helper then dumped liquidETH through Uniswap v4 and the USDC dust through Uniswap v3, forwarding 15.45 ETH to the EOA.

Background — what the AtomicQueue is for#

Veda's AtomicQueue is a limit-order style withdrawal helper used by ether.fi Liquid (and other BoringVault deployments). A user who wants to exit vault shares for a stable asset (or the reverse) posts:

struct AtomicRequest {
    uint64 deadline;
    uint88 atomicPrice; // want-token units per 1e{offerDecimals} of offer
    uint96 offerAmount;
    bool inSolve;
}

updateAtomicRequest(offer, want, req) writes userAtomicRequest[msg.sender][offer][want] (AtomicQueue.sol:157-174). It is nonReentrant and otherwise unrestricted — any address may post a request for any token pair.

A "solver" (normally a keeper / AtomicSolverV3 that actually holds the want inventory, or redeems shares through the Teller) is then supposed to:

1. Receive the users' offer tokens.
2. In finishSolve, source want (swap, redeem, P2P) and approve the queue.
3. Let the queue transferFrom that want back to the users at each request's atomicPrice.

The payout math is atomicPrice.mulDivDown(offerAmount, 10 ** offerDecimals) (AtomicQueue.sol:308-314). With an 18-decimal fake offer token and atomicPrice = 1e18, one wei of junk clears one wei of want.

Users approved the queue because that is how a legitimate withdrawal is funded: the queue must be able to transferFrom their liquidETH when they are the user. The bug is that the same spender is also used when they are named as the solver.

The vulnerable code#

Verified source lives at sources/AtomicQueue_d45884/src_modules_atomic-queue_AtomicQueue.sol (compiler v0.8.21, 200 runs, shanghai). This deployment has no Auth / requiresAuth — later Veda revisions gated solve behind a role, which this ether.fi queue never did.

1. solver is a free parameter#

function solve(
    ERC20 offer,
    ERC20 want,
    address[] calldata users,
    bytes calldata runData,
    address solver
) external nonReentrant {
    uint8 offerDecimals = offer.decimals();
    uint256 assetsToOffer;
    uint256 assetsForWant;
    for (uint256 i; i < users.length; ++i) {
        AtomicRequest storage request = userAtomicRequest[users[i]][offer][want];
        // deadline / zero-amount / duplicate checks only…
        assetsForWant += _calculateAssetAmount(request.offerAmount, request.atomicPrice, offerDecimals);
        assetsToOffer += request.offerAmount;
        request.inSolve = true;
        offer.safeTransferFrom(users[i], solver, request.offerAmount);
    }

    IAtomicSolver(solver).finishSolve(runData, msg.sender, offer, want, assetsToOffer, assetsForWant);

    for (uint256 i; i < users.length; ++i) {
        AtomicRequest storage request = userAtomicRequest[users[i]][offer][want];
        if (request.inSolve) {
            uint256 assetsToUser = _calculateAssetAmount(request.offerAmount, request.atomicPrice, offerDecimals);
            want.safeTransferFrom(solver, users[i], assetsToUser);
            // …zero the request…
        }
    }
}

(AtomicQueue.sol:190-246)

There is no:

• msg.sender == solver (or solver whitelist / QUEUE_ROLE)
• check that solver approved this particular fill
• check that want is the asset the named solver intended to sell
• check that solver even consented to being a solver

The comment above the function says solvers are "required to approve this contract to spend enough of want assets" — that is an assumption, not an invariant. Any prior approve(queue, type(uint256).max) satisfies it.

2. finishSolve does not have to pay#

IAtomicSolver(solver).finishSolve(runData, msg.sender, offer, want, assetsToOffer, assetsForWant);

(AtomicQueue.sol:219, interface at IAtomicSolver.sol)

A real AtomicSolverV3 would swap/redeem here and approve want. A wallet whose fallback / 7702 target does not revert on an unknown selector just returns. The queue then transferFroms want anyway.

Solc 0.8.21 inserts an extcodesize check on that high-level call, so a pure EOA would revert. The eleven live victims were 7702-delegated accounts or small proxies; the unknown selector was a no-op (gas 0, [Stop] in the PoC, output.txt:114). The teaching PoC vm.etches a single STOP byte to reproduce that callback. Accounting is unchanged: transferFrom still pulls from the victim address.

3. Payout size is attacker-controlled#

function _calculateAssetAmount(uint256 offerAmount, uint256 atomicPrice, uint8 offerDecimals)
    internal pure returns (uint256)
{
    return atomicPrice.mulDivDown(offerAmount, 10 ** offerDecimals);
}

The attacker is the request user, so they pick both offerAmount and atomicPrice. Setting atomicPrice = 1e18 and offerAmount = stealable makes assetsToUser = stealable — exactly min(victim.balance, victim.allowance) capped at uint96.

Root cause#

Secondary analysis (@SlowMist_Team)#

Missing auth on AtomicQueue.solve(solver): attacker-chosen solver plus leftover ERC-20 allowance lets transferFrom drain prior approvers after a no-op finishSolve

Source: https://x.com/SlowMist_Team/status/2098344499923784048

The queue treats "address that will be transferFrom'd for want" as a caller-supplied solver role, but the only access control on that role is "does this address currently have an ERC-20 allowance to the queue?". Users granted that allowance for a different role (request owner offering liquidETH). There is no binding between (user, offer, want) and the solver that is allowed to source want, and finishSolve is not required to move value.

Later Veda code (AtomicSolverV5, requiresAuth on solve) is a tacit admission: a rogue queue + unauthenticated solver is a known drain. This ether.fi deployment is the original ungated AtomicQueue.

Preconditions#

1. Victims previously approve'd AtomicQueue (0xD458…ea07) to spend liquidETH and/or USDC — the normal UX for posting a withdrawal request.
2. solve and updateAtomicRequest are callable by anyone (no Auth).
3. isPaused is false.
4. The named solver has some code whose finishSolve / fallback does not revert (7702 delegation, proxy, or, in the PoC, STOP).
5. The attacker can mint an ERC-20 they fully control (no market, no value).
6. Victim min(balance, allowance) > 0 and fits in uint96.

No flash loan, no oracle, no governance. The live attacker EOA was nonce 0.

Attack walkthrough#

Fork block 25,952,623. The PoC keeps the stolen liquidETH / USDC (the live tx additionally swapped to ETH). Profit is measured on the attacker EOA.

1. Mint worthless offer inventory#

attack() deploys JunkToken, mints 100e18, and approves the queue (EtherFiVedaAtomicQueue_exp.sol:169-171, output.txt:93–output.txt:96).

2. Open a self-request against the largest approver#

Victim 0x69da…47D4 had allowance = 12.366762997907905993 liquidETH (balance was larger: 145.99, output.txt:98–output.txt:100). The exploit writes:

• deadline = type(uint64).max
• atomicPrice = 1e18
• offerAmount = 12366762997907905993

(output.txt:101, EtherFiVedaAtomicQueue_exp.sol:183).

3. solve with solver = victim#

queue.solve(junk, liquidETH, [exploit], "", 0x69da…47D4)

(EtherFiVedaAtomicQueue_exp.sol:187, output.txt:106)

Inside solve:

1. Junk transferFrom(exploit → victim, 12.366…) — the victim is paid in worthless tokens (output.txt:109).
2. finishSolve on the victim: gas 0, [Stop] (output.txt:114).
3. liquidETH.transferFrom(victim → exploit, 12.366…) — the drain (output.txt:117). AtomicRequestFulfilled emits the same amount in and out (output.txt:125).

4. Repeat for the remaining ten approvers#

The same _drain helper walks the other eight liquidETH holders and two USDC holders (EtherFiVedaAtomicQueue_exp.sol:189-194). Each fill is independent because solve zeroes offerAmount after a success.

5. Forward profit#

liquidETH.transfer(owner, balance) / usdc.transfer(owner, balance) (EtherFiVedaAtomicQueue_exp.sol:196-197). The test asserts liquidProfit > 14 ether and usdcProfit > 7e6 (output.txt:6, gas 2,478,578).

The historical transaction additionally routed liquidETH through Uniswap v4 Pool Manager 0x000000000004444c5dc75cB358380D2e3dE08A90 and the USDC dust through Uniswap v3 SwapRouter 0xE592427A0AEce92De3Edee1F18E0157C05861564, unwrapping WETH, and sent 15.453645063405167626 ETH to 0xa5CC…64Ea. That swap is incidental; the bug is the queue transferFrom.

Diagrams#

Remediation#

• Do not take solver from the caller. Hard-code solver = msg.sender, or restrict solve to a SOLVER_ROLE / requiresAuth keeper set (as later Veda AtomicQueue + AtomicSolverV5 do).
• Do not reuse user allowances as solver inventory. Pull want from msg.sender (the party that just ran finishSolve and can approve in that callback), never from an arbitrary third party.
• Require finishSolve to actually pay. For example, measure want.balanceOf(queue) (or allowance) before/after the callback and revert if the solver did not provision assetsForWant.
• Split spenders. A "user offer" allowance must not authorize a "solver want" transferFrom. Use a dedicated solver vault or permit bound to (user, offer, want, amount, nonce).
• Pause + revoke. If this queue is still live, pause() it and tell every approver to approve(queue, 0) for liquidETH, USDC, and any other listed asset.
• On-chain allowlists. isAtomicRequestValid already checks the user's offer allowance; add a symmetric check that solver is a known IAtomicSolver implementation, not a wallet.

How to reproduce#

cd /workspaces/RustroverProjects/audits/evm-hack-registry
_shared/run_poc.sh 2026-09-EtherFiVedaAtomicQueue_exp -vvvvv

Expect [PASS] testExploit() and:

liquidETH profit: 14.445541086626480232
USDC profit: 7.047848

The test forks http://127.0.0.1:8545 at block 25,952,623 from anvil_state.json. Verified AtomicQueue sources are under sources/AtomicQueue_d45884. The PoC is test/EtherFiVedaAtomicQueue_exp.sol.

Reference: https://x.com/exvulsec/status/2098318467556692298

References#

• https://x.com/SlowMist_Team/status/2098344499923784048 (@SlowMist_Team secondary analysis)

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2026-09-EtherFiVedaAtomicQueue_exp (evm-hack-registry mirror).
• Attack transaction: view on explorer.

Alerts & third-party analyses

• Original alert / thread: post on X.
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.