· Alex · security  · 3 min read

All You Need To Know About CVE-2022-3602 & CVE-2022-3786

Technical details about CVE-2022-3602 & CVE-2022-3786

The OpenSSL organization finally released version 3.0.7 of its famous cryptographic library. The InfoSec community waited for this release for a week, as OpenSSL gave organizations a head-start by announcing the patching of a Critical security vulnerability. Now we finally have more details. This article attempts to summarize everything that you need to know about CVE-2022-3602 and CVE-2022-3786 .

CVE-2022-3602 & CVE-2022-3786

  • Both vulnerabilities are buffer overruns that can be triggered during X.509 certificate verification, specifically in name constraint checking of the certificate email field.
  • Issues happen after certificate chain signature verification. So exploitation requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer.
  • Severity: High (3602 was downgraded from the initial Critical severity).
  • Both vulnerabilities can be triggered in:
    • a TLS client (when the server is malicious).
      • To exploit a TLS client you would have to make a user or application connect to a malicious TLS server that sends over a crafted certificate.
    • a TLS server (when using mutual TLS and the client is malicious).
      • To exploit a TLS server you would have to configure the TLS client to use a crafted certificate. Fortunately, mutual TLS is not used that frequently in the web context.
  • Impact:
    • OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to both issues.
    • OpenSSL 1.1.1 and 1.0.2 are not affected.
  • Mitigation: OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7


  • An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution.
  • Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler.
  • Exploitation could be easier on platforms that don’t use memory mitigations such as ASLR or DEP/NX.
  • No public exploit exists at the time.


  • An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the ’.’ character (decimal 46) on the stack.
  • This buffer overflow could result in a crash (causing a denial of service).

Detecting what version of OpenSSL you have

OS level

To see what version you have at the OS level, just type:

openssl version

Application level

At the application level, it can be more difficult to detect what you’re using. There are 2 situations:

  • Applications that ship OpenSSL as a set of libraries (dynamically linked) - these can be either .so (Linux) or .dll (Windows). These are usually called libcrypto (handles cryptographic algorithms like RSA, AES, etc) and libssl (handles TLS implementations).
  • Apps that embed OpenSSL (statically linked) - in this case, libraries are embedded into the main executable and it’s more difficult to detect. A possible way is to search/grep for the “OpenSSL” string using bash strings command (Linux) or SysInternals Strings (Windows).

See the OpenSSL advisory here.

About the Author:


Application Security Engineer and Red-Teamer. Over 15 years of experience in Application Security, Software Engineering and Offensive Security. OSCE3 & OSCP Certified. CTF nerd.

Back to Blog

Related Posts

View All Posts »
A Comprehensive Guide to Types of Penetration Tests

A Comprehensive Guide to Types of Penetration Tests

Let's discuss about pen tests: from black box to white box to gray box testing, internal vs external, delved into social engineering, red, blue and purple teaming, importance and how to choose what's right for your organization.