CVE-2018-17144 Bitcoin… That was close.

Sep - 27

CVE-2018-17144 Bitcoin… That was close.

It all started with an innocent alt-coin contributor testing his code in his van by the beach. He noticed that some tests didn’t pass and alerted the Bitcoin core team.
Bitcoin core team was quick to react and patch the critical vulnerability, however they only disclosed half of the truth about the bug when releasing the patch to the public. From the words of bitcoin unlimited contributor who discovered the bug:

This 600 microsecond optimization now resulted in CVE-2018–17144. Certainly the most catastrophic bug in recent years, and certainly one of the most catastrophic bugs in Bitcoin ever.

Initially CVE-2018-17144 was presented as a patch for DoS attack on bitcoin network, while in reality it fixed a more severe inflammation vulnerability that would allow creation of new bitcoins by bitcoin miners bypassing the blockchain rules. In theory, the bug could have led to a malicious miner inflating the bitcoin supply by producing a malicious block with transactions containing double-spent coins (“inputs”).

  • Anyone running a recent Bitcoin Core (0.15.0 through 0.16.2) versions would have accepted the malicious block, creating a dirty blockchain with a inflated supply of bitcoin.
  • Anyone running an older (0.14.0 through 0.14.2) version of bitcoin core would have crashed their node when receiving a block from a malicious miner. Only this last outcome of the bug (node crash) was initially made public by bitcoin core team and explained as Denial of Service (DoS) vulnerability when publishing the patch.

Once more than 50% of bitcoin core users applied the patch, Bitcoin Core team fully disclosed all aspects of the vulnerability on Sept 20th in this statement.

Isn’t blockchain designed to prevent Inflammation?

Yes, blockchain technology is designed to prevent exactly that: the Inflammation of coin supply. But the implementation of blockchain software that runs on individual nodes was created by developers who sometimes make mistakes. One of those mistakes was made while trying to improve the performance of bitcoin nodes in Nov 2016.

This is taken from Pull Request #9049 that was included in Release 0.14.0 of Bitcoin core:

As displayed above a developer has introduced an ability to skip validation of transaction with duplicate inputs (“coins”) by assuming that this check is already being made somewhere else in the code. This code change was reviewed and approved by at least 2 other bitcoin core contributors who have failed to test whether the validation is actually being performed. This code change has introduced as part of update on March 2017 and remained a part of Bitcoin Core and all platforms that rely on it (BCH, BTC) until Sept, 2018, roughly 18 months.


The vulnerability was never attempted to be exploited by any of the miners in 18 months. Mainly because nobody has been known to discover it and the high price one had to pay to attempt exploitation. If a miner were to try to exploit it, they would need to risk forfeiting 12.5 BTC (~$80K) reward to generate a malicious block. The attack would have been immediately noticed by bitcoin community and most of the miners would have upgraded their node software to reject the chain with malicious block and continue mining on on-compromised clean blockchain. The incident however would have had a high impact on the price of BTC and other crypto-currencies and the overall trust society puts into crypto.

The Fix

Here is the fix that bitcoin core team produced in Release 0.16.3 on Sept 18, 2018:

In the code above a simple 4 letter fix (true instead of false) was produced and the automated test was added to test the scenario of the block with duplicate coin (“input”) spend.

As you can see both the bug and the fix were very simple: just one flag that enables/disables the validation. The source of confusion that caused this bug originated in the assumptions made by people who wrote and reviewed the code. It is clear that code review process is not infallible not just at Bitcoin Core but in many organizations and open source projects. The common solution is covering the code with automated tests, but still, the tests are written by developers and they decide which scenarios to test. The quality of testing lies in variation and creativity of the person performing it.


In general we all have a high degree of confidence in highly automated fool-proof systems like blockchain, cloud infrastructure and software in general. But it’s important to understand that all these valuable technologies are being developed in an environment where human error element is still present. Having an infallible process that prevents human error in production of automated system(s) is one of the biggest challenges humanity is trying to solve in the modern age.

If you have any questions

Security assessment and penetration testing are becoming an integral part of SDLC, the quality of testing remains largely dependent on the curiosity and creativity of individuals who perform the test.

Should you have any questions about this incident or risk re-mediation plan for your company, feel free to ping me on LinkedIn or schedule a free assessment call.



Leave a Reply

Your email address will not be published. Required fields are marked *