I've noticed a recent trend in Bitcoin-related open source projects of moving to (temporarily) closed source releases for security. This is a dangerous trend which can have dangerous long-term effects.
In this post, I want to share the dangers of this approach and how I think we should deal with these vulnerabilities, from the perspective of an open-source maintainer, security researcher and infrequent CTF player.
Daniel Stenberg, the maintainer of curl, already blogged about this topic, for example in 2025, where the curl project had to deal with a lot of "slop" reports that were not real vulnerabilities, and again in 2026, where the quality of reports got significantly better.
There's not much I can add to that, but in general, there's still lots of "researchers" out there that just spam projects with slop reports because they have absolutely no clue about computer science/programming/security. This is a huge issue for maintainers, and I've already seen maintainers make complicated code changes to "fix" issues that aren't actually issues.
I think LLMs are an opportunity for more people to do "fun" stuff in Cybersecurity rather quickly. But without an understanding of what's happening, it's hard to figure out what really is a vulnerability.
I have not interacted with the Bitcoin Red Team, but they are a team of people using AI to "scan" Bitcoin-related projects for vulnerabilities.
In general, that can be very useful. However, if vulnerabilities are not reviewed properly by people who understand what they are doing, it may overwhelm maintainers by providing them a very comprehensive report that is partially wrong or at least misrepresents issues.
I hope the team is careful with what they send to maintainers to avoid spamming people.
I want to share the two most prominent examples of "wrong handling" of security reports.
BTCPayServer is a formerly open-source payment processor mostly focused on Bitcoin as a payment method. It is very popular for accepting Bitcoin payments and is written in C#.
They recently had two releases fixing critical security issues, 2.4.2 and 2.4.3.
For 2.4.2, they chose a somewhat reasonable strategy: Publish all the code, but avoid naming the vulnerability that was fixed, instead only disclosing some smaller vulnerabilities in the announcement. While this confused some users and developers (for example, the Umbrel team claimed it was only a two-factor auth bypass in their changelog), it overall helped get the update out very quickly.
For 2.4.3, which contained a lot of smaller fixes, the BTCPay team decided on a different strategy. They released a new Docker Container btcpayserver/btcpayserver-internal with a "release candidate" that was built from a non-public repository. Only binaries were released that were only distributed as part of that container image. Their official deployment system was changed to update to that closed-source version. In the initial announcement, they promised a release within 48 hours if no more significant bugs were found. Later, it turned out that the release had a few small issues and the team decided to delay open sourcing for even longer.
Because I found this practice of just running a closed source binary concerning, I decided to reverse engineer the code. C# normally compiles to an intermediate language that is extremely easy to "decompile" (turn back into source code), for example with ILSpy. So, to figure out what changed, I ran the same decompiler on BTCPay 2.4.2 and 2.4.3.
Comparing the output between these two versions already gave me a mostly readable list of changes. I then looked through the changes and manually made the same changes in the last open source BTCPay release (2.4.2), with some cleanups applied and published all of that on GitHub. This took me approximately one and a half hours after being aware of the release. An LLM could have probably done the same much faster.
At this point, BTCPay still did not release any source code for multiple days, even though this clearly showed there is no point in keeping the code closed.
Core Lightning is an implementation of the Lightning Network in C.
On August 26, the Core Lightning team advised users to shut down their node and restart it in offline mode, and informed them of an upcoming security release that would be provided in binary form only.
On August 28, this release was finally published, with only binaries being published on GitHub with no source code available.
Again, I tried to figure out what they changed to ensure there are no backdoors.
Because Core Lightning is written in C, it is harder to "decompile" than C#. Luckily, their provided binaries included debug symbols, giving us information on which assembly instructions correspond to which C functions and even which lines in the source file.
This made it easier to reproduce the changes exactly. Because it would still be difficult to compare these binaries, I gave the task to Claude Opus 5, which completed it after a few hours and gave me a patch that allows reproducing the published binaries exactly.
At the moment of writing, their "embargo" is still ongoing, but I published code that reproduces all of the fixes here.
As demonstrated, as soon as the binaries are accessible to the public, no matter how much obfuscation you do on these binaries, the information about what changed essentially becomes public knowledge (with a very small delay in people actually figuring out the changes).
If the changes to the source code can be reconstructed, there is no benefit in keeping the information secret.
Open source and Bitcoin in particular are built on the idea of "Don't trust, verify!".
Now, maintainers, who provide the application, suddenly want users to just trust them without being able to easily verify what changed in a release. This is in clear conflict with the "don't trust, verify" approach.
You may consider breaking source code embargoes unethical. And in some parts, I can agree.
When I find a vulnerability myself, I wouldn't disclose it publicly, but report with the maintainers. If I'm involved with developing a fix, I won't share the patch publicly before its release.
I wouldn't share any source code that was confidentially provided to me.
However, this situation is different: I broke these embargos to demonstrate that they are pointless. I'm not a skilled attacker who wants to exploit this with specialized tools, I'm an average developer. And if the average person can reproduce these changes, like with BTCPay, in ~1h, or even faster, why have them at all? A skilled attacker whose goal is not to reproduce the binaries, but instead just exploit them, could find the vulnerabilities even faster.
The second benefit of breaking these embargos is helping users regain trust.
These embargos negatively affect users who don't want to run random binaries on their servers. They either need to run an untrustworthy binary or have vulnerabilities on their system that can be easily figured out by an attacker. This is very dangerous for these users.
It also negatively affects users on systems where every change is normally built from source code (like NixOS), because the packages there may not be updated until source code is published.
If we can't avoid the information leak, we need a different strategy of how to deal with vulnerabilities.
In most cases, it makes sense not to immediately push a release after receiving a report of a vulnerability.
Many projects instead collect reports to make a security release. Until that point, patches and binaries should be kept secret and only shared with people involved in the project or who discovered the vulnerability for a preliminary review.
When it's time to make a release, it is reasonable to build binaries locally first, if builds are reproducible.
This means that source code and binaries can be released at the same time, without any kind of build delay. This is very useful to help users update faster.
It may also make sense to announce to users before the release when a security release will be published, but this could also help attackers who then are aware that your app has a vulnerability, so I would avoid it.
The way maintainers in Bitcoin are dealing with security today is misguided, dangerous to open source and also completely useless.
Publishing source code alongside reproducible binaries at the same time protects everyone, not just those who blindly trust maintainers.