Apache 2

Plugin tenable:161948 rolls up the Apache HTTP Server issues fixed in 2.4.54, but they are not one uniform bug. The set includes mod_proxy_ajp request smuggling (CVE-2022-26377), mod_proxy dropping X-Forwarded-* headers and enabling backend IP-auth bypass (CVE-2022-31813), several mod_lua edge cases (CVE-2022-29404, CVE-2022-30556, CVE-2022-28614), a mod_sed memory-exhaustion DoS (CVE-2022-30522), a Windows-only mod_isapi over-read (CVE-2022-28330), and another low-likelihood over-read in ap_strcmp_match() that mainly matters to third-party modules or Lua (CVE-2022-28615). Upstream impact is generally 2.4.53 and earlier, with a few bugs narrower than that.

The vendor-style severity is inflated for most enterprises because the plugin inherits worst-case impact from the scariest constituent CVE, not the median real deployment. In practice, almost every path here depends on optional modules, uncommon proxy topologies, or a backend application making a bad trust decision such as treating proxy-supplied client IP metadata as authentication. That's meaningful enough to stay on the board, but it's not a drop-everything Apache emergency.

Why this verdict

• Big downgrade for module dependency: the bundle is dominated by mod_proxy_ajp, mod_proxy, mod_lua, mod_sed, and Windows mod_isapi cases rather than a universal Apache core bug.
• Big downgrade for attacker path assumptions: the nastiest issue, CVE-2022-31813, only pays off when the backend or app trusts forwarded IP metadata for auth. That implies a specific, brittle trust model, not generic compromise of every pre-2.4.54 host.
• Another downgrade for population narrowing: mod_proxy_ajp and AJP backends are far less common in modern fleets than plain HTTP reverse proxying, and Windows mod_isapi is a niche subset again.
• Small upward adjustment for exposure: internet-facing Apache reverse proxies are common, and when the trust flaw exists the attacker position is still unauthenticated remote.
• Small upward adjustment for visibility gap: version scanners light this up broadly, but config validation is harder, so vulnerable edge cases can hide inside large estates.

Why not higher?

There is no generic upstream Apache RCE here, no CISA KEV listing, and no strong evidence of broad indiscriminate exploitation against stock Apache for this bundle. Most exploit chains fail immediately if the relevant module is absent or the backend does real authentication instead of trusting network position.

Why not lower?

This is not ignorable because one branch is still an unauthenticated remote auth-bypass against public reverse proxies when the backend trust model is weak. If you run Apache as an app gateway, especially with mod_proxy or AJP, the impact can be real even though it is not universal.

1. Unload unused modules — Disable mod_proxy_ajp, mod_lua, mod_sed, and mod_isapi anywhere they are not explicitly required. For a MEDIUM finding there is no noisgate mitigation SLA; treat this as normal hardening work now and complete the actual patch inside the 365-day remediation window.
2. Stop using client IP as authentication — If any backend app trusts X-Forwarded-For, missing X-Forwarded-*, or the proxy's source IP as an auth decision, move that check to real application authentication or a trusted identity layer. This is the single best compensating control for CVE-2022-31813, and for MEDIUM there is no mitigation SLA—fix the design during normal engineering change control while planning patching inside 365 days.
3. Constrain AJP aggressively — If AJP is still in use, keep it on loopback or a tightly filtered backend segment and remove internet-reachable paths that can hit the proxy chain unnecessarily. Again, MEDIUM means no mitigation SLA; do it as routine risk reduction and patch by the remediation deadline.
4. Hunt for risky reverse-proxy patterns — Search Apache configs for ProxyPass, ProxyPassMatch, ProxyRequests, mod_proxy_ajp, and any rewrite or auth logic that keys on client IP or forwarded headers. This lets you separate 'plain web server noise' from the small subset of boxes that deserve faster attention even though the overall bundle is only MEDIUM.

Run this on the target Apache host as a local shell user; root is not required, though package-manager queries may work better with standard local tooling installed. Invoke it as bash verify_apache_2454.sh and it will conservatively return VULNERABLE, PATCHED, or UNKNOWN based on the local Apache/package version; distro backports it cannot prove are deliberately marked UNKNOWN rather than guessed.

#!/usr/bin/env bash
# verify_apache_2454.sh
# Conservative local checker for the Apache httpd issues fixed in upstream 2.4.54.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

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

extract_httpd_version() {
  local out=""
  for cmd in apache2ctl apachectl httpd apache2; do
    if have_cmd "$cmd"; then
      out="$($cmd -v 2>/dev/null | awk -F/ '/Server version|Server version:|Server version/{for(i=1;i<=NF;i++){if($i ~ /^2\.[0-9]+\.[0-9]+/){print $i; exit}}}' | head -n1)"
      if [ -n "$out" ]; then
        echo "$out"
        return 0
      fi
    fi
  done
  return 1
}

version_ge() {
  # usage: version_ge 2.4.54 2.4.53  => true
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}

UPSTREAM_VER=""
PKG_VER=""
DISTRO_ID=""
DISTRO_VER=""

if [ -r /etc/os-release ]; then
  # shellcheck disable=SC1091
  . /etc/os-release
  DISTRO_ID="${ID:-}"
  DISTRO_VER="${VERSION_ID:-}"
fi

if ! UPSTREAM_VER="$(extract_httpd_version)"; then
  echo "UNKNOWN"
  exit 2
fi

# If the running/build version is upstream 2.4.54 or newer, we're done.
if version_ge "$UPSTREAM_VER" "2.4.54"; then
  echo "PATCHED"
  exit 0
fi

# Debian/Ubuntu package checks for known backported fixed package strings.
if have_cmd dpkg-query; then
  PKG_VER="$(dpkg-query -W -f='${Version}' apache2 2>/dev/null || true)"
  if [ -n "$PKG_VER" ]; then
    if [ "$DISTRO_ID" = "debian" ]; then
      if dpkg --compare-versions "$PKG_VER" ge "2.4.54-1~deb11u1"; then
        echo "PATCHED"
        exit 0
      fi
    fi
    if [ "$DISTRO_ID" = "ubuntu" ]; then
      # Conservative: only assert patched for the known Ubuntu fixed string surfaced in public tracking.
      if dpkg --compare-versions "$PKG_VER" ge "2.4.54-2ubuntu1"; then
        echo "PATCHED"
        exit 0
      fi
    fi
    # Debian-family package exists but we cannot safely prove backport status.
    echo "UNKNOWN"
    exit 2
  fi
fi

# RPM-family packages are often heavily backported; do not guess from package label alone.
if have_cmd rpm; then
  if rpm -q httpd >/dev/null 2>&1 || rpm -q apache2 >/dev/null 2>&1; then
    echo "UNKNOWN"
    exit 2
  fi
fi

# Source-built / non-packaged installs below 2.4.54 are vulnerable.
echo "VULNERABLE"
exit 1

Sources

1. Tenable Nessus Plugin 161948 changelog
2. Apache HTTP Server 2.4 vulnerability list
3. NVD: CVE-2022-26377
4. Synacktiv write-up for CVE-2022-31813
5. Ubuntu CVE tracker: CVE-2022-31813
6. Debian security tracker: CVE-2022-31813
7. CISA Known Exploited Vulnerabilities Catalog
8. Bitsight Apache HTTP Server 2.4.53 observation footprint