**Bisq Protocol Exploit Update** This is a brief update on what we have learned so far, the current state of reimbursement planning for affected users, and some broader observations about the growing role of AI-assisted attacks. **Estimated impact** Based on preliminary estimates from data analysis and reports from affected users, the total amount stolen appears to be approximately **11 BTC**. The attacker used a **0.001 BTC** multisig output together with an unusually high **10,000 sat** miner fee in the reported transactions. That combination created a recognizable transaction fingerprint, which helped identify suspicious transactions within the time window in which the attack occurred. So far only Altcoin trades have been reported. This remains a preliminary estimate. The final amount may change as additional reports are reviewed. **How are victims getting reimbursed?** We are currently discussing several reimbursement options. Our goal is to enable **fast and complete reimbursement with minimal friction for victims**. There are, however, practical constraints: • **Protocol constraints**: victims must open arbitration cases. Arbitration can only be opened after a time lock of **10 days for altcoin trades** and **20 days for fiat trades**. • **DAO constraints**: the DAO has limits on how much can be issued per DAO cycle. • **DAO governance**: the proposal for the reimbursement has to be confirmed by the DAO via voting. The current DAO cycle will end around 25th of May. The current intention is to allow victims to choose between reimbursement in **Bitcoin** or **BSQ**. At this stage we cannot make a final commitment on the exact mechanism, but we wanted to share our intentions. For Bisq users — whether affected directly or not — discussion is ongoing in the **Matrix channel**: (https://matrix.to/#/%23bisq:bitcoin.kyoto) And on **GitHub**: (https://github.com/bisq-network/bisq/discussions/7628) The final reimbursement model will be submitted as a **DAO proposal for voting**. The exploit caused a significant challenge for both Bisq and the DAO, but we are confident it is manageable. It was serious, but it was not a fatal blow. **How did the exploit happen?** In short, the exploit was caused by a **missing validation that should have rejected negative input values provided by the taker**. The maker and taker must use the same miner fee. That fee value is provided by the taker. The attacker supplied a **negative miner fee**. When the maker calculated the multisig output amount — which includes the miner fee for the payout transaction — the negative value reduced the multisig amount to **0.001 BTC**, while the remaining funds were redirected to the taker’s change output. Unfortunately, the taker change output was a leftover from older protocol versions. It had already been identified as something that should be removed, but that cleanup had unfortunately not happened. **Was it an AI-assisted attack?** We cannot answer that with certainty. However, based on our own experience during the investigation, we think it is likely. After the issue was discovered, one group of developers started manual code inspection to understand how the exploit could have happened. A second group used AI-assisted analysis. The AI-assisted group was faster and identified the exploit path in a relatively short time. The first AI-generated attempt turned out to be a false positive, but a second attempt by another developer successfully reproduced the exploit. It also produced both an attack patch and a corresponding fix. AI tools include safeguards, so simply asking them to identify an exploit will usually not work. However, with enough context, careful prompting, and a degree of social engineering of the model, those safeguards can be bypassed. Based on our experience, it is reasonable to assume that the attacker may have followed a similar path. **A warning shot** Some Bisq developers are highly proficient with AI tools. However, we had not systematically used them as part of an actual security audit process. One developer attempted to get Bisq into an external security audit program, but the application was rejected. In hindsight, this was a serious failure on our side. The mistake was not only the missing validation check. It was also failing to react early enough to the changing security landscape and the increasing practical relevance of AI-assisted vulnerability discovery. We must assume that there will be further attempts. Over the coming weeks we will invest significant effort into hardening the codebase and actively using AI tools ourselves to search for failure modes. We are particularly focused on vulnerabilities that could directly affect the wallet. Until additional review and hardening are completed, we recommend that Bisq users **do not keep more BTC in their Bisq wallet than is necessary for active trading**. We also hope this serves as a useful warning to other projects in the space. If our experience helps others identify similar risks earlier and strengthen their defenses, something positive may still come out of it. **Release plans** We have already fixed the immediate vulnerability and are currently working on additional hardening for a hotfix release. We expect to publish that release in the coming days. After that, we will continue with a follow-up release focused on further hardening, broader review, and additional security auditing.

We are delayed as some issues unrelated to the release occurred. Hope we are ready next day(s). The day only has 24 hours and we consume those nearly already....

# Bisq Exploit Update 2 ## Data points We have now received all reports from affected users. The total amount of funds lost is **11.59104 BTC**. A total of **10 users** were affected. Only **altcoin trades** were impacted. **Fiat trades** are protected by the account age witness signing system, which likely acted as a deterrent to the attacker. **Three trades accounted for almost 90% of the total loss**, while **three traders suffered only very small losses**. ## What is the current status of reimbursement? No final proposal has been completed yet. Our goal remains to submit a proposal for **DAO voting**, and the current proposal period ends in about **one week**. The intent remains the same as initially communicated: **we plan to fully reimburse all victims** and provide the option to receive reimbursement in **Bitcoin or BSQ**. What remains unresolved is how to fund the reimbursement in a way that minimizes the impact on the **DAO, BSQ stakeholders, and Bisq contributors**. ## When will a new version be released? Our initial plan was to deploy a hotfix based on the latest release, with only minimal changes to address the vulnerability used in the exploit. However, this approach proved too risky. We must assume that the same attacker — and potentially others — will actively probe for additional vulnerabilities across all parts of the application. This includes the **wallet**, the **P2P network**, the **DAO**, and infrastructure components such as **external market price providers**. Given the breadth of this attack surface, a full review could not be completed in a short timeframe. We therefore focused on **hardening the trade protocol** and addressing other short-term risks that could realistically be mitigated. In addition, we decided to merge the hotfix branch into the main branch, which already contained the work for the upcoming **1.9.23 release** and was close to completion. This introduced a substantial number of additional changes and naturally requires more extensive testing — which is why this option was not initially considered. However, as the hotfix itself grew significantly in scope, the original argument no longer applied and merging became the more reasonable path. As a result, our release schedule has been delayed. We are now in the final stages and hope to begin testing and release within the next few days. We understand that this delay is frustrating for users. However, security requires discipline, and we cannot take shortcuts that could create the risk of a follow-up incident. ## What did we find during the security analysis? The main findings that could affect user funds are limited to the **trade protocol**. No new exploit path has been identified. That said, we discovered and addressed a number of potential issues. Based on our current understanding, none of them could have been used to directly steal funds. Some, however, could have caused transactions to become invalid, potentially leading to secondary damage and operational risk. ### Wallet security No wallet-related vulnerability has been identified. We are currently evaluating additional measures to further reduce wallet-related risk, but these would require significantly more time to implement. While no wallet vulnerability has been found, we cannot completely exclude the possibility that undiscovered issues may exist. Because a **hot wallet integrated into a P2P application** inherently carries more risk than a traditional wallet, we strongly recommend that users **do not keep more funds in the Bisq wallet than are necessary for active trading**. This should already be standard security practice: **keep savings in a hardware wallet, not in the Bisq wallet**. ### Other areas Our analysis of the **DAO**, **P2P network**, and **node infrastructure** did not uncover any critical vulnerabilities. However, we did address several existing issues and will continue working to reduce attack surface and strengthen protective safeguards. ## Some learnings One important lesson from this work is that **structural friction and layer boundaries can act as valuable security safeguards**. In **Bisq 1**, the maker fee transaction allocates the UTXO required by the maker for the trade. This transaction is created only through direct user action, not by network messages, and it exists outside the trade protocol itself. That separation created an important boundary and limited the maximum possible damage the exploit could cause. In the **Bisq 2 MuSig protocol**, we removed that extra transaction as an optimization. At the time, we viewed that as clear progress. With the learnings from this incident, we need to reconsider that assumption — or at minimum recognize that the protective boundary created by that separate layer no longer exists in the new protocol. **Security often works against intuition. Friction can be beneficial. Layer boundaries create risk boundaries.**

Bisq v1 has experienced an exploit in its trade protocol that allowed an attacker to drain a portion of available offers. The impact was limited to open offers that were actively taken by the attacker over the last 12 hours. Funds held in users’ Bisq Bitcoin wallets were not affected. As an immediate mitigation, an emergency mechanism was activated to disable trading by setting the required trading version to 2.0.0 — a version that does not exist. This effectively prevents the attacker from continuing the exploit. The attack appears to have started on May 1 in the early morning hours. The development team is continuing to investigate the full extent of the damage. Users with trades initiated on or after this time are advised to open mediation by selecting the trade and pressing Ctrl + O. A mediator will assess whether their trade was affected. Preliminary investigation indicates that the attacker exploited a missing validation check using a modified client. The team is working to reliably reproduce the issue and verify a fix. Once confirmed, a hotfix will be released based on the latest stable version. In parallel, a comprehensive security review is being conducted to identify any related or additional vulnerabilities. For affected users, reimbursement options are being evaluated. Bisq recognizes that both the exploit and a consequent response are critical to its integrity, and is dedicating all available resources to finding a solution that helps restore confidence. Bisq 2, with the Bisq Easy trade protocol, is not affected. It is a separate codebase with a fundamentally different protocol design. Bisq will continue to provide updates through its official communication channels, including Matrix, the Bisq Forum, Telegram, Reddit, X, and Nostr. Bisq sincerely apologizes for the impact this incident has had on its users, and is fully committed to addressing both the root cause and its consequences.