Haveno Brought Back the Arbitrator Multisig and Attackers Just Hijacked It

On May 20th, 2026, at 03:43 UTC, Haveno lead developer woodser opened a one-file pull request titled "core: refuse to update node address before multisig created." Eight added lines, one deleted line. By the time the patch went up, the attack was already running against live trades on RetoSwap, the largest Haveno-based decentralized Monero exchange. Hours earlier, Monero community contributor @ofrnxmr posted a PSA on X quoting woodser directly: pull every offer off the books, stop trading, the protocol itself is bleeding.

That eight-line patch tells you exactly what went wrong. Open TradeProtocol.java line 888 and look at the function called `onAckMessageAux`. Before the fix, when a node received an ACK message from a peer in a trade, the code would automatically update the peer's stored network address to whatever address sent the ACK. That sounds innocent because in a normal trade it just keeps the contact info current as Tor hidden service endpoints reconnect. The bug was that it ran the update before the multisig deposit was created, which meant the swap could happen before the cryptographic walls of the 2-of-3 wallet existed. An attacker who took a trade could send a forged out-of-order ACK message that impersonated the arbitrator, and the victim's client would obediently overwrite the real arbitrator's node address with the attacker's. From there the attacker controlled the third key in the multisig, and the wallet that was supposed to protect the trade was already compromised before any Monero ever hit it.

The mechanism here matters because it answers a question Haveno's own architecture invites. The platform is a fork of Bisq that brought back the 2-of-3 arbitrator multisig, the exact design Bisq abandoned in version 1.2.0 back in 2019 after concluding the arbitrator-as-keyholder model was too dangerous to keep. Bisq wrote at the time that a hacked or impersonated arbitrator could "sweep the offer book and steal all locked funds, or bait takers into fraudulent trades." Seven years later, RetoSwap confirmed publicly that this is exactly what just happened on their fork, with the third key getting hijacked through message frontrunning during trade initiation, and the resulting multisig compromised before either honest party could deposit.

The timeline is brutal. Version 1.4.0-reto shipped on May 18th, 2026, forty-eight hours before the exploit PR went up, and its release notes list WebTunnels Tor support, dispute cleanup, offer-edit fixes, and throttling tweaks. None of them mention this vulnerability because nobody on the dev side knew about it yet. Anyone who updated this week is running the version that's getting actively drained. The patch in PR #2315 exists but at the time of writing it's still open, meaning no release contains the fix. If you are sitting on an open offer right now, your client is the target. From what I found, the RetoSwap team has already banned the exploiter accounts and is publicly recommending the same thing woodser said: pull everything, wait.

For anyone who hasn't followed P2P exchange forensics, this rhymes hard with what happened to Bisq itself two weeks ago. On May 1st, 2026, an attacker drained about 11.6 BTC from 10 Bisq users by exploiting a missing validation check on miner fees in a trade, which the Bisq team later described as a likely AI-assisted vulnerability discovery. They conceded the failure was theirs, pushed reimbursement through their DAO, and explicitly admitted the mistake was "not only the missing validation check" but also "failing to react early enough to the changing security landscape." Same lesson on both sides of the fork: the trade protocol is the attack surface, and one missing check is where stolen funds come from. Bisq removed the arbitrator from the multisig in 2019 and still got hit. Haveno kept the arbitrator in the multisig, and just got hit at exactly that seam. The reto fork, with the largest network on Haveno's protocol at roughly $2M monthly volume per KYCnot.me, is now the most exposed.

This is a protocol-level bug, which means you can't patch around it with stricter OPSEC and you need the new client to be safe. The fix itself is correct and minimal, which is the kind of patch you want to see because it means the bug had one root cause and woodser found it cleanly. The new code refuses to apply an ACK-driven node-address update if `trade.isDepositRequested()` returns false, closing the window the attacker was using to hijack the arbitrator role before the deposit existed. The uncomfortable part is that this happened on a publicly auditable codebase that the broader Monero community treats as a flagship for non-custodial trading, and it still took an active exploit in the wild before the bug surfaced, which is roughly the same disclosure pattern Bisq just lived through two weeks ago.

Here is the practical guidance if you have any exposure. Open your RetoSwap or other Haveno-fork client, remove every offer, do not take or make new trades until a patched release is published, and watch the haveno-dex repository releases page and RetoSwap's official account for the announcement that the fix is live. If you were mid-trade when the exploit started, your security deposit is the first thing at risk, and the Haveno trade protocol docs describe what arbitration looks like once you're already in a dispute, but understand that the very role you would be appealing to is the role that just got impersonated. This is a hard week for P2P Monero, and the people running offers on these networks are the ones absorbing the cost while the patch finishes its review.