Introduction
On May 1, 2026, Bisq v1 experienced a security incident affecting its trade protocol. An attacker exploited insufficient validation checks in parts of the protocol using a modified client implementation. The attack targeted active altcoin trades and resulted in losses for a limited number of users.
This post-mortem explains what happened, how the incident was contained, what we discovered during the investigation, what changes were implemented in response, and what lessons we are taking forward.
We want to acknowledge the impact this incident had on affected users and the wider Bisq community. Incidents of this kind directly challenge confidence in Bisq, and we approached both the investigation and the remediation effort with that responsibility in mind.
Summary
- The exploit affected Bisq v1 only.
- Bisq 2 and the Bisq Easy protocol were not affected.
- The attacker exploited missing validation checks within the trade protocol.
- Only altcoin trades were impacted.
- Fiat trades were protected by the account age witness signing system.
- User funds stored in Bisq wallets were not directly compromised.
- 10 users were affected.
- Total losses amounted to 11.59104 BTC.
- Three traders suffered the vast majority of losses.
- Trading was halted through an emergency version enforcement mechanism to prevent continued exploitation.
- No additional exploit path capable of directly stealing funds was identified during the broader security review.
Timeline
Initial Exploitation
The attack appears to have started during the early hours of May 1, 2026. The attacker selectively targeted open offers and manipulated trades through a modified client.
Detection and Emergency Response
Once suspicious activity was identified, emergency measures were activated to stop further exploitation. Trading was effectively disabled by enforcing a non-existent mandatory trading version, preventing peers from continuing protocol interactions.
At the same time:
- Investigation efforts began immediately.
- Affected users were asked to open mediation cases.
- Information about the incident was distributed through our main communication channels.
- Internal analysis focused on reproducing the exploit and identifying the root cause.
Investigation Phase
The original plan was to release a minimal hotfix as quickly as possible. However, as the investigation progressed, it became clear that a narrow patch would not provide sufficient assurance against follow-up attacks.
The scope of the review expanded beyond the immediate exploit path to include:
- Trade protocol validation
- Wallet interaction surfaces
- P2P network behavior
- DAO-related components
- External infrastructure dependencies
- Build and dependency security
There are strong reasons to assume that the attacker used AI-assisted tools to discover the vulnerability, so we had to assume additional probing attempts would follow after reopening the network.
Release Preparation
Rather than maintaining a small isolated hotfix branch, the fixes were merged into the main development branch that already contained work for the upcoming 1.9.23 release. This increased the amount of testing required but allowed for a more comprehensive hardening effort.
Impact Assessment
The incident was limited in scope compared to the worst-case scenarios initially considered during the first hours of the investigation.
What Was Affected
- Open altcoin offers that were actively taken by the attacker
- A limited number of traders participating in affected trades
What Was Not Affected
- Fiat trades
- Bisq 2
- Funds passively stored in Bisq wallets
- DAO integrity
- The broader P2P network infrastructure
The account age witness signing mechanism used for fiat trades likely acted as an effective deterrent and significantly reduced the potential attack surface.
Root Cause
The primary exploit path resulted from insufficient validation inside the trade protocol. The attacker used a modified client to bypass assumptions made by honest peers. Specifically, the taker defines the miner fee for the trade transactions and passes that value to the maker. This value was not validated against negative numbers, allowing the attacker to cause the maker to calculate an incorrect output value for the multisig output.
The vulnerability exposed weaknesses in how certain protocol messages and trade-related data were verified before acceptance.
During the investigation, additional weaknesses and edge cases were discovered and corrected. None of those secondary findings are currently believed to have enabled direct theft of funds, though some could have created operational or transaction integrity risks.
Security Review Findings
Trade Protocol
The majority of relevant findings were concentrated within the trade protocol itself. Significant hardening work was performed around:
- Trade message validation
- Deposit transaction verification
- Payout transaction validation
- Contract data consistency checks
- Peer-provided wallet data validation
Wallet Security
No wallet vulnerability capable of directly compromising user funds was identified.
However, Bisq still operates as a hot wallet integrated into a complex P2P trading application, which inherently carries higher risk than standard wallets. For this reason, users should continue following standard operational security practices and avoid storing long-term savings inside the Bisq wallet.
Infrastructure and Network Components
The investigation also reviewed:
- DAO functionality
- P2P networking
- Node infrastructure
- External market price dependencies
No critical vulnerabilities were identified in those systems, though several issues were fixed as part of the broader hardening effort.
Immediate and Long-Term Mitigations
The 1.10.0 release includes a broad set of security improvements introduced in response to the incident.
Security Hardening
Key improvements include:
- Expanded protocol validation checks
- Additional verification of trade-related transactions and data
- Improved protection against supply chain attacks through dependency signature verification
- Build process hardening and additional toolchain verification
- Updated dependencies including Java, JavaFX, Tor, and bitcoinj
- New Docker-based DAO and end-to-end trade testing infrastructure
- Reproducible build system improvements (still partially work in progress but planned for the next release)
Trading Restrictions
Several temporary or precautionary limitations were introduced to reduce risk exposure while additional auditing work continues:
- Reduced maximum trade size to 0.125 Bitcoin
- Limited acceptable price deviation to 25%
- Disabled XMR auto-confirmation
- Removal of dispute attachment and log uploads
- Removal of the webcam QR scanning dependency due to its large set of native libraries
These changes prioritize security and risk reduction over convenience.
Reimbursement
A reimbursement proposal has been submitted to the DAO with the goal of fully reimbursing affected users in Bitcoin, subject to DAO approval.
Throughout the process, the objective remained consistent:
- Full reimbursement for victims
- Minimizing negative impact on the DAO
- Protecting BSQ stakeholders and contributors from disproportionate burden
We appreciate the constructive participation from the community during these discussions.
Lessons Learned
This incident reinforced several important security principles.
Layer Boundaries Matter
One of the most important findings was that architectural friction can provide meaningful security benefits.
In Bisq 1, certain trade setup steps required explicit user action outside the trade protocol itself. That separation unintentionally created a containment boundary which limited the scale of the exploit.
Some of those boundaries had been streamlined away in the new MuSig protocol design for Bisq 2 for efficiency and UX reasons. This incident demonstrated that reducing friction can also reduce security segmentation. We will reconsider those design decisions.
Fast Fixes Can Increase Risk
While there was pressure to restore trading quickly, releasing a narrowly scoped hotfix without broader review would have introduced unacceptable risk.
The delayed release schedule was the result of deliberately choosing comprehensive validation and testing over speed.
Defense in Depth Is Essential
No single safeguard should be assumed sufficient in adversarial environments. Validation, isolation boundaries, reproducible builds, dependency verification, and operational constraints all contribute to reducing systemic risk.
Next Steps
Work following this incident continues in several areas:
- Additional protocol review and auditing
- Continued reduction of attack surface
- Completion of reproducible build deployment
- Further end-to-end automated testing
- Review of protocol assumptions in future Bisq versions
- Evaluation of stronger wallet isolation approaches
Security hardening will remain an ongoing priority rather than a one-time response.
Closing
We want to thank everyone who contributed during this incident:
- Users who quickly reported affected trades
- Mediators and contributors assisting with investigations
- Developers and reviewers working on fixes and testing
- Community members providing support and coordination
Incidents like this are difficult for any open decentralized project. Transparency, careful analysis, and disciplined remediation are essential to maintaining long-term resilience and trust.
We remain committed to learning from this event and continuing to strengthen the security and robustness of Bisq.