Few vulnerabilities generated as much pre-disclosure anxiety as CVE-2022-3602. OpenSSL took the unusual step of pre-announcing a CRITICAL fix a week ahead of release, and because the last time OpenSSL rated something critical was Heartbleed, the industry braced for another internet-wide emergency. When the details landed, the picture was more nuanced. CVE-2022-3602, along with its sibling CVE-2022-3786, is a stack buffer overflow in OpenSSL's X.509 certificate handling, and both were ultimately rated HIGH rather than critical. Understanding why the severity moved, and why the panic mostly did not pan out, is a useful lesson in how exploitability, not just impact, should drive your response.
Timeline and impact
OpenSSL announced on October 25, 2022 that a critical fix would arrive on November 1. On release day, the project published both CVEs together in OpenSSL 3.0.7 and, based on a week of testing by partner organizations, downgraded CVE-2022-3602 from CRITICAL to HIGH. The reasoning: on the most common platforms and build configurations, stack-layout details and compiler protections made the four-byte overflow implausible to turn into code execution, leaving denial of service as the realistic outcome.
The scope was also narrower than Heartbleed's. The vulnerable code was introduced in the OpenSSL 3.0 series, so the enormous installed base still on OpenSSL 1.1.1 was not affected at all. Combined with the specific conditions needed to trigger it, the real-world exploitation that many feared never materialized. Still, OpenSSL 3.0 shipped in newer Linux distributions and countless container images, so patching was a genuine, if less frantic, fleet-wide exercise.
Root cause
Both bugs live in the punycode decoding OpenSSL performs during X.509 certificate verification, specifically while checking name constraints. Punycode is the encoding used to represent internationalized (non-ASCII) domain names in an ASCII-safe form. When OpenSSL processes a certificate containing an internationalized email address in a name-constraint check, it decodes the punycode into a fixed-size buffer on the stack.
The decoding routine did not correctly bound how much it wrote:
- CVE-2022-3602 is an off-by-one error that lets a crafted email address write exactly four attacker-controlled bytes past the end of the stack buffer.
- CVE-2022-3786 lets a crafted email address overflow the buffer with an arbitrary number of period ("
.") characters, which the attacker does not control the value of, making it a denial-of-service primitive rather than a code-execution one.
The exploitation conditions are what tamed the severity. The overflow happens during certificate verification, so to reach it an attacker generally needs either a certificate signed by a trusted CA that carries the malicious name, or an application (typically a TLS client, or a server configured to request and verify client certificates) that continues processing a certificate even after chain verification has failed. That is a meaningfully higher bar than "send one packet to any listening server."
Which versions were affected
CVE-2022-3602 and CVE-2022-3786 affected OpenSSL 3.0.0 through 3.0.6. OpenSSL 1.1.1 and the 1.0.x lines are not affected, because the vulnerable punycode name-constraint code was added in the 3.0 series. The fix is OpenSSL 3.0.7.
Detection
- Inventory every place OpenSSL 3.0.x is present, and distinguish it from 1.1.1, which is not affected. This includes system packages, statically or dynamically linked application dependencies, and language runtimes that bundle their own OpenSSL.
- Scan container images specifically. Many images built on newer base distributions picked up OpenSSL 3.0.x, and a stale layer can carry a vulnerable copy long after the host is updated.
- Do not rely on the host package alone. Applications frequently vendor or statically link OpenSSL, so a build-artifact-level composition scan is the only reliable way to find every copy.
- Compare each located OpenSSL against the 3.0.7 threshold.
Remediation and patched versions
Upgrade OpenSSL to 3.0.7 or later everywhere the 3.0.x series is present. On supported distributions the fix arrives through a normal package update; for container images, rebuild against an updated base so the fix persists across redeploys, and re-scan statically linked binaries that bundle their own copy. Where an immediate upgrade was not possible, the interim guidance recognized that clients are the primary exposure (they routinely verify server certificates from many sources), while servers are only exposed when configured to request and verify client certificates, so temporarily disabling client-certificate verification could reduce a server's exposure until patched. The durable fix is simply to be on 3.0.7 or later.
How Safeguard helps
The hardest part of a bug like CVE-2022-3602 is not fixing it, it is finding every copy of OpenSSL 3.0.x hiding in your estate, including the ones statically linked into binaries and buried in container layers. Safeguard's software composition analysis resolves your dependencies down to precise versions, including vendored and transitive OpenSSL, and tells you which copies are 3.0.x (affected) versus 1.1.1 (not affected), so you patch what actually matters instead of chasing false alarms. Container scanning does the same for image layers, and when a safe version exists, autonomous auto-fix opens a tested pull request that moves you to a patched release. Developers catch it before merge with the Safeguard CLI. And because the story here is really about exploitability, the Safeguard vs Snyk comparison covers how reachability and context change which findings deserve your attention first.
Precise version identification is what separates a calm patch cycle from a fire drill. Get started free or read the documentation.
Frequently Asked Questions
Was CVE-2022-3602 as bad as Heartbleed?
No. Despite being pre-announced as critical, it was downgraded to high on release because the four-byte stack overflow was not plausibly exploitable for code execution on common platforms, leaving denial of service as the realistic impact. It also affected only the OpenSSL 3.0 series, sparing the large installed base still on 1.1.1, and required specific conditions to trigger. Heartbleed, by contrast, was a trivially exploitable, unauthenticated memory-disclosure bug across a vast footprint.
Which OpenSSL versions are affected by the punycode overflows?
CVE-2022-3602 and CVE-2022-3786 affect OpenSSL 3.0.0 through 3.0.6. OpenSSL 1.1.1 and the 1.0.x lines are not affected, because the vulnerable punycode name-constraint code was introduced in the 3.0 series. The fix is OpenSSL 3.0.7 or later. Because the two lines look similar, verifying whether a given copy is 3.0.x is the key step.
What conditions are needed to trigger the vulnerability?
The overflow occurs during X.509 certificate verification, in punycode decoding of an internationalized email address while checking name constraints. To reach it, an attacker generally needs a certificate signed by a trusted CA carrying the malicious name, or an application that keeps processing a certificate after chain verification has already failed. TLS clients are the primary exposure; servers are only exposed when they request and verify client certificates.
How do I find every copy of OpenSSL in my environment?
Do not rely on the operating-system package alone, because applications and language runtimes frequently vendor or statically link their own OpenSSL, and container images can carry copies in individual layers. Use build-artifact-level software composition analysis and container scanning to enumerate every embedded and transitive copy with its exact version, then compare each against the 3.0.7 threshold to identify what actually needs upgrading.