When David Johansson dug into the Socket.IO client code, he found a mistake in the configuration-handling code of the engine.io-client module. The mistake stemmed from an assumption in the way Node's TLS module functions when handling the rejectUnauthorized setting. According to the principle of secure defaults, the configuration-handling code in the TLS module should be written in such a way that an error results in a secure configuration. However, that wasn't the case. The TLS module in Node.js essentially defaults to an insecure configuration by default. From a design perspective, this is exactly the opposite of what you'd want to do when you get a bad certificate. The worst part is that due to the nature of the configuration option, you would never know that your configuration was insecure, since when Node is configured to accept invalid certificates, it won't log that certificates are invalid. You can check out the technical details of the flaw in David's post, Node.js and Socket.IO: How security fails when 'null' is 'false'.
This chain of vulnerable design and improper implementation is difficult to detect in code, unless you have all the dependency code you're using within the scope of a review. So these types of flaws can often slip through the cracks and go unnoticed for days, months, or even years. In a world where bad actors are constantly on the lookout for ways to intercept encrypted communications, this once-overlooked classification of flaw is now at the center of one of the most important and impactful debates in the history of the Crypto Wars.
A quick Google search shows around 2,000 package.json files that import the socket.io-clientlibrary. This indicates that potentially hundreds of frameworks, libraries, and open source applications today could be vulnerable to this man-in-the-middle attack. Given the nature of the design flaw in Node.js that leads to this problem (principle of secure defaults) and the probability that other frameworks using the TLS module are making the same mistake, I would rate this a higher likelihood than I would do otherwise.
Overall, this can serve as a lesson in secure software design, the importance that frameworks play in modern software, and especially the impact that a framework vulnerability and a responsive development community can have on the global state of application security.