Revenera logo
Image: New OpenSSL Vulnerabilities: Act Now

The OpenSSL project announced on October 25, 2022 that it was releasing OpenSSL version 3.0.7 which will patch newly discovered vulnerabilities in current versions of OpenSSL. Patches were released today.  

OpenSSL is the core open source library that implements SSL and TLS protocols which makes it possible to securely communicate over the internet. Does all of this sound familiar? Remember “Heartbleed (CVE-2014-0160)?” Multiple attacks in 2014 exploited the ”Heartbleed” software flaw in OpenSSL, allowing attackers to spy on Internet communications, steal data, and impersonate services. At that time, over 20% of the world’s servers were impacted; and to this day, we are still finding vulnerable versions of OpenSSL unpatched. 


Two vulnerabilities in OpenSSL impacting versions 3.0.0 through 3.0.6, potentially causing a Denial of Service (DoS) and in one case potentially allowing the execution of arbitrary code, have been publicly disclosed. The vulnerabilities are related to X.509 certificate validation when handling email addresses in both the TLS clients and servers. They have been assigned the identifiers CVE-2022-3602 and CVE-2022-3786 respectively and are rated as “HIGH” severity by the maintainer of OpenSSL.   

The first vulnerability, referred to as CVE-2022-3786, can be exploited to cause a buffer overflow through a specially crafted X.509 certificate. As the content cannot be controlled by a potential attacker, the only plausible impact is a DoS currently.   

The second vulnerability, represented by the identifierCVE-2022-3602, potentially allows for the execution of arbitrary code in addition to a DoS effect. While many platforms incorporate safeguards for the stack and thus mitigate any impact, code execution cannot be fully ruled out. 

Which OpenSSL Versions are Vulnerable?

Only OpenSSL versions 3.0 through 3.0.6 are vulnerable. The commonly deployed OpenSSL 1.x versions are not vulnerable to these vulnerabilities. 

Steps to Take Now

  1. We’ve said it before and we’ll keep saying it, “Know what’s in your code.” Are you utilizing Software Composition Analysis (SCA) tools such as Code Insight to scan all your applications and catalog all your open source and third-party components? Scanning solutions will help you quickly uncover the version of OpenSSL in use and which of your applications are impacted.  
  2. Work quickly. If you have SCA in place and you have been scanning, that’s a great start! Simply query your system to assess potential impact. Make sure you have a documented response mechanism within your organization so that remediation can start ASAP. Put your plan into action now. Is there a process you follow along with guidelines? Who needs to be involved (software development, security, legal, OSPO, etc.)? How do you communicate what you’re doing to your customers? 
  3. If you haven’t done so before now, generate a complete and accurate Software Bill of Materials of all components in your applications. Again, there are tools to help you do this. Understand there’s code coming from all corners such as from suppliers, vendors and other third-parties. Start today to track all the components in your software, regardless of where in the software supply chain they originated—both inside and outside your organization. Know where all components exist in your software applications and where they came from to effectively manage legal and security risk now. When the next vulnerability hits—and there will be more, unfortunately—you’ll have an accurate inventory of all your components and where they exist for faster remediation. 
  4. Check in with your vendors and third-party suppliers. Start requesting SBOMS from them and understand their policies for securing their code and helping to ensure the integrity of the software supply chain you’re all a part of. 
  5. Assume that this is not over. These types of events tend to have long tails as more exploits are typically discovered over time and additional patches may be released in the near term. 
  6. Ensure that your OpenSSL 1.x versions are also up to date (latest release was v1.1.1r 21 days ago) and are not vulnerable to a different set of security vulnerabilities.

For information regarding our products, please follow our security advisory at  

Come back here for further updates on what’s happening with these OpenSSL vulnerabilities.