OpenSSL BN_mod_sqrt infinite loop DoS (CVE-2022-0778)

On March 15, 2022, the OpenSSL Project disclosed CVE-2022-0778, an infinite-loop denial-of-service vulnerability in the BN_mod_sqrt() function used to compute modular square roots. The bug is triggered when OpenSSL parses a certificate — or, in some code paths, a private key — that uses explicit elliptic-curve parameters where the declared "prime" field value is not actually prime. Feeding such a certificate to any application that calls into OpenSSL's certificate-parsing routines causes the affected thread to spin forever, pegging a CPU core and, in many deployment topologies, exhausting the worker pool behind a TLS listener. Because certificate parsing routinely happens before any trust decision is made — a server evaluating a client certificate, a client validating a peer certificate, a proxy inspecting a chain — the vulnerability is remotely triggerable pre-authentication in a wide range of real-world configurations.

This is not a theoretical footgun. OpenSSL underpins TLS termination for a large share of the internet's servers, load balancers, mail transfer agents, VPN gateways, and embedded devices, and it is a near-universal transitive dependency in language ecosystems that shell out to system TLS libraries or bind to libssl. An infinite loop in certificate parsing is one of the more dangerous DoS shapes because it doesn't require sustained attacker bandwidth — a single malformed certificate, sent once, can hang a worker indefinitely until the process is killed and restarted.

Affected Versions and Components

CVE-2022-0778 affects the following OpenSSL branches:

• OpenSSL 1.0.2 through 1.0.2zc (fixed in 1.0.2zd) — extended-support builds only.
• OpenSSL 1.1.1 through 1.1.1m (fixed in 1.1.1n).
• OpenSSL 3.0 through 3.0.1 (fixed in 3.0.2).

The vulnerable code path lives in crypto/bn/bn_sqrt.c, inside the Tonelli-Shanks algorithm implementation used by BN_mod_sqrt(). The function is reachable from:

• X.509 certificate parsing when a certificate specifies EC public-key parameters using the explicit (rather than named-curve) encoding, with a crafted non-prime modulus.
• Private key parsing for EC keys that use explicit curve parameters, meaning key-loading utilities and CAs that ingest untrusted key material are also exposed.

Because BN_mod_sqrt() is invoked as part of routine ASN.1 certificate decoding, any application linking against a vulnerable OpenSSL version is exposed regardless of the higher-level protocol wrapped around it — TLS, DTLS, S/MIME, and any custom protocol that parses X.509 structures. This includes web servers (Apache, nginx when built against system OpenSSL), mail servers, IoT and embedded TLS stacks, Kubernetes ingress controllers, service meshes, and any Python, Node.js, Go (via cgo bindings), Java (via JNI wrappers), or Ruby application that delegates TLS handling to the system's OpenSSL library. Static or containerized builds that vendor an affected OpenSSL version are equally exposed and are frequently the last to get patched, since they don't automatically pick up OS-level security updates.

CVSS, EPSS, and KEV Context

• CVSS v3.1 Base Score: 7.5 (High) — vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The score reflects a network-exploitable, low-complexity, unauthenticated attack with no impact on confidentiality or integrity but a high availability impact — consistent with a pure DoS bug in a widely deployed, pre-auth-reachable code path.
• EPSS: Exploit Prediction Scoring System probabilities for this CVE have generally sat in the low-to-moderate band relative to the broader vulnerability population, which is typical for DoS-class bugs that require crafting a specific malformed input rather than yielding code execution or data exposure. EPSS is a live, recalculated score, so security teams should pull the current value from the FIRST.org API rather than rely on a point-in-time snapshot — a low EPSS today does not guarantee a low EPSS after a public PoC gains traction.
• CISA KEV: As of this writing, CVE-2022-0778 does not appear on CISA's Known Exploited Vulnerabilities catalog. Absence from KEV is not a reason to deprioritize the fix — KEV tracks confirmed in-the-wild exploitation, and a DoS bug with this reach (any pre-auth certificate parse) is exactly the kind of issue that can be weaponized quietly against availability-sensitive services (payment gateways, authentication backends, CI/CD endpoints) without generating the forensic signal that would get it added.

The practical takeaway: this is a High-severity, easy-to-trigger, pre-authentication DoS in one of the most widely deployed cryptographic libraries in existence. Severity scoring alone undersells the operational blast radius given how many products embed OpenSSL indirectly.

Timeline

• Reported to OpenSSL by Tavis Ormandy of Google in early 2022, following discovery via fuzzing of certificate parsing paths.
• March 15, 2022 — OpenSSL Project publishes the security advisory and CVE-2022-0778, alongside patched releases 1.0.2zd, 1.1.1n, and 3.0.2.
• March–April 2022 — Downstream Linux distributions (Debian, Ubuntu, RHEL/CentOS, Alpine, Amazon Linux) and major cloud providers ship backported patches within days to weeks; container base images and package repositories update in the same window.
• Ongoing — Because OpenSSL is frequently vendored, statically linked, or embedded in firmware and appliance images, unpatched instances have continued to surface in vulnerability scans and SBOM audits well beyond the initial disclosure window — a pattern typical of widely transitively-depended-upon C libraries.

Remediation Steps

1. Upgrade OpenSSL immediately to a fixed version: 1.0.2zd, 1.1.1n, 3.0.2, or any later release on your branch. If you are still on the 1.0.2 line, note that it reached end-of-life in December 2019 and should be migrated off entirely, not just patched.
2. Rebuild and redeploy statically linked binaries. OS package upgrades do not touch applications that vendor their own OpenSSL copy — audit Go, Rust, and C/C++ binaries, container images, and appliance firmware for embedded libssl/libcrypto and rebuild against the patched version.
3. Inventory transitive dependencies, not just direct ones. Language runtimes and frameworks (Python cryptography/pyOpenSSL, Ruby OpenSSL bindings, Node.js native TLS, Java JNI wrappers) may bundle or dynamically link a vulnerable OpenSSL — check the actual linked version at runtime, not just the declared package version.
4. Prioritize pre-authentication exposure. Systems that accept client certificates (mutual TLS), CAs and intermediate services that parse untrusted certificate or key submissions, and any service that validates externally supplied X.509 material should be patched ahead of internal-only, server-cert-only deployments.
5. Confirm the fix with a version check, not a scanner label alone: openssl version should report 1.0.2zd, 1.1.1n, 3.0.2, or later. For embedded builds, extract and check the linked library version directly, since package-manager metadata can be wrong for vendored copies.
6. Add a regression test or WAF/proxy-level filter for malformed explicit-curve EC certificates as a defense-in-depth measure while patch rollout is in progress across a large fleet, particularly for internet-facing mTLS endpoints that can't be patched atomically.
7. Re-run software composition analysis after remediation to confirm no build artifact, container layer, or firmware image still references the vulnerable OpenSSL version — patching source repos without rebuilding downstream artifacts is one of the most common reasons old CVEs resurface in later audits.

How Safeguard Helps

Vulnerabilities like CVE-2022-0778 are exactly where generic CVE feeds fall short: the same "OpenSSL is vulnerable" alert fires whether your service ever parses untrusted certificates or not, burning triage time on paths that can't actually be reached by an attacker. Safeguard's reachability analysis traces whether your application's actual call graph exercises the vulnerable BN_mod_sqrt() path through certificate or key parsing, so teams can separate genuinely exploitable exposure — mTLS listeners, CA services, cert-ingesting APIs — from incidental linkage that poses no real risk. Griffin AI correlates that reachability signal with CVSS, EPSS trend, and your deployment topology to produce a risk-ranked queue instead of a flat severity list, so a pre-auth, network-reachable DoS in a production TLS terminator surfaces above a copy sitting in an unused build tool. Safeguard's SBOM generation and ingestion capture both direct and transitive OpenSSL dependencies — including statically linked and vendored copies that package-manager-only tooling misses — giving you a single source of truth for exactly where every affected version lives across your fleet. And where the fix is a straightforward version bump, Safeguard can open auto-fix pull requests that update the pinned OpenSSL version or base image across affected repositories, turning a fleet-wide remediation effort into a batch of reviewable, mergeable diffs rather than a manual dependency-chase across dozens of services.