Bisq Exploit Update 2

Bisq DAO
1

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 traders 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.

4 Likes
3

Thanks for the update. Given that you’re in the final stages of testing, is there a specific target date for when trading will be fully operational again? I’m trying to decide if I should wait a few more days for the fix or if I need to move my activity elsewhere in the meantime.

4

There is no ETA, but the development is in the later phases of testing, so we are really talking about a short time.

1 Like
5

Thank you for the updates, and for the hard work you’re obviously putting into this.

There is a point that is probably just harried messaging that I would like to clear up. When I opened Bisq today (for the first time in weeks) I got the message that a new version was out (ie “a mandatory update was released”), which disabled old versions. But I do not see this new version even though the message used the past tense.

Please confirm that this message was erroneous. Based on the above, it seems likely that this message was sent out before you actually had the new version released. Hopefully you see how this contradiction could be confusing (but very forgiveable of course.)

One other request: please be 120%+ certain that the new version is signed with the proper signatures. If a new version comes out after this exploit, and it is not properly signed, it will erode trust in Bisq. (Even more than the previous time the key changed with no notice, whcih is still a serious concern!)

6

Forcing trades to have a nonexistent version was the trick used to stop the attack. The new version will be 1.10, is going to be released in the next hours/days and will be announced properly.

Signatures will be from regular developers.

1 Like
7

Thanks for replying, but you did not answer my question. Can you please confirm that the message that contained the text “a mandatory update was released” was erroneous? I am still seeing that message, but there is no new version. So it would appear to have been an erroneous message (ie - it says there is a new version, but there is not - present tense.)

Signatures will be from regular developers.

This is disconcertingly vague. There could be any number of “regular developers.” Ever since the (very scary, improperly managed, and to-date cryptographically unsound) switch to the new signing key, Bisq downloads have been signed by the following key:

B493319106CC3D1F252E19CBF806F422E222AA02
Alejandro GarcĂ­a alejandro.garcia@disroot.org
sub rsa4096/0xE7F08D07C72561D0 2022-09-28 [E] [expires: 2026-10-03]

Please be sure that v1.10 is also signed by this key (which expires soon, something else to note) or there will be every reason to believe that Bisq has been compromised, given the combination of the exploit and the change in key.

Thank you for all of your hard work fixing this problem. I appreciate it will take time to identify the problem, design a solution, create and package the solution, sign the solution with the proper key (fingerprint B493319106CC3D1F252E19CBF806F422E222AA02) and distribute it. Slow and proper is better than rushed and improper, and I am happy to wait.

1 Like
8

I too received the ‘new version’ message this morning [5/13/26]. The application has been left open for over a week & generated the [new version] message on its own without any action on my part - which is disconcerting.

1 Like
9

Thank you for speaking up. Yes it is concerning. Of course it is not as concerning as what @suddenwhipvapor said about GPG keys here: Update 3 about Bisq Exploit response - #4 by hardheadarea

The disconcerting part isn’t that the message was generated on its own though, right? That is to be expected. The part that is of concern is that the message did not match what was really happening. So it makes one wonder if the team that is doing the work, is the team that controls messaging (or if that was a part of the exploit, trying to get people to upgrade to their version.)

10

The ‘on its own’ reference was meant to clarify that ‘opening the application’ was not the source of the message’s generation as was reported in your post. I agree that the discovery of ‘who’ was behind the untimely generation of the message is of paramount importance.

1 Like
11

Releases are signed by one of the two release managers, and HenrikJannsen is a release manager.

Please stop spreading unfounded concerns.

Update 3 about Bisq Exploit response
12

Also, the reason for the “new version” popup message has been explained in the communications and updates sent to x, nostr, this forum, telegram and matrix.

For your benefit, I will explain the rationale here, yet again:

Requiring that a “new version” (that did not really exist at the time) be installed to be able to trade, was an effective workaround to disable trading altogether, exactly because said version did not exist, so no trader could make or take offers on the platform.
It was exactly thanks to that workaround that the damage was contained to something over 11btc and 10 makers, rather than spreading to many more users and amounting to a much larger sum.

1 Like
13

That had nothing to do with the exploit.

The message that appears was the way the devs tricked the software to stop the exploit from draining traders funds.

14

Huh? How did the phrasing trick the software? That makes no sense. The phrasing used the past tense to refer to the new version, and my question was simply: why did you use the past tense if the version wasn’t out yet? It was a simple question, which no one has answered yet. If the devs knew the new version was unreleased, why didn’t the message say that? It’s a simple question, but no one will answer it. The answer might be as simple as “we thought we had the new version ready, but we were wrong.” Okay, no problem, that would make sense. So why not just say what the actual answer is?

Also: are you a dev, or are you just guessing?

Yes, it has been, and I have pointed out how it is inadequate. I have asked a specific question (three times) regarding that inadequacy (four, including above), and although I expected a quick and easy reply, you have avoided the question, and then said you will not discuss it further, and I even see a veiled threat. This is not how one responds when they are serious. You have made a simple explanation look like a misdeed on the devs’ end. I still assume you did not mean to do this, but you have.

Specifically, you have not explained why the message used the past tense to refer to the new version. The app wasn’t reading your english language message, right? It’s a great app, but I assume it’s not sentient. The message could have said what you are saying now, which is something like “Bisq v1.9.22 has been tricked into expecting a new version, which we will release as soon as possible.” Instead, the app has one message that the new version had already been released, but you, here (and on matrix, and telegram, as you point out) are saying something different - and you refuse to explain that difference. This is sketchy at best. It would have been such a simple thing to explain. Are you hiding something, or just do not like questions? You have turned a simple query into a potential crisis.

15

User suspended for combative behavior and failure to follow staff guidance.

1 Like
16

This may be an error. Maybe they’ve used this wording as taken from previous messaging and did not have a lot of time to read while under a lot of stress. I don’t care if it’s an error or if they’ve used past tense when there was not a new version released yet.

I care that new released will be signed as usual, and they have reviewed it carefully.

No, I’m not. But not only I have been able to ask them significant questions about the exploit, but I have also read the same statements you have.

1 Like