Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchA proof-of-concept exploit for OpenSSL CVE-2020-1967 was reported publicly on 5 May 2020, but the bug did not make every server running an affected OpenSSL release vulnerable. A crash was possible only when an application used OpenSSL 1.1.1d, 1.1.1e, or 1.1.1f and called SSL_check_chain() during or after a TLS 1.3 handshake. OpenSSL fixed the issue in 1.1.1g, released on 21 April 2020.
What is CVE-2020-1967?
OpenSSL’s official vulnerability record calls CVE-2020-1967 “Segmentation fault in SSL_check_chain.” In affected applications, mishandling the TLS 1.3 signature_algorithms_cert extension could lead to a NULL pointer dereference when a peer supplied an invalid or unrecognised signature algorithm. The application could crash, creating a denial-of-service condition.
The failure depended on a particular API call, not simply on whether OpenSSL was present. The OpenSSL advisory says server or client applications calling SSL_check_chain() during or after a TLS 1.3 handshake could crash. OpenSSL credits Bernd Edlinger with finding the vulnerability using a GCC static code analyzer. OpenSSL’s CVE-2020-1967 advisory describes the defect and its scope.
Which OpenSSL versions were affected?
OpenSSL lists versions from 1.1.1d up to, but not including, 1.1.1g as affected. Versions before 1.1.1d are not affected by this issue.
#1 Best Overall
| Upstream OpenSSL release | CVE-2020-1967 status |
|---|---|
| Before 1.1.1d | Not affected by this issue, according to OpenSSL. |
| 1.1.1d, 1.1.1e, 1.1.1f | Affected releases; application exposure also depends on calling SSL_check_chain() in the relevant TLS 1.3 handshake context. |
| 1.1.1g | Fixed release, published 21 April 2020. |
The release range describes upstream OpenSSL. Operating-system and software vendors may backport security fixes without changing the displayed upstream version. Check the security notice for the specific package or product rather than relying on a version string alone; the OpenSSL advisory does not document package-specific backports.
Does the vulnerability affect every TLS server?
No. An application needed both an affected OpenSSL version and code that called SSL_check_chain() during or after a TLS 1.3 handshake. Security researcher Imre Rad told SecurityWeek that this API use was not common and that, in his view, the vast majority of TLS servers did not call it. That is his reported assessment, not a measured prevalence study.
The vulnerable code path was not limited to servers. SecurityWeek reported Rad’s view that a malicious TLS server could induce a vulnerable client to connect, while a malicious payload could be sent to a vulnerable server using a patched openssl s_client utility. Rad also said mutual TLS did not protect the server-side code path. These are reported attack scenarios; they do not establish that all clients, servers, or mutual-TLS deployments were exploitable. SecurityWeek’s 5 May 2020 report covers the PoC and Rad’s account of the conditions.
Was a proof-of-concept exploit released?
Yes. SecurityWeek reported on 5 May 2020 that Imre Rad had published a proof of concept and an explanation of the exploitation process. The report described sending a malicious payload to a vulnerable server with a modified openssl s_client utility. The existence of that PoC demonstrates a reported way to trigger the flaw under the required conditions; it is not evidence that every OpenSSL-based service could be crashed or that a particular number of systems were affected.
Free tools Windows power users keep installed
One-click scans. No signup required.
How to check and remediate a possible exposure
- Identify the OpenSSL component in use. Check the application’s actual linked or bundled OpenSSL library and its upstream version. A system-wide version command may not reveal a copy embedded in an application.
- Check vendor patch status. If the component appears to be 1.1.1d, 1.1.1e, or 1.1.1f, consult the operating-system or application vendor’s security notice to determine whether a fix was backported.
- Determine whether the application calls
SSL_check_chain(). Review the application’s code, vendor documentation, or maintainer guidance. The version by itself does not establish exposure. - Install the applicable fixed update. Use OpenSSL 1.1.1g or a vendor package that includes the fix, following the vendor’s supported update procedure.
For this specific vulnerability, the relevant axes are the OpenSSL component version, vendor patch status, use of SSL_check_chain(), and whether the application acts as a TLS server or client. The OpenSSL advisory and SecurityWeek report do not provide a count of exposed systems or independently measured exploitation statistics.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
