The OpenSSL project has announced two security vulnerabilities tracked as CVE-2022-3602 and CVE-2022-3786. The good news is that these vulnerabilities are unlikely to facilitate remote code execution as originally anticipated, and only OpenSSL version 3.0.0 and later are impacted. The bad news, however, is that even though the remote control is unlikely, it’s still possible.
To learn how to protect your ecosystem and your third-party vendors from falling victim to a data breach or a ransomware attack from these OpenSSL vulnerabilities, read on.
The OpenSSL project has announced two vulnerabilities affecting OpenSSL version 3.0.0 through to version 3.0.6, with version 3.0.7 containing the critical security fixes for these vulnerabilities.
Learn more about security vulnerabilities >
Both vulnerabilities can be exploited if the following requirements are met:
Both scenarios can potentially result in a denial of service attack (DoS attack) at best and remote code injection (RCE) at worst.
Despite being downgraded from a critical rating, these OpenSSL vulnerabilities still present a significant security risk. UpGuard cybersecurity analysts have discovered over 10,000 websites running vulnerable versions of OpenSSL.
The Open SSL vulnerabilities could facilitate malware injections, meaning that every website running a vulnerable version could potentially suffer a data breach or ransomware attack.
Every website running a vulnerable version of OpenSSL risks suffering a data breach or ransomware attack.

The two OpenSSL vulnerabilities (CVE-2022-3602 and CVE-2022-3786) impact versions 3.0.0 through to version 3.0.6, with OpenSSL 3.0.7 containing the security fixes for these vulnerabilities.
OpenSSL versions prior to 3.0.0 are not impacted.
If an immediate upgrade to the patched version of OpenSSL isn’t possible, the impact could be mitigated by disabling TLS client authentication (if you have TLS servers) until security fixes can be applied.
A vulnerable version of OpenSSL could impact your IT ecosystem in three primary ways:
System-level instances are the easiest to detect. To do this, run the following command and check if your system is running a version within the vulnerable range (3.0.0 - 3.0.6)
% openssl version
In this scenario, your system could be impacted by vulnerable third-party software. You can detect if a solution is running a vulnerable version of OpenSSL by scanning its OpenSSL library (a DLL file on Windows and an SO file on Linux).
The following scanners from Github can be used for each operating system.
The OpenSSL version command above could also work for this scenario.
This level of impact is the most difficult to detect. Statically linked software compiles all Open SSL libraries in the main executable software. The are two methods of confirming whether your business is impacted at this level:
Detecting and remediating emerging vulnerabilities like these is most frustrating for the third-party attack surface. The following process will help simplify this effort.
Vendors could be impacted by domains running vulnerable versions of OpenSSL or with software running vulnerable OpenSSL libraries. The first risk is much easier to detect. This can be done with UpGuard’s vulnerability scanner.

UpGuard can rapidly confirm whether your business is impacted by domains running vulnerable versions of OpenSSL.
See UpGuard’s OpenSSL vulnerability scanner in action >
Vulnerable third-party software is harder to confirm, especially if you work with a high volume of vendors. To expedite the scanning methods outlined above, send a security questionnaire to all your vendors to request that they assess their own software for these OpenSSL vulnerabilities.
A questionnaire tailored to these new OpenSSL risks can be easily created with UpGuard’s custom questionnaire builder.
Learn about UpGuard’s custom questionnaire builder >
The combination of results from security scans and questionnaire responses will allow you to map the impact of these vulnerabilities on your organization. For each impacted asset, assign an owner who will take ownership of remediation efforts.
The remediation of critical assets - internet-facing assets and assets mapping to sensitive resources - should be prioritized. A vendor tiering strategy makes the prioritization of critical third-party vendors much easier.
Learn more about vendor tiering >
UpGuard offers a host of features to help you manage the complete cybersecurity lifecycle of OpenSSL’s two new vulnerabilities: