Responsible Disclosure

As you may be aware, Bitcoin Gold has a Responsible Disclosure policy listed on the website, which is basically a (bug) bounty program for reporting security vulnerabilities in our stable software versions or infrastructure.

It allows people to safely report an issue to us, and if they follow the rules set out in the Responsible Disclosure policy, we will not take any legal action against them in regard to the report (hacking is still illegal).

The Report

Through the end of March, we received only false reports of “non-existing” issues, which we rejected. However, we recently received the first report which our SYSOPS and CERT team could accept. Although the security issue was very minor, we acted on it directly.

It was a DLL vulnerability that affects Bitcoin and all coins that use Bitcoin’s installer methods (including BTG.) We used the fix in our recent Network Upgrade and shared it for the rest of the community’s benefit.


27 March Initial Report by Kushal Arvind Shah from Fortinet’s FortiGuard Labs
28 March Initial assessment from SYSOPS/CERT
28 March Started incident team with SYSOPS, CERT, Board and lead developer
01 April Classified the issue as LOW on usability and MEDIUM on impact
02 April Cause of issue identified and started work on fix
11 April Sent reward from the RD program to the Reporter
27 April Committed the code into master branch
29 April Added the code onto initial builds
24 May Reported the official fix of the issue
04 Jun Received confirmation from Reporter that the issue was resolved

You might have noticed there was a sizable time span between the report and the fix. That is correct: it takes time to build a fix, especially if the issue stems from a third party module and your entire build process is wrapped around it. It took a long time to test, build, and test again before we could implement the fix as a replacement for our current build process.

The Fix

The specific issue addressed by the bug was as follows: Bitcoin Gold uses the NSIS Installer module, which basically wraps our code into a nice install package for people. Our code uses the v2.46 NSIS installer module, the same as in the Bitcoin source. This outdated code had a bug in LoadLibrary: by default, it looks in the current directory of the process and into the Folder of the Executable. This is bad (especially in common use case when users execute our installer from the downloads folder) because an attacker is able to drop a DLL into the Folder of the Executable and give themselves high privileges. To try it out, just place a fake shfolder.dll (which brings up a message box in its DllMain) in the same directory as an NSIS installer and run the installer to see the message box appear. This bug has recently been found in many products and is called ‘.DLL sideloading’ or ‘.DLL hijacking’. Only Windows 7 and very old builds of Windows 8 are vulnerable. An updated Windows 8.1 or any Windows 10 system is not vulnerable.

Although the fix may appear easy (just install the new version 3.03 NSIS installer module!), it is, unfortunately, not that simple. With deterministic builds, we have to make sure the installer matches our code, which involves a lot of trial and error. Also, with our upcoming Upgrade hardfork and another update in the code, all updates needed to be added into the latest releases (as they are mandatory upgrades.)

Our developers did the careful work necessary to implement the new module into the existing build process before our next release. Any developer that is interested in how we resolved the issue can find our fix on our GitHub repo code commit, Switch to NSIS 3.03 (borrowed some code from TOR project).

The (low) Risk

To be clear, your system had to be compromised in advance for the attacker to have used this vulnerability. The installer software was not compromised, nor was our code modified or hacked. An attacker had to download a malicious .DLL file and put it in the same folder where you downloaded and run the installer. The Bitcoin Gold code, daemon and cli are not affected, nor is any Linux or Windows system (8/10) that is up-to-date. Even if you are running Windows 7, it’s unlikely that an attacker would have been able to download a malicious .DLL file into the right folder at the same moment as you launched the installer. And users would only install a (new) version once on their system.

Our recommendation: remove any and all previously downloaded installers and only use the latest version from our website or Git repository.

Because this fix was implemented well before our recent Network Upgrade on July 3rd, everyone who downloaded our software or code in preparation for the Upgrade was safe from this vulnerability.

It’s important to note that this issue is not specific to Bitcoin Gold: it can affect any coin that uses Bitcoin’s code as a basis. Some repositories, including Bitcoin itself, are currently vulnerable to this issue.

To ensure awareness of the issues and the fix, we submitted our work to the Bitcoin code repository in this Pull Request: Switch to NSIS 3.03 to avoid DLL hijacking.


The BTG team would like to thank the original Reporter (Shah from FortiGuard Labs), the TOR Project (where helpful code was sourced), and we’d like to call out the efforts of our SYSOPS and DEV teams, who managed the issue and the resolution for us. We’re happy to be able to contribute back to the Bitcoin project and provide a fix which can potentially be used by multiple projects which rely on the Bitcoin codebase.

Supporting the ecosystem,
The Bitcoin Gold Organization