A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient…

CVE-2022-4304 is an OpenSSL RSA decryption timing oracle: tiny timing differences during RSA decrypt processing can leak enough signal for a Bleichenbacher-style plaintext recovery attack. Upstream affected ranges are OpenSSL 3.0.0 through 3.0.7, 1.1.1 before 1.1.1t, and 1.0.2 before 1.0.2zg; distro builds may be fixed via backports even when the package version string looks older.

The vendor's MEDIUM label is technically fair in a vacuum but still a little generous for enterprise patch triage. The decisive reality check is exploit friction: the attacker needs a reachable RSA decryption path, usually a legacy TLS_RSA_* handshake or some application-level RSA decrypt API, then must collect a very large number of timing samples under noisy network conditions; that sharply narrows both exposed population and practical attacker success.

Why this verdict

• Baseline starts at vendor MEDIUM, then drops on attacker position reality: the attacker is nominally remote and unauthenticated, but in practice they need a live RSA decryption oracle plus a target ciphertext; that is already narrower than a normal network bug.
• Reachable population is sharply reduced by modern crypto defaults: TLS 1.3 removed RSA key exchange, and well-run TLS 1.2 estates prefer ECDHE, so a huge fraction of OpenSSL deployments are not exploitable through the classic observed-session path.
• Operational exploit friction is extreme: public tooling exists, but success still depends on very large probe volumes, stable timing collection, and enough signal surviving network noise and middleboxes.

Why not higher?

There is no broad internet-scale smash-and-grab path here. No KEV entry, no known active campaigns, no integrity or availability impact, and a large chunk of modern deployments simply do not expose the necessary RSA decryption behavior at all.

Why not lower?

This is still a real confidentiality bug in one of the most widely deployed crypto libraries, not a paperwork CVE. If you still run legacy TLS_RSA_* or application-level RSA decryption on exposed systems, the impact can be meaningful and the fix is well established.

1. Disable legacy TLS_RSA_* cipher suites — If the service is exposed over TLS, removing RSA key exchange cuts off the most common remotely reachable attack path outright; prefer ECDHE/TLS 1.3 everywhere. For a LOW verdict there is no formal SLA, but do it in the next normal crypto-hardening change window.
2. Inventory app-layer RSA decryption uses — Find services, middleware, VPNs, mail gateways, HSM front-ends, and ICS components that still perform RSA decryption on untrusted input, because those are the real blast-radius drivers for this CVE. For LOW, treat this as backlog hygiene and complete it during the next routine library exposure review.
3. Rate-limit handshake and decrypt abuse — High-volume repetitive probes are part of the attack economics, so rate limits, per-source throttles, and connection anomaly controls raise attacker cost and reduce measurement quality. Use the next standard perimeter tuning cycle; no mitigation SLA applies at this severity.
4. Alert on repetitive failed handshakes — Build detections for bursts of failed TLS handshakes or repetitive malformed decrypt requests against the same endpoint, because that is where exploitation is most likely to surface operationally. Roll this into regular detection engineering maintenance rather than emergency change.
5. Patch the terminating tier first — Where legacy backends remain, prioritize the front-end TLS terminator, reverse proxy, or appliance actually doing RSA decryption so you remove the exposed oracle without waiting for every downstream dependency. For LOW, schedule in normal remediation waves.

Run this on the target host or container image that ships OpenSSL, not from an auditor workstation. Invoke it as bash check-cve-2022-4304.sh or bash check-cve-2022-4304.sh /usr/bin/openssl; root is not required, but package-changelog checks are more reliable if the local package database is readable.

#!/usr/bin/env bash
# check-cve-2022-4304.sh
# Detect likely exposure to CVE-2022-4304 (OpenSSL RSA timing oracle)
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_BIN="${1:-$(command -v openssl 2>/dev/null || true)}"
CVE="CVE-2022-4304"

if [ -z "$TARGET_BIN" ] || [ ! -x "$TARGET_BIN" ]; then
  echo "UNKNOWN: openssl binary not found or not executable"
  exit 2
fi

version_line="$($TARGET_BIN version -a 2>/dev/null | head -n 1)"
if [ -z "$version_line" ]; then
  echo "UNKNOWN: unable to read OpenSSL version"
  exit 2
fi

version="$($TARGET_BIN version 2>/dev/null | awk '{print $2}')"
platform_info="$($TARGET_BIN version -a 2>/dev/null | tr '\n' ' ' )"

# First: distro/package backport checks, because package versions may look older than upstream fixed releases.
check_dpkg() {
  if ! command -v dpkg-query >/dev/null 2>&1; then
    return 1
  fi

  local pkg
  for pkg in openssl libssl3 libssl1.1 libssl1.0.0; do
    if dpkg-query -W -f='${Status}\n' "$pkg" 2>/dev/null | grep -q "install ok installed"; then
      if command -v apt-cache >/dev/null 2>&1; then
        if apt-cache show "$pkg" 2>/dev/null | grep -qi "$CVE"; then
          echo "PATCHED: dpkg package metadata for $pkg references $CVE (backport likely)"
          exit 0
        fi
      fi
      # Debian fixed versions from tracker
      local ver
      ver="$(dpkg-query -W -f='${Version}\n' "$pkg" 2>/dev/null | head -n1)"
      case "$pkg:$ver" in
        openssl:1.1.1n-0+deb10u4*|openssl:1.1.1n-0+deb11u4*|libssl1.1:1.1.1n-0+deb10u4*|libssl1.1:1.1.1n-0+deb11u4*)
          echo "PATCHED: Debian backported fixed package detected ($pkg $ver)"
          exit 0
          ;;
      esac
    fi
  done
  return 1
}

check_rpm() {
  if ! command -v rpm >/dev/null 2>&1; then
    return 1
  fi

  local pkg
  for pkg in openssl openssl-libs; do
    if rpm -q "$pkg" >/dev/null 2>&1; then
      if rpm -q --changelog "$pkg" 2>/dev/null | grep -q "$CVE"; then
        echo "PATCHED: rpm changelog for $pkg references $CVE (backport likely)"
        exit 0
      fi
    fi
  done
  return 1
}

check_dpkg
check_rpm

# Upstream version comparison fallback. Handles common OpenSSL trains only.
normalize() {
  # Converts versions like 3.0.7, 1.1.1s, 1.1.1t into sortable numeric-ish tuples.
  local v="$1"
  local base suffix letter_num=0
  base="${v%%[a-z]}"
  suffix="${v#$base}"
  if [ "$suffix" != "$v" ] && [ -n "$suffix" ]; then
    # a=1 ... z=26
    letter_num=$(( $(printf '%d' "'${suffix}") - 96 ))
  fi
  IFS=. read -r a b c <<< "$base"
  a=${a:-0}; b=${b:-0}; c=${c:-0}
  printf "%03d%03d%03d%03d\n" "$a" "$b" "$c" "$letter_num"
}

ver_ge() {
  [ "$(normalize "$1")" -ge "$(normalize "$2")" ]
}

ver_lt() {
  [ "$(normalize "$1")" -lt "$(normalize "$2")" ]
}

# Common upstream trains
if [[ "$version" =~ ^3\.0\.[0-9]+$ ]]; then
  if ver_ge "$version" "3.0.8"; then
    echo "PATCHED: upstream OpenSSL $version is at or above 3.0.8"
    exit 0
  else
    echo "VULNERABLE: upstream OpenSSL $version is below 3.0.8"
    exit 1
  fi
fi

if [[ "$version" =~ ^1\.1\.1[a-z]?$ ]]; then
  if ver_ge "$version" "1.1.1t"; then
    echo "PATCHED: upstream OpenSSL $version is at or above 1.1.1t"
    exit 0
  else
    echo "VULNERABLE: upstream OpenSSL $version is below 1.1.1t"
    exit 1
  fi
fi

if [[ "$version" =~ ^1\.0\.2[a-z]?$ ]]; then
  if ver_ge "$version" "1.0.2zg"; then
    echo "PATCHED: upstream OpenSSL $version is at or above 1.0.2zg"
    exit 0
  else
    echo "VULNERABLE: upstream OpenSSL $version is below 1.0.2zg"
    exit 1
  fi
fi

# Newer trains likely contain the fix; older/odd vendor forks are ambiguous.
if [[ "$version" =~ ^3\.[1-9]\.[0-9]+$|^4\.[0-9]+\.[0-9]+$ ]]; then
  echo "PATCHED: OpenSSL $version is on a newer major/minor train than the affected upstream releases"
  exit 0
fi

echo "UNKNOWN: version '$version' from '$version_line' could not be mapped cleanly; inspect package advisory/backport status"
exit 2

Sources

1. OpenSSL vulnerability index
2. OpenSSL security advisory 2023-02-07
3. NVD entry
4. CISA KEV catalog
5. Debian security tracker
6. Everlasting ROBOT: the Marvin Attack
7. tlsfuzzer repository
8. marvin-toolkit repository