The OpenSSL cryptographic library is used to provide Secure-Socket Layer (SSL) and Transport Layer Security (TLS) in many popular websites. These include Twitter, GitHub, Yahoo, Tumblr, Steam, and Dropbox.
OpenSSL isn't just used in web sites. OpenVPN, an open-source virtual private network, and older versions of the secure login and terminal program OpenSSH also use OpenSSL.
In other words, if you're running a secure server, you're likely running OpenSSL.
What went wrong with the Sept. 22 patches amounts to sloppy programming. The biggest problem, which impacts OpenSSL 1.1.0a, "resulted in an issue where if a message larger than approx 16k is received then the underlying buffer to store the incoming message is reallocated and moved. Unfortunately a dangling pointer to the old location is left which results in an attempt to write to the previously freed location. This is likely to result in a crash, however it could potentially lead to execution of arbitrary code".
If you use OpenSSL, you should immediately update to 1.1.0b
The new OpenSSL 1.0.2i also had a new, albeit not as severe, problem. In it, a C Region Library (CRL) sanity check was added to the OpenSSL 1.1.0 tree. So far, so good. But it wasn't added to OpenSSL 1.0.2i. As a result, any attempt to use CRLs in OpenSSL 1.0.2i will crash with a null pointer exception.
So, if you're using OpenSSL 1.0.2i, you should upgrade to 1.0.2j. Now.
With OpenSSL, you always need to patch quickly. Chances are everything in your server that requires security relies on OpenSSL -- and you can't afford to leave your doors wide open.
That said, the OpenSSL programmers need to make quality assurance job No. 1. Everyone makes mistakes, but the sheer sloppiness of these most recent patches -- Dangling pointers! Null pointers! -- makes me think it's time to look for OpenSSL replacements.
OpenSSL alternatives worth considering are Amazon's s2n, LibreSSL, and WolfSSL. The secure internet is too important to leave to OpenSSL given its recent track record.