SliceFundsModule exploit analysis

Slice is an onchain commerce protocol on Base. A shop on it keeps its sales in its own contract until the owner withdraws them, and releases of those earnings run through Slice's settlement contract, the FundsModule.

The pool that held it was reachable by anyone, and the credit the module recorded was never checked against a balance.

The entry point trusts a number it was handed

0x9d2edfac takes a list of source contracts, a recipient, a token and a boolean. For each source it calls source._releaseFromFundsModule(recipient, token) and treats the returned amount as the truth of what was paid out. The recipient is credited a deposit of exactly that amount, with nothing checking that the module's own ETH or USDC balance rose by it. When the boolean is set, the same call then withdraws that credited amount from the module's pooled reserves and sends it to the recipient.

Two checks are missing, not one. The source list is never checked against the registered set of shop contracts, so a caller can pass a contract of their own. And the credited amount never has to be backed by anything, because the contract does not look at what it received.

DeFiHackLabs records the mechanism and ships a proof of concept that forks Base at the block before the attack and replays it. The proof of concept notes that neither the implementation at the attack block nor the current one is verified on BaseScan, so the module's source was not published for review.

Pooling the reserves, then taking them

The attacker used the same entry point for both halves of the job.

The first calls used the real Slice product contracts with the flag false, and pulled the unclaimed sales revenue of real stores into the module. The proof of concept records that the module held essentially nothing beforehand, 2 wei of ETH and 1 unit of USDC, so everything sitting in the pool after the first phase was money that belonged to someone else.

The second calls used two contracts the attacker had deployed. They returned a non-zero amount while transferring nothing. The module credited that amount to the attacker and paid it straight out of the pool, in the same call.

Rektradar's brief on the incident puts the number of real stores whose revenue was force-released at about seventy. Slice's own statement says fewer than ten user stores were affected, and that most of the money was Slice's own or tied to past partner initiatives.

What one transaction shows

It all happened in one transaction, 0x02b039a6345348d984e4a0b70dd233127772206e61ce82c390c4709c0b8d790a, at block 52,866,122 on 20 October 2026 at 18:39:51 UTC. The sender was 0xC34572EbB26b9A4c54854AaE8d2347108E8c892F, and it called into a contract at 0x8eBC7878287415f1FADCF4Ace8817094E4C86f90. The transaction produced 17 internal transactions and 108 ERC-20 transfers.

The contract that paid the attacker was the FundsModule itself, 0x61bCd1ED11fC03C958A847A6687b1875f5eAcaaf: 8.716935563284127414 ETH, which BaseScan valued at $20,715.54 on the day, and 19,820.734002 USDC, valued at $19,815.32. At the $2,376.47 ETH price on the page, that comes to about $40,531, which is the roughly $41K the write-ups report.

Before the payout, the same transaction moved ETH and USDC from more than forty shop contracts into the module, and paid recipients directly at the same time, to addresses including sliceprotocol.base.eth and streetphotography.base.eth. The pool that funded the payout was assembled inside the transaction that emptied it.

The proof of concept reconstructs all eight ETH legs and 55 of the 66 USDC legs. The 11 legs it does not reconstruct paid recipients that are themselves slicers, so their money never reached the drainable balance, and the reconstruction still lands within the module's one-unit rounding on the payout.

Paused and fixed within the hour

SlowMist and DefimonAlerts both reported the incident on 21 October. SlowMist's alert put the loss at about $41,000, and DefimonAlerts put it at about $42,000. Slice's statement gives about $41k.

Slice says it paused the contracts and fixed the vulnerability within an hour of being alerted, contacted incident response teams and traced the stolen funds, which it said it was monitoring. It also paused use of the protocol while it completed its review, and offered the attacker a deal: return the funds by 23 October at 17:00 UTC and keep 10% as a white-hat bounty. No return of funds had been reported as of 27 October.

Two other protocols with the same habit

UnifiProtocol let a caller-supplied pool decide reward eligibility and the arithmetic that followed. AllbridgeCCTP credited a deposit read from a forged CCTP message without checking that any USDC had actually been minted. In both, a figure that arrived from outside the contract was written down as a balance.