Apache 2

Plugin 193423 is nominally titled Apache 2.4.x < 2.4.54 Multiple Vulnerabilities, but Tenable’s own plugin metadata ties it to CVE-2022-30522 (apache_2_4_54_cve-2022-30522.nasl). The actual flaw is a denial of service in mod_sed: if Apache HTTP Server 2.4.53 is configured to run mod_sed transformations on very large request or response bodies, the module can make oversized memory allocations and abort. That is much narrower than the plugin title suggests, and upstream Apache documents mod_sed as experimental.

Tenable’s High / 7.5 label is technically defensible in CVSS-land because the bug is network-reachable and availability-impacting, but it badly overstates enterprise reality. You need the exact vulnerable release, the uncommon mod_sed module, and a live InputSed / OutputSed path handling large content. Upstream Apache called this issue low, and for a 10,000-host patch queue that is the right instinct: this finding is mostly version-based noise unless you knowingly use mod_sed.

Why this verdict

• Start from Tenable's 7.5, then cut hard for prerequisites: the crash path exists only when the host is effectively vulnerable 2.4.53, mod_sed is loaded, and that module is attached to a reachable large-content flow.
• Attacker position is easy, but population is tiny: this is *unauthenticated remote* in theory, yet the required config implies a very small slice of real Apache deployments compared with generic public web serving.
• Modern edge controls remove many attempts before Apache sees them: body-size caps in CDNs, WAFs, reverse proxies, and app gateways often stop the oversized content needed to hit the bug.
• Blast radius is limited to DoS: the realistic outcome is worker abort / service degradation, not authentication bypass, data theft, or code execution.
• The scanner overstates exposure: plugin 193423 is explicitly version-only and does not validate mod_sed, InputSed, OutputSed, or large-body reachability.

Why not higher?

There is no KEV listing, no solid evidence of active exploitation, and no meaningful confidentiality or integrity impact. More importantly, the exploit chain depends on an uncommon experimental module and specific content-filter configuration, which sharply reduces the reachable enterprise population.

Why not lower?

This is still remotely triggerable DoS if the exact module/config combination exists on an internet-facing host. If you do use mod_sed on upload or large-response paths, the issue stops being theoretical and can disrupt service, so it is not pure ignore-tier noise.

1. Unload mod_sed where unused — If mod_sed is not a deliberate business requirement, remove or comment out the module load and reload Apache. For a LOW verdict there is no formal mitigation SLA; do this as backlog hygiene in the next normal maintenance cycle.
2. Remove InputSed / OutputSed from large-body routes — If you must keep mod_sed, keep it off upload paths and any route that can process very large request or response bodies. That eliminates the practical trigger condition without waiting on a major platform refresh; again, for LOW, handle during routine change windows.
3. Enforce body-size limits upstream — Set conservative request-size caps at the CDN, reverse proxy, WAF, or app gateway in front of Apache so oversized payloads are dropped before they reach the filter chain. This is the cleanest compensating control if you cannot patch immediately, but on a LOW issue it belongs in normal hardening work rather than emergency change.
4. Validate distro backports before escalating — Use package changelogs and vendor advisories to confirm whether a lower-looking distro package already includes the fix. This prevents wasting patch-window capacity on false-priority findings generated by version-only scans.

Run this on the target Apache host, not from a scanner box. Invoke it as sudo bash ./check-cve-2022-30522.sh; root is recommended so apachectl can enumerate loaded modules and the script can read all config includes. It outputs VULNERABLE, PATCHED, or UNKNOWN based on version, distro backport evidence, mod_sed load state, and active Sed directives.

#!/usr/bin/env bash
# check-cve-2022-30522.sh
# Determine practical exposure to Apache HTTP Server CVE-2022-30522
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

CVE="CVE-2022-30522"
APACHE_CTL=""
APACHE_BIN=""
CONFIG_ROOTS=(/etc/httpd /etc/apache2 /usr/local/apache2/conf)

find_apache() {
  for x in apachectl apache2ctl; do
    if command -v "$x" >/dev/null 2>&1; then
      APACHE_CTL="$(command -v "$x")"
      break
    fi
  done
  for x in httpd apache2 apache; do
    if command -v "$x" >/dev/null 2>&1; then
      APACHE_BIN="$(command -v "$x")"
      break
    fi
  done
}

ver_ge() {
  # returns 0 if $1 >= $2
  [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}

ver_gt() {
  [ "$1" != "$2" ] && ver_ge "$1" "$2"
}

get_version() {
  local out ver
  out=""
  if [ -n "$APACHE_BIN" ]; then
    out="$($APACHE_BIN -v 2>/dev/null || true)"
  fi
  if [ -z "$out" ] && [ -n "$APACHE_CTL" ]; then
    out="$($APACHE_CTL -v 2>/dev/null || true)"
  fi
  ver="$(printf '%s' "$out" | sed -n 's/.*Apache\/\([0-9][0-9.]*\).*/\1/p' | head -n1)"
  printf '%s' "$ver"
}

has_backport_fix() {
  # Debian/Ubuntu package changelog
  if command -v dpkg-query >/dev/null 2>&1; then
    if dpkg-query -W apache2 >/dev/null 2>&1; then
      if zgrep -qi "$CVE" /usr/share/doc/apache2/changelog.Debian.gz 2>/dev/null; then
        return 0
      fi
      if grep -Rqi "$CVE" /usr/share/doc/apache2* 2>/dev/null; then
        return 0
      fi
    fi
  fi

  # RPM package changelog
  if command -v rpm >/dev/null 2>&1; then
    if rpm -q httpd >/dev/null 2>&1; then
      if rpm -q --changelog httpd 2>/dev/null | grep -qi "$CVE"; then
        return 0
      fi
    fi
  fi

  return 1
}

mod_sed_loaded() {
  local mods
  mods=""
  if [ -n "$APACHE_CTL" ]; then
    mods="$($APACHE_CTL -M 2>/dev/null || true)"
  elif [ -n "$APACHE_BIN" ]; then
    mods="$($APACHE_BIN -M 2>/dev/null || true)"
  fi
  printf '%s' "$mods" | grep -Eq '(^|[[:space:]])sed_module[[:space:]]' 
}

sed_directives_present() {
  local root found=1
  for root in "${CONFIG_ROOTS[@]}"; do
    if [ -d "$root" ]; then
      if grep -RIEq '^\s*(InputSed|OutputSed|AddInputFilter\s+Sed\b|AddOutputFilter\s+Sed\b)' "$root" 2>/dev/null; then
        return 0
      fi
    fi
  done
  return 1
}

say() {
  printf '%s\n' "$1"
}

find_apache

if [ -z "$APACHE_BIN" ] && [ -z "$APACHE_CTL" ]; then
  say "UNKNOWN: Apache binary/control utility not found"
  exit 2
fi

VERSION="$(get_version)"
if [ -z "$VERSION" ]; then
  say "UNKNOWN: Could not determine Apache version"
  exit 2
fi

# First, honor distro backport evidence.
if has_backport_fix; then
  say "PATCHED: Package metadata/changelog references ${CVE}; likely fixed via distro backport"
  exit 0
fi

# Upstream logic for CVE-2022-30522 is much narrower than '<2.4.54'.
if ver_gt "$VERSION" "2.4.53"; then
  say "PATCHED: Apache version ${VERSION} is newer than upstream vulnerable 2.4.53"
  exit 0
fi

if [ "$VERSION" != "2.4.53" ]; then
  say "PATCHED: Upstream CVE-2022-30522 is tied to 2.4.53 behavior, not generic older Apache"
  exit 0
fi

# Exactly 2.4.53: now check practical exposure.
if mod_sed_loaded; then
  if sed_directives_present; then
    say "VULNERABLE: Apache 2.4.53 with mod_sed loaded and active Sed directives present"
    exit 1
  else
    say "UNKNOWN: Apache 2.4.53 has mod_sed loaded, but no active Sed directives were found in common config roots"
    exit 2
  fi
else
  say "PATCHED: Apache 2.4.53 detected, but mod_sed is not loaded so the CVE-2022-30522 code path is not active"
  exit 0
fi

Sources

1. Tenable Nessus Plugin 193423
2. Tenable CVE-2022-30522
3. Apache HTTP Server 2.4 vulnerabilities
4. NVD CVE-2022-30522
5. Apache mod_sed documentation
6. Ubuntu CVE-2022-30522
7. Debian Security Tracker CVE-2022-30522
8. CISA Known Exploited Vulnerabilities Catalog