On October 25, 2022, the OpenSSL Project sent out a notice that stopped security teams mid-sprint: a CRITICAL-severity advisory was coming in the fixed release, 3.0.7, due November 1. For a project that had issued exactly one other CRITICAL rating in its history — Heartbleed, CVE-2014-0160 — that word triggered a week of war-room prep across the industry. When 3.0.7 actually shipped, the two vulnerabilities it fixed, CVE-2022-3602 and CVE-2022-3786, landed at HIGH. CVE-2022-3602 carries a CVSS 3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H per NVD) and is tracked under CWE-787, Out-of-bounds Write. Both bugs live in OpenSSL's punycode decoder, used when verifying X.509 certificate name constraints against internationalized email addresses, and both affect only OpenSSL 3.0.0 through 3.0.6 — the 1.1.1 branch, still widely deployed in 2022, was never affected. This post walks through what the overflow actually does, why the severity dropped between pre-announcement and release, and what a safe upgrade to 3.0.7 (or later) actually involves in practice.
What does the buffer overflow actually do?
CVE-2022-3602 is a stack buffer overflow in OpenSSL's ossl_a2ulabel() function, part of the punycode decoding logic used when an X.509 certificate contains an internationalized domain-style email address subject to name-constraint checking. NVD's description states that a crafted email address in a certificate can overflow four attacker-controlled bytes on the stack. Four bytes is a narrow window — not the kind of overflow that hands an attacker a clean, reliable shellcode landing pad the way a larger heap overflow might. The sibling bug, CVE-2022-3786, is a related overflow in the same punycode-handling code path triggered by inserting a large number of . characters into the crafted email address; it causes an attacker-controlled amount of stack memory to be overwritten with the . character itself, which is a denial-of-service primitive rather than a code-execution one. Both bugs require the target application to actually reach the punycode name-constraint check during certificate verification.
What has to be true for either bug to be exploitable?
Exploitation depends on the application's own certificate-handling logic, not just the OpenSSL version. NVD lists three practical triggering paths: a malicious TLS server presenting a crafted certificate to a connecting client, a malicious TLS client presenting a crafted certificate during client-certificate authentication on a server, or a certificate signed by a trusted CA that happens to contain the crafted email address. Critically, name-constraint checking with punycode-encoded email addresses only fires under specific conditions — the certificate chain must include a name constraint, and in some deployments the vulnerable code path is only reached when certificate path building fails and the application chooses to continue verification anyway rather than abort. That's a meaningfully narrower attack surface than "any TLS connection with a vulnerable OpenSSL is exploitable," and it's one reason the eventual severity landed well below the pre-announcement.
Why did OpenSSL downgrade the severity from critical to high?
The downgrade happened during the embargo period, before public release, once OpenSSL's own engineers and outside researchers had working proof-of-concept exploit attempts against the pre-release patch. According to NVD's severity history for CVE-2022-3602, the CRITICAL pre-announcement was revised to HIGH after analysis found mitigating factors: modern stack-protection mechanisms — stack canaries, non-executable stack pages, and ASLR, which are default-on across most current Linux distributions and compilers — made reliable remote code execution significantly harder to achieve than a four-byte overflow might otherwise suggest. The overflow's exploitability also turned out to be heavily dependent on compiler choice, stack layout, and calling convention, meaning a working exploit on one build wouldn't necessarily transfer to another. OpenSSL's own advisory language shifted accordingly: the bug was still real, still remotely triggerable, and still capable of denial-of-service or, on some platforms, code execution — but not the kind of platform-agnostic, drop-in-and-detonate flaw Heartbleed was in 2014.
Which systems were actually at risk?
The affected range — OpenSSL 3.0.0 through 3.0.6 — was narrower than the initial panic suggested, but far from trivial. OpenSSL 3.0.0 shipped in September 2021, so any Linux distribution or container base image that had adopted the 3.0 branch by late 2022 was in scope; the far more widely deployed 1.1.1 branch, still supported and common in enterprise environments at the time, was unaffected because its punycode implementation predates the 3.0 rewrite. Distribution maintainers moved fast: Fedora, Gentoo, and network-appliance vendors including Cisco, NetApp, and SonicWall published their own advisories referencing the same CVE, per the reference list on NVD's record. The real-world blast radius mattered less for "how many servers run OpenSSL" and more for "how many of those servers do name-constraint checking on client certificates or connect out to untrusted TLS servers" — a smaller, but non-zero, population.
What does patching safely actually involve?
The fix landed in OpenSSL 3.0.7, released November 1, 2022, and the immediate step for anyone on 3.0.0–3.0.6 is upgrading to 3.0.7 or later. The practical complication is that OpenSSL is rarely a direct application dependency — it's usually a transitive one, compiled into a base container image, linked by a language runtime's TLS bindings, or bundled by a package manager several layers below the application manifest a typical SCA scan reads. A scan that only checks requirements.txt or package.json will miss an OpenSSL 3.0.x baked into an OS layer entirely. Safeguard's dependency graph resolves transitive chains to 100 levels deep across ecosystems, including container layers, specifically to catch native libraries like this that sit below the application-manifest boundary rather than in it. Once a vulnerable OpenSSL build is identified, the actual upgrade for compiled or containerized services means a base-image bump and a rebuild, not a simple lockfile edit — which is why Griffin AI's remediation flow in Safeguard flags dependency upgrades by breaking-change risk tier (Safe, Minor, Major, Critical) before generating a fix PR, so a native-library bump that requires a rebuild and test pass doesn't get treated the same as a routine minor-version dependency bump.