The OpenSSL project has rolled out fixes to contain two high-severity flaws in its widely used cryptography library that could result in a denial-of-service (DoS) and remote code execution.

The issues, tracked as CVE-2022-3602 and CVE-2022-3786, have been described as buffer overrun vulnerabilities that can be triggered during X.509 certificate verification by supplying a specially-crafted email address.

“In a TLS client, this can be triggered by connecting to a malicious server,” OpenSSL said in an advisory for CVE-2022-3786. “In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.”

OpenSSL is an open source implementation of the SSL and TLS protocols used for secure communication and is baked into several operating systems and a wide range of software.

Versions 3.0.0 through 3.0.6 of the library are affected by the new flaws, which has been remediated in version 3.0.7. It’s worth noting that the commonly deployed OpenSSL 1.x versions are not vulnerable.

Per data shared by Censys, about 7,062 hosts are said to run a susceptible version of OpenSSL as of October 30, 2022, with a majority of those located in the U.S., Germany, Japan, China, Czechia, the U.K., France, Russia, Canada, and the Netherlands.

While CVE-2022-3602 was initially treated as a Critical vulnerability, its severity has since been downgraded to High, citing stack overflow protections in modern platforms. Security researchers Polar Bear and Viktor Dukhovni have been credited with reporting CVE-2022-3602 and CVE-2022-3786 on October 17 and 18, 2022.

The OpenSSL Project further noted the bugs were introduced in OpenSSL 3.0.0 as part of punycode decoding functionality that’s currently used for processing email address name constraints in X.509 certificates.

Despite the change in severity, OpenSSL said it considers “these issues to be serious vulnerabilities and affected users are encouraged to upgrade as soon as possible.”

Cybersecurity firm Rapid7 pointed out that “exploitability is significantly limited,” as the flaws occur “after certificate verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.”

“Specifically, implementations that are configured for mutual authentication, where both the client and the server are providing OpenSSL-provided certificates for authentication, should definitely be fast-tracking this update,” Tod Beardsley, director of research at Rapid7, said.