Skip to main content
• 7 min read

RetoSwap/Haveno Exploit: Active Arbitrator
Multisig Hijack via Pre-Deposit ACK Message Spoofing

RetoSwap halted trading after an active Haveno protocol exploit let attackers impersonate the arbitrator during trade setup, poison the stored node address, and create a compromised Monero 2-of-3 multisig before deposits were funded.

AUTOSEC.DEVAUTOSEC.DEV
RetoSwap/Haveno Exploit: Active Arbitrator Multisig Hijack via Pre-Deposit ACK Message Spoofing
  • Incident Date: May 20, 2026; RetoSwap said Haveno lead developer woodser reported active exploitation at 02:31 UTC
  • Target: RetoSwap / Haveno trade protocol, specifically trade-message sender verification and arbitrator node-address binding before deposit funding
  • Target Overview: Haveno is a Tor-routed, Monero-focused P2P exchange protocol. RetoSwap, formerly Haveno-reto, is a public Haveno network that had just shipped the 1.4.0-reto client release on May 18, 2026.
  • Total Loss: Not publicly finalized in the reviewed sources. RetoSwap said damage appeared contained to large-scale crypto offers, with fiat traders not affected.
  • Recovery Status: RetoSwap said it banned the exploiter onion address, halted trading by forcing the minimum client version filter to 2.0.0, and was assessing recovery options for affected traders. Haveno PR #2315 remained the main public fix track at the time of review.
  • Attack Vector: Out-of-Order ACK Message Spoofing / Arbitrator Node-Address Poisoning / Pre-Deposit Multisig Participant Hijack

Incident Review & Technical Details​

1. Attack Path​

  1. Vulnerable Client Was Deployed: RetoSwap 1.4.0-reto was published on May 18, 2026. Public analysis later linked the live exploit to Haveno trade-protocol logic that accepted certain peer node-address updates during trade setup.
  2. Active Exploitation Was Reported: On May 20, RetoSwap publicly said woodser reported that the Haveno trade protocol was being actively exploited. RetoSwap then banned the exploiter onion address and halted trading through the client-version filter.
  3. Attacker Entered the Trade Setup Flow: The attacker took or initiated trades during the early negotiation stage, before the Monero multisig deposit wallet had been created and funded.
  4. Forged ACK Message Poisoned Role Routing: Public reporting and RetoSwap's quoted explanation described a fake, out-of-order ACK message that impersonated the arbitrator. The victim client updated the arbitrator's stored node address to the attacker's onion address.
  5. Address Mutation Happened Before the Custody Boundary: The dangerous window was before trade.isDepositRequested() became true. At that point, the client had not yet created the final 2-of-3 multisig, so poisoning the arbitrator route could influence which endpoint participated in setup.
  6. Compromised Multisig Was Created: Once the real arbitrator's node address was replaced, the trade could proceed toward a multisig where the attacker controlled the arbitrator-facing participant. That undermined the protective intent of the buyer/seller/arbitrator 2-of-3 model before funds reached the wallet.
  7. Halt and Patch Work Followed: Haveno PR #2315 was opened on May 20. Its title and diff evolved from a narrow pre-deposit node-address gate into a broader fix: verify trade-message senders against the expected public key rings and stop treating unverified routing data as identity.

2. Impact Scope​

  • Affected Surface: The exposed surface was the Haveno trade protocol used by RetoSwap, especially ACK processing, peer node-address updates, and arbitrator role binding during pre-deposit setup.
  • Affected Users: RetoSwap said the observed damage appeared contained to large-scale crypto offers and that fiat traders were not affected, but final affected-trader accounting had not been published in the reviewed materials.
  • Operational Impact: Trading was halted through the network filter mechanism while the protocol was reviewed for related issues.
  • Patch Status: As of the reviewed GitHub state, PR #2315 was open and under review, with one commit touching sender verification, support/dispute handling, deposit-confirmation message handling, and deprecated message fields.
  • Broader Exposure: Other Haveno-based networks or forks using the same trade protocol path should treat the issue as relevant until they confirm a patched release and regression coverage.
  • Disclosure Gap: No final post-mortem with exact exploit transactions, total losses, affected onion addresses, signed patched release hash, and recovery accounting had been published in the reviewed public sources.

3. Root Cause Assessment​

The exploit points to a classic P2P protocol boundary failure: a mutable network address was allowed to influence a custody-critical role before the message sender was strongly bound to the expected cryptographic identity.

Key risk patterns to examine:

  • Routing Data Was Treated Too Much Like Identity: Tor onion addresses can change or be re-announced, but the buyer, seller, and arbitrator roles must be anchored to stable public keys and protocol state, not merely to the latest address seen in a message.
  • ACK Messages Crossed a High-Trust Boundary: ACKs are often treated as transport or liveness plumbing. In this flow, an ACK-driven node-address update could alter the future multisig participant set, making it custody-critical.
  • Pre-Deposit State Is the Most Sensitive Phase: Before the multisig exists, role assignment and key exchange are still forming the wallet that will hold funds. Any address or role mutation in this phase must be authenticated and state-gated.
  • Partial Verification Creates Confusing Safety Assumptions: Some trade messages were signed or verified in specific handlers, but the public PR shows the fix moving toward consistent getVerifiedTradePeer style checks across trade, support, dispute, and ACK paths.
  • Arbitrator-in-Multisig Design Amplified the Bug: Because the arbitrator holds the third key in the trade wallet model, impersonating or redirecting that role can become direct custody compromise rather than only a messaging failure.

The core invariant should have been strict: no message may update buyer, seller, or arbitrator routing state unless the sender is cryptographically verified as the expected role, and no pre-deposit routing update may be allowed to change the identity or key material that will enter the multisig.

4. Mitigation and Response​

Recommended actions for RetoSwap users, Haveno forks, and P2P exchange operators:

  • Remove open offers and avoid starting new trades until a patched release is published and verified.
  • Treat 1.4.0-reto and related Haveno builds as unsafe for live trading unless the specific sender-verification fix has been confirmed in the deployed client.
  • Bind every trade message to the expected role public key ring before applying state changes, address updates, dispute changes, payment-state transitions, or multisig data.
  • Separate routing address freshness from cryptographic identity. A changed onion address should be an authenticated metadata update, not a role reassignment.
  • Reject out-of-order ACKs and any ACK whose source UID, source class, sender key, role, and trade state do not match an expected transition.
  • Add regression tests for fake arbitrator ACKs, stale ACKs, duplicate ACKs, pre-deposit address swaps, address reuse between roles, and mailbox-delivered spoof attempts.
  • Require signed release notes and clear upgrade guidance when a network-level halt is lifted.
  • Publish a final incident report with affected versions, exploit timeline, losses, recovery process, patched commit, release hashes, and a list of related protocol branches reviewed.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

The RetoSwap/Haveno incident shows that non-custodial P2P trading systems still have custody-critical application logic. Multisig does not protect users if the protocol can be tricked into building the wallet with the wrong participant before funds arrive.

  1. P2P Trade Protocol Audit: AUTOSEC.DEV reviews message authentication, role binding, ACK handling, mailbox replay behavior, dispute workflows, and state-machine transitions in decentralized exchange protocols.
  2. Multisig Workflow Review: We validate key ceremony ordering, participant identity binding, signer rotation assumptions, payout rules, timeout behavior, and recovery branches for 2-of-2 and 2-of-3 custody flows.
  3. State-Machine Fuzzing: We build tests for out-of-order messages, malicious acknowledgements, stale routing data, role confusion, replayed mailbox messages, and state transitions that mutate custody roles.
  4. Incident Response (IR): We support exploit reconstruction, affected-trade scoping, patched-release validation, recovery-plan review, and user-facing technical disclosure.

Service Content​

Reference​