OpenSSL 1

This finding is CVE-2022-0778 in OpenSSL's BN_mod_sqrt() routine. On affected builds, a crafted X.509 certificate or private key with malformed explicit elliptic-curve parameters can push the parser into an infinite loop, hanging the process and causing denial of service only. For the plugin you cited, the directly affected upstream range is OpenSSL 1.1.1 through 1.1.1m, fixed in 1.1.1n on 2022-03-15; OpenSSL 3.0.0-3.0.1 and 1.0.2-1.0.2zc were also affected upstream.

The raw CVSS 7.5/HIGH is technically defensible because the crash path can be network-reachable and does not require prior auth, but it overstates fleet-wide urgency for a generic enterprise estate. In practice, exploitation requires a target that actually parses attacker-supplied certificates or keys: a TLS client talking to a malicious server, a TLS server doing client-certificate auth, a CA/PKI workflow, or a product ingesting customer certs/keys. That prerequisite sharply narrows exposed population, and the impact is a hang of the consuming process, not code execution or data theft. This is why the plugin's VPR Medium 5.8 feels closer to reality than the base CVSS.

Why this verdict

• Downgrade from CVSS HIGH: the base 7.5 assumes a vulnerable parser is directly reachable over the network; in enterprise reality, many hosts merely *ship* OpenSSL without exposing an attacker-controlled certificate parse path.
• Posture friction: the most common Internet-facing server case only works if the server consumes attacker-supplied certs, typically mTLS/client-auth or a certificate upload workflow. That exposure population is far smaller than generic HTTPS.
• Client-side path implies a prior foothold or user flow: attacking TLS clients usually requires luring clients to a malicious server, service-discovery abuse, or MITM-style positioning, which compounds downward pressure.
• Impact is availability only: this hangs a process or worker; it does not hand over execution, privileges, secrets, or persistence.
• But not low/ignore: public PoC exists, trigger reliability is good once the parser path is hit, and the library is ubiquitous enough that PKI-heavy environments, appliances, proxies, and security tools can still suffer meaningful outages.

Why not higher?

This is not a broad unauthenticated Internet-to-RCE situation. The exploit chain collapses entirely if the target never parses attacker-controlled certificates or keys, and even successful exploitation produces only a hang/DoS, often bounded to one process, one worker pool, or one device node behind supervision or HA.

Why not lower?

The bug is real, the trigger condition is well understood, and public PoC exists. In environments that do parse untrusted certificate material—reverse proxies with mTLS, VPN clients, PKI tooling, CA workflows, cert-management portals, security appliances—the attack is easy enough to matter and can create immediate service disruption.

1. Map cert-parsing exposure — Within the no mitigation SLA — go straight to the 365-day remediation window for a MEDIUM, identify where OpenSSL is used in mTLS, certificate upload/import, CSR processing, VPN clients, PKI, mail gateways, and reverse proxies. This is the single best way to separate noisy package hits from actually reachable risk.
2. Turn on parser-path IPS where available — If your stack supports it, enable signatures that detect malformed certificate attacks; for example, Palo Alto documents Threat IDs 92409 and 92411. Do this on exposed ingress points to reduce opportunistic exploitation while you validate patch coverage; for a MEDIUM there is no mitigation SLA, so use this selectively where exposure is proven.
3. Constrain client-certificate auth — Review Internet-facing services that request client certificates and disable unnecessary mTLS prompts or narrow them to trusted networks. This shrinks the unauthenticated attack surface immediately and is worth doing during the normal remediation window.
4. Harden process supervision — Ensure watchdog restarts, health probes, worker recycling, and sane per-connection timeouts are in place for services that parse certificates. This does not fix the bug, but it reduces outage duration and blast radius if a parser thread hangs before patching within the MEDIUM remediation window.
5. Validate distro backports before retagging — Before escalating tickets, compare package release metadata against vendor advisories on Debian/RHEL/SUSE-style systems. Many hosts will appear numerically below 1.1.1n yet already contain the fix; clean this up early so the team spends time on reachable exposure, not version-string archaeology.

Run this on the target Linux/macOS/Unix host that triggered the plugin, not on your scanner. Invoke it as sudo bash check-openssl-cve-2022-0778.sh or bash check-openssl-cve-2022-0778.sh; root is recommended so the script can query package managers cleanly, but it will still attempt a best-effort check unprivileged. It prints VULNERABLE, PATCHED, or UNKNOWN and exits 0, 1, or 2 respectively.

#!/usr/bin/env bash
# check-openssl-cve-2022-0778.sh
# Determine likely exposure to CVE-2022-0778 on the local host.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -u

have() { command -v "$1" >/dev/null 2>&1; }

result_unknown() {
  echo "UNKNOWN: $1"
  exit 2
}

result_vuln() {
  echo "VULNERABLE: $1"
  exit 0
}

result_patched() {
  echo "PATCHED: $1"
  exit 1
}

version_ge() {
  # returns 0 if $1 >= $2
  if have dpkg; then
    dpkg --compare-versions "$1" ge "$2"
    return $?
  fi
  local first
  first=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
  [ "$first" = "$2" ]
}

OPENSSL_BIN=""
if have openssl; then
  OPENSSL_BIN=$(command -v openssl)
fi

if [ -n "$OPENSSL_BIN" ]; then
  OPENSSL_FULL=$($OPENSSL_BIN version 2>/dev/null || true)
  OPENSSL_VER=$($OPENSSL_BIN version 2>/dev/null | awk '{print $2}')
else
  OPENSSL_FULL=""
  OPENSSL_VER=""
fi

# Debian / Ubuntu backport-aware checks
if have dpkg-query; then
  PKG_VER=$(dpkg-query -W -f='${Version}' openssl 2>/dev/null || true)
  if [ -n "$PKG_VER" ]; then
    . /etc/os-release 2>/dev/null || true
    DISTRO_ID=${ID:-unknown}
    DISTRO_VER=${VERSION_ID:-unknown}

    case "$DISTRO_ID:$DISTRO_VER" in
      debian:10)
        if dpkg --compare-versions "$PKG_VER" ge '1.1.1d-0+deb10u8'; then
          result_patched "Debian 10 openssl package version $PKG_VER includes the CVE-2022-0778 fix (DSA-5103)."
        else
          result_vuln "Debian 10 openssl package version $PKG_VER is below fixed version 1.1.1d-0+deb10u8."
        fi
        ;;
      debian:11)
        if dpkg --compare-versions "$PKG_VER" ge '1.1.1k-1+deb11u2'; then
          result_patched "Debian 11 openssl package version $PKG_VER includes the CVE-2022-0778 fix (DSA-5103)."
        else
          result_vuln "Debian 11 openssl package version $PKG_VER is below fixed version 1.1.1k-1+deb11u2."
        fi
        ;;
      ubuntu:*)
        # Ubuntu commonly backports fixes; package version is authoritative.
        # If ubuntu-security-status tooling is absent, keep this conservative.
        if printf '%s' "$PKG_VER" | grep -qi 'ubuntu'; then
          echo "UNKNOWN: Ubuntu openssl package version $PKG_VER detected. Ubuntu often backports fixes; confirm against the Ubuntu CVE tracker for CVE-2022-0778."
          exit 2
        fi
        ;;
    esac
  fi
fi

# RPM-based best-effort check
if have rpm; then
  RPM_VER=$(rpm -q --qf '%{VERSION}-%{RELEASE}' openssl 2>/dev/null || true)
  if [ -n "$RPM_VER" ] && [ "$RPM_VER" != "package openssl is not installed" ]; then
    if printf '%s' "$RPM_VER" | grep -Eq 'el7|el8|el9|amzn|sles|opensuse'; then
      echo "UNKNOWN: RPM package openssl-$RPM_VER detected. Enterprise RPM distros often backport this fix; verify with the vendor advisory for your distro build."
      exit 2
    fi
  fi
fi

# Upstream version-string check for non-backported installs and source builds
if [ -z "$OPENSSL_VER" ]; then
  result_unknown "openssl binary not found and no authoritative package result available."
fi

case "$OPENSSL_VER" in
  1.1.1*)
    # Vulnerable upstream: 1.1.1 through 1.1.1m; fixed: 1.1.1n+
    if version_ge "$OPENSSL_VER" '1.1.1n'; then
      result_patched "OpenSSL runtime version is $OPENSSL_FULL, which is >= 1.1.1n."
    else
      result_vuln "OpenSSL runtime version is $OPENSSL_FULL, which is < 1.1.1n."
    fi
    ;;
  3.0.*)
    if version_ge "$OPENSSL_VER" '3.0.2'; then
      result_patched "OpenSSL runtime version is $OPENSSL_FULL, which is >= 3.0.2."
    else
      result_vuln "OpenSSL runtime version is $OPENSSL_FULL, which is < 3.0.2."
    fi
    ;;
  1.0.2*)
    # Publicly fixed only for premium support customers as 1.0.2zd.
    if version_ge "$OPENSSL_VER" '1.0.2zd'; then
      result_patched "OpenSSL runtime version is $OPENSSL_FULL, which is >= 1.0.2zd."
    else
      result_vuln "OpenSSL runtime version is $OPENSSL_FULL, which is in the affected 1.0.2 line below 1.0.2zd."
    fi
    ;;
  *)
    result_unknown "OpenSSL runtime version is $OPENSSL_FULL. This script only makes an authoritative decision for affected upstream branches 1.0.2, 1.1.1, and 3.0.x or known distro backports."
    ;;
esac

Sources

1. Tenable Plugin 158974
2. OpenSSL Security Advisory 2022-03-15
3. NVD CVE-2022-0778
4. Tenable CVE page with EPSS
5. Packet Storm PoC / advisory
6. Debian DSA-5103 backport advisory
7. Palo Alto Networks advisory for CVE-2022-0778
8. CISA Known Exploited Vulnerabilities Catalog