What happened
On 25 October 2022, the OpenSSL Project pre-announced, as its policy requires for serious issues, that version 3.0.7 would fix a vulnerability it rated Critical, without yet disclosing details. The announcement drew wide attention because a Critical rating from OpenSSL, used across much of the internet's encrypted traffic, is rare. When the project published its security advisory and released 3.0.7 on 1 November 2022, it disclosed two buffer-overflow flaws in how OpenSSL 3.0.0 through 3.0.6 verify punycode-encoded email addresses in X.509 certificates, CVE-2022-3602 and CVE-2022-3786, and rated both High rather than Critical. Both require either a malicious certificate signed by a trusted certificate authority or a client that continues verification after a trust-chain failure, and the project's own explanation of the downgrade said testing during the pre-notification period showed that common stack layouts and standard platform protections made a crash, rather than remote code execution, the likely outcome on most systems.
Confidence and limits
The advisory and the project's own blog post are the primary record of both the vulnerabilities and the reasoning for the severity change; no outside verification of the internal testing is available, only the project's account of it. OpenSSL 1.1.1 and 1.0.2, still in wide use at the time, were stated as unaffected, a fact this article treats as accurate per the advisory but has not independently confirmed against every downstream distribution.
Why it mattered
The week between the Critical pre-announcement and the High-rated release triggered a burst of emergency patching activity, inventory scrambling and public speculation about a second Heartbleed, activity that a calmer, more measured response might have avoided had the initial severity held. The episode is now a reference case for a specific problem: a pre-notification, by design, withholds detail to prevent early exploitation, which means organizations must decide how urgently to prepare before they can see the actual scope of what they are preparing for.
Defensive takeaway
Maintain a current inventory of where OpenSSL 3.x is deployed before the next pre-notification arrives, so that when one does, your organization can assess real exposure quickly rather than reacting to the announced severity alone.
- Do you know which of your systems run OpenSSL 3.0.x specifically, as distinct from the still-common 1.1.1 branch?
- Does your patching process distinguish between a pre-notification's provisional severity and a released advisory's confirmed rating?
- Would your organization have patched unnecessarily disruptive systems during the pre-notification week, before the actual conditions for exploitation were known?
The vulnerabilities were real and worth patching, and the project's downgrade was a correction based on further testing, not a retraction. The more durable lesson is about process: acting on a pre-announced severity is sometimes necessary, but it is provisional by design, and the final advisory is the document that should govern any lasting judgment about the incident.