· 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 »