CVE-2022-0778

What it actually does

This vulnerability is an availability flaw in OpenSSL certificate and key parsing. The BN_mod_sqrt() function can enter an infinite loop when asked to compute a modular square root using attacker-controlled, non-prime parameters. OpenSSL reaches this code path while parsing X.509 certificates, certificate requests, or private keys that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a compressed base point. Because parsing occurs before certificate signature verification or trust decisions, an unauthenticated attacker can cause a vulnerable client, server, certificate-processing service, or dependent application to consume CPU indefinitely. The impact is denial of service only: confidentiality and integrity are not directly affected.

Why it matters to the business

Successful exploitation can make services that parse untrusted certificates, certificate requests, or private keys become slow, hang worker threads, or stop responding. Exposed TLS clients, TLS servers requiring client certificates, certificate authorities, hosting control panels, databases, connectors, and certificate-management workflows may experience outages or degraded availability. The risk is elevated because exploitation is remotely reachable in common TLS and certificate-processing paths, requires no authentication or user interaction, and the EPSS score is high, although this issue is not listed in CISA KEV and is not identified as ransomware-associated. Because OpenSSL is widely embedded in applications and appliances, organizations should treat exposure as product-wide rather than limited to directly installed OpenSSL packages.

How an attack unfolds

An attacker creates a malformed certificate, certificate signing request, or private key containing explicit elliptic curve parameters with values designed to make BN_mod_sqrt() operate on a non-prime modulus. The malicious object does not need to be trusted or signed by a valid authority because the vulnerable code path is reached during parsing, before verification. The attacker then delivers the object through a path where the target parses attacker-supplied certificate material: for example, by presenting a malicious server certificate to a TLS client, presenting a malicious client certificate to a TLS server that requests client authentication, submitting a CSR to a certificate authority, uploading a certificate or private key to a hosting platform, or causing an application to parse the crafted ASN.1 EC parameters. Once parsed, the target process enters an infinite loop and consumes CPU until killed, restarted, timed out externally, or otherwise remediated. Repeated attempts can exhaust worker pools or CPU capacity and create a sustained denial of service.

How to fix it

Upgrade OpenSSL and dependent software to fixed versions. OpenSSL 3.0.0 and 3.0.1 should be upgraded to OpenSSL 3.0.2 or later; OpenSSL 1.1.1 through 1.1.1m should be upgraded to OpenSSL 1.1.1n or later; OpenSSL 1.0.2 through 1.0.2zc should be upgraded to OpenSSL 1.0.2zd or a vendor-supported backport. For source-based dependencies, ensure fixes equivalent to openssl/openssl commit e04bd3433fd84e1861bf258ea37928d9845e6a86 are present. For affected MariaDB code lines, ensure fixes equivalent to mariadb/server commit cb1316b8d213aded32aa2c1a98271eede179146d and mariadb-connector-nodejs commit 7e8696f8926ee5793bc9c73413c572f957af7e9b are present where applicable. Restart all services that dynamically link to OpenSSL after patching, and rebuild or redeploy applications that statically bundle OpenSSL. Where immediate patching is not possible, reduce exposure by rejecting externally supplied explicit-parameter EC certificates where feasible, disabling or restricting mutual TLS client certificate intake from untrusted parties, placing timeouts and resource limits around certificate-parsing workflows, rate-limiting certificate upload or CSR submission endpoints, and isolating certificate-processing workers from critical service paths.

How to confirm the fix worked

Confirm installed and bundled OpenSSL versions are fixed by checking runtime and package versions, not only development headers. Use commands such as openssl version -a and package-manager queries, and verify that applications with statically linked OpenSSL have been rebuilt against a fixed library. Validate that exposed TLS clients, TLS servers, certificate upload paths, CSR-processing systems, and private-key parsing workflows no longer use OpenSSL 3.0.0-3.0.1, 1.1.1-1.1.1m, or 1.0.2-1.0.2zc unless a vendor backport is documented. Confirm all dependent services have been restarted after patching by checking loaded library mappings for running processes. In test environments only, use a known-safe regression test or vendor test case for malformed explicit EC parameters to confirm the process rejects the input instead of entering a sustained high-CPU loop. Monitor for recurrence of unexplained high CPU during certificate parsing or TLS handshakes after remediation.

Typical attack path

1. Identify a service or workflow that parses externally supplied X.509 certificates, CSRs, private keys, or ASN.1 elliptic curve parameters using a vulnerable OpenSSL version.
2. Craft a certificate, CSR, or private key with invalid explicit elliptic curve parameters and a compressed elliptic curve point that triggers BN_mod_sqrt() with a non-prime modulus.
3. Deliver the crafted object through a reachable parsing path, such as TLS handshake certificate exchange, mutual TLS client authentication, certificate upload, CSR submission, or automated certificate inspection.
4. Cause the vulnerable process or worker thread to enter an infinite loop during parsing before certificate trust verification completes.
5. Repeat delivery or maintain connections to consume CPU, exhaust worker capacity, and degrade or deny service availability.

How to detect it

This vulnerability usually does not create a distinctive application log entry because the vulnerable process loops before cleanly returning an error. Retrospective detection should focus on symptoms and artifacts around certificate parsing. Review system and application telemetry for sustained single-thread or process CPU saturation, worker exhaustion, request timeouts, failed or incomplete TLS handshakes, and service restarts that correlate with inbound TLS connections, client-certificate authentication attempts, CSR submissions, or certificate/private-key uploads. Useful log sources include reverse proxy and load balancer logs, TLS termination logs, web application logs for certificate upload or CSR endpoints, CA/RA enrollment logs, authentication gateway logs, process supervisor logs, container orchestration events, EDR process telemetry, performance metrics, and crash/core-dump or hang diagnostics. On affected hosts, inspect stack traces, core dumps, profiler captures, or EDR thread samples for OpenSSL certificate parsing functions with BN_mod_sqrt() on the stack. Preserve any submitted certificates, CSRs, or private keys associated with high-CPU events and analyze them offline for explicit elliptic curve parameters, compressed EC points, and invalid non-prime moduli. Network detection is difficult unless full TLS handshakes or submitted certificate objects are captured, because the primary indicator is a crafted ASN.1 certificate object rather than a fixed byte string.

• BN_mod_sqrt
• EC_POINT_set_compressed_coordinates
• ossl_ec_GFp_simple_set_compressed_coordinates
• X509_get_pubkey
• PEM_read_bio_X509
• PEM_read_bio_X509_REQ
• PEM_read_bio_PrivateKey
• d2i_X509
• d2i_X509_REQ
• d2i_PrivateKey
• high CPU during certificate parsing
• TLS handshake timeout
• client certificate verification timeout
• CSR parsing timeout
• certificate upload timeout

What your security team should do

• Inventory all externally reachable and internal systems that parse certificates, CSRs, private keys, or TLS peer certificates, including appliances, agents, databases, language runtimes, containers, and statically linked applications.
• Prioritize patching internet-facing TLS services, mutual TLS endpoints, certificate authorities, hosting or control-plane certificate upload features, and automated certificate-inspection pipelines.
• Upgrade OpenSSL to 3.0.2+, 1.1.1n+, or 1.0.2zd/vendor-backported fixed builds, and redeploy applications that bundle OpenSSL rather than relying only on OS package updates.
• Restart affected services after patching and verify running processes are no longer mapped to vulnerable OpenSSL libraries.
• Add operational guardrails for certificate-processing paths, including request timeouts, worker isolation, CPU limits, upload rate limits, and queue back-pressure.
• Search historical logs and monitoring for high-CPU events, stuck TLS handshakes, certificate upload attempts, CSR parsing failures, or process restarts around certificate-handling services.
• Because the issue has a high EPSS score despite no KEV listing, treat remaining exposure as urgent for services reachable by untrusted users or networks.