Unauthorized Vault Approval Drain

The key architectural fact is that these privileged hooks were meant to be callable only by the legitimate parent spawner. In practice, the contract never records or checks a specific trusted spawner identity. Because Aerodrome liquidity is permissionless and the attacker only needs a fresh helper contract plus gas, the exploit is an ACT opportunity rather than a privileged compromise.

3. Vulnerability Analysis & Root Cause Summary

This is an ATTACK-class authorization failure. The intended invariant is that only the legitimate parent MoltEVM or Moltling spawner for a child instance may mint supply or change exemption status on that instance. The verified MoltEVM code breaks that invariant by checking only whether msg.sender is a contract and whether msg.sender.staticcall("initialized()") returns true. That predicate is attacker-controlled and does not authenticate identity. As a result, mintFromSpawner can mint arbitrary supply directly to an attacker-controlled address and setExemptFromSpawner can whitelist that same address against transfer restrictions. Once the fabricated tokens exist, the attacker sells them into public Aerodrome liquidity and withdraws ETH profit in the same transaction.

The code-level breakpoint is visible in the verified root-token source:

modifier onlySpawnerToken() {
    require(msg.sender.code.length > 0, "not contract");
    (bool ok, bytes memory data) = msg.sender.staticcall(abi.encodeWithSignature("initialized()"));
    require(ok && data.length == 32 && abi.decode(data, (bool)) == true, "not worm spawner");
    _;
}

function mintFromSpawner(address to, uint256 amount) external onlySpawnerToken {
    _mint(to, amount);
}

function setExemptFromSpawner(address a, bool v) external onlySpawnerToken {
    _setExempt(a, v);
}

4. Detailed Root Cause Analysis

The exploitable pre-state is Base block 43018099, after MoltEVM had already deployed the root token and created the Aerodrome WETH pool. At that point, the only remaining requirement for exploitation was a helper contract whose initialized() function returned true.

In the first exploit transaction 0x90f5ff5f6b849e534b40d04dcf37460f49d2314a920beadedd993a8ef43a4e8c, the attacker deployed orchestrator 0xE0536A52e15Efa5F550B168Ceb26A01479e465dE, which in turn deployed fake spawner 0xd4f74693373CF89eB41b1678EcEB33B774269B04. The root token then treated that fake spawner as authorized:

MoltEVM::mintFromSpawner(0xd4f74693373CF89eB41b1678EcEB33B774269B04, 100000000000000000000000000)
  0xd4f74693373CF89eB41b1678EcEB33B774269B04::initialized() [staticcall]
Router::swapExactTokensForTokensSupportingFeeOnTransferTokens(...)
WETH9::withdraw(4435669098513314)

That trace proves the critical execution order: the victim contract asks the attacker helper whether it is initialized, accepts the answer, mints unauthorized supply, and the attacker immediately routes the minted balance through Aerodrome to extract ETH.

The same pattern scales cleanly. In transaction 0x10b7ec56e852351de4951ab2a91fca4099fc4f385dd2171951476c3d497fe03d, attacker helper 0xA9bcf8a0804518e4deF8A348e153CF9bC2AC9C0F called setExemptFromSpawner and mintFromSpawner across 12 victim token targets in one transaction, and each victim again validated the helper only by an initialized() staticcall. The revised deterministic refinement artifact enumerates 32 attacked token instances in total across the 11 exploit transactions, including the verified root token and verified WormGenesis instance 0x3d9b7201354c8fdbdd8cdd29ec32ca2b96cc358d.

The success predicate is also deterministic. For the first exploit tx, debug_traceTransaction prestate diff shows attacker EOA 0x4c452e829748e34e11d010e338596433d638f03c moving from 61735213774266739 wei to 66045983529708679 wei, a post-fee increase of 4310769755441940 wei (0.004310769755441940 ETH). That is a direct consequence of the unauthorized mint followed by a public-liquidity sale; no hidden permissions or off-chain side channel are involved.

5. Adversary Flow Analysis

The on-chain attack flow is consistent across all observed exploit transactions:

1. The attacker funds an unprivileged EOA and deploys a short-lived orchestrator plus a fake spawner helper contract.
2. The fake spawner exposes initialized() -> true, which is sufficient to satisfy the victim’s onlySpawnerToken modifier.
3. The attacker calls setExemptFromSpawner to flip the helper into the exempt set where needed.
4. The attacker calls mintFromSpawner on the vulnerable token instance, minting arbitrary supply directly to the helper.
5. The helper approves the public Aerodrome router and swaps the fabricated balance into WETH/ETH.
6. The helper withdraws WETH to ETH and forwards the proceeds back to the attacker EOA.

The first exploit transaction targeted only the root token. Later transactions such as 0x10b7ec56e852351de4951ab2a91fca4099fc4f385dd2171951476c3d497fe03d and 0xe770afb80b9c4948348d95377a53fd42bb6c77e4cd490f08936d41d312a71083 expanded the same helper-contract strategy across many spawned token pools. Across the observed set, the attacker cluster consists of EOA 0x4c452e829748e34e11d010e338596433d638f03c and attacker-created orchestrators including 0xE0536A52e15Efa5F550B168Ceb26A01479e465dE and 0x9ff446a31a6796c8cf1b65129547e549ddc7f2fe.

6. Impact & Losses

The measurable impact is ETH drained from public liquidity supporting the MoltEVM root token and spawned vulnerable token instances. The observed gross extraction was 13245134847652521355 wei (13.245134847652521355 ETH) across 11 adversary-crafted exploit transactions. After gas, the attacker cluster retained 13241529885121947119 wei (13.241529885121947119 ETH) net.

The affected victim set is broader than a single token contract. The revised evidence-backed enumeration identifies 32 attacked token instances on Base: the verified root token, one verified WormGenesis instance, and 30 additional unverified vulnerable instances that expose the same fake-spawner primitive.

7. References

1. MoltEVM verified source: https://basescan.org/address/0x225dA3D879D379FF6510C1CC27Ac8535353f501F#code
2. Root-token deployment tx: 0x656db2115205c8915b452453fdde2b320bf37b1a30fa6c5471c1821d85cffa3b
3. Root-pool creation tx: 0x892fb9165cc7532104f7976c762b987acefa2efd8aa8889c409d4a68cc89e0cb
4. First exploit tx: 0x90f5ff5f6b849e534b40d04dcf37460f49d2314a920beadedd993a8ef43a4e8c
5. Largest observed multi-target exploit tx: 0x10b7ec56e852351de4951ab2a91fca4099fc4f385dd2171951476c3d497fe03d
6. Later exploit tx on additional instances: 0xe770afb80b9c4948348d95377a53fd42bb6c77e4cd490f08936d41d312a71083
7. Auditor evidence summary: /workspace/session/artifacts/auditor/iter_0/evidence_summary.json
8. Deterministic refinement with exact profit delta and attacked-token enumeration: /workspace/session/artifacts/auditor/iter_1/deterministic_refinement.json