In late October 2022, the OpenSSL Project did something it had never done before: it pre-announced a "Critical" severity patch, evoking immediate comparisons to Heartbleed. A week later, the actual fix landed as OpenSSL 3.0.7, patching two related buffer overflow flaws — CVE-2022-3602 and CVE-2022-3786 — in the punycode decoder used during X.509 certificate name-constraint checking. By release day, OpenSSL had downgraded both to High severity after further analysis showed exploitation to remote code execution was implausible on most common platforms. The pair nonetheless represents a real stack-overflow risk in certificate parsing code that touches a huge swath of the internet's TLS stack, and it's a useful case study in how vulnerability severity can shift dramatically between disclosure and patch.
What the vulnerabilities actually are
Both bugs live in OpenSSL's punycode decoding routines (ossl_punycode_decode and ossl_a2ulabel), which convert internationalized domain-style "xn--" encoded labels found in an X.509 certificate's email address name constraints back into readable form. This code path was introduced in OpenSSL 3.0.0 and did not exist in the 1.1.1 or 1.0.2 branches — which is why those older, still widely deployed branches were unaffected.
- CVE-2022-3602 is an off-by-one error that allows an attacker to trigger a 4-byte buffer overflow on the stack. Because only 4 bytes overflow and the content is partially attacker-influenced, early reports treated this as a potential path to remote code execution — hence the initial "Critical" label.
- CVE-2022-3786 is a variable-length stack buffer overflow. An attacker can overflow the buffer with an arbitrary number of
.(period, decimal 46) characters, but cannot control the content beyond that single repeated byte. Because only the length — not the content — of the overwrite is attacker-controlled, OpenSSL never considered this one a realistic RCE candidate; it was scoped as a crash / denial-of-service issue from the start.
Both are triggered when an application constructs a certificate chain that includes a CA certificate carrying a Name Constraints extension with a punycode-encoded email address, and then verifies a certificate against it. That's a meaningfully narrower trigger condition than "any TLS handshake" — it typically requires an application to explicitly enable and act on certificate chain verification involving a malicious or attacker-controlled CA/intermediate, which is why exploitation in the wild turned out to be far less trivial than the pre-announcement suggested.
Affected versions and components
- Affected: OpenSSL 3.0.0 through 3.0.6 (inclusive).
- Not affected: OpenSSL 1.1.1 and 1.0.2 branches — the vulnerable punycode code was net-new in the 3.0.x line.
- Fixed in: OpenSSL 3.0.7, released November 1, 2022.
- Affected surface: any application, library, container base image, or embedded device firmware statically or dynamically linked against a vulnerable OpenSSL 3.0.x build — this includes many Linux distributions that had recently shipped OpenSSL 3.0 as default (notably several containers built on newer base images), custom TLS-terminating proxies, and any software performing certificate chain verification with name constraints enabled.
Because OpenSSL 3.0 had only recently become the default in some distributions at the time, the practical blast radius was smaller than a decade-old LTS branch would have produced — but it was non-trivial, especially in container images and CI/CD pipelines that had pulled in fresh OpenSSL 3.0.x builds during 2022.
CVSS, EPSS, and KEV context
- CVSS v3.1: NVD scores CVE-2022-3602 at 7.5 (High) with vector
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H— network-exploitable, low complexity, no privileges or user interaction required, but impact limited to availability (crash/DoS) rather than confidentiality or integrity. CVE-2022-3786 carries a comparable High-severity rating under the same reasoning. Note that OpenSSL itself does not publish CVSS scores; these are third-party (NVD) assessments applied after the fact. - EPSS: Exploit Prediction Scoring System values for CVE-2022-3602 have hovered in the single-digit-percent range (roughly 6–8% probability of exploitation in the next 30 days as tracked historically), reflecting the narrow trigger conditions and lack of a practical public RCE exploit.
- KEV: As of this writing, neither CVE-2022-3602 nor CVE-2022-3786 appears on CISA's Known Exploited Vulnerabilities catalog. No confirmed in-the-wild exploitation has been publicly reported — the vulnerabilities remain a "high theoretical, low observed" risk, though that can change and security teams should still track KEV status over time.
Timeline
- October 17, 2022 — The underlying issue (CVE-2022-3602) is discovered and reported to the OpenSSL Project, credited to a researcher using the pseudonym "Polar Bear," with Viktor Dukhovni contributing to the fix.
- October 25, 2022 — OpenSSL issues an unprecedented pre-announcement: a Critical-severity fix is coming on November 1. This triggers a week of industry-wide "Heartbleed 2.0" speculation, emergency patching plans, and vendor advisories issued in advance of any actual technical detail.
- October 25 – November 1, 2022 — OpenSSL partner organizations and downstream vendors test the unreleased patch across common platforms and compiler/stack-protection configurations, concluding that reliable RCE is not plausible in most real-world builds.