Apache Tomcat 9

The issue behind tenable:160894 is CVE-2022-29885, fixed in Apache Tomcat 9.0.63. Affected upstream Tomcat versions are 9.0.13 through 9.0.62 for the 9.x line. The bug is not classic HTTP-side remote code execution; it is a documentation flaw around Tomcat clustering's EncryptInterceptor, which incorrectly implied that clustered Tomcat nodes could safely run over an *untrusted* network. In reality, confidentiality and integrity were improved, but DoS risk remained.

Reality is much milder than the 7.5 CVSS and Tenable plugin severity make it look. To matter, the target must be a clustered Tomcat deployment, EncryptInterceptor must be in play, and the attacker must be able to reach the cluster replication path, which is typically an internal-only design. Apache itself rated this issue Low, and that is much closer to enterprise patching reality than version-only scanner output.

Why this verdict

• Downward pressure: requires the cluster plane, not just the web app. CVSS treats this like any network-reachable service, but the real prerequisite is access to Tomcat Tribes clustering traffic, typically on internal-only paths.
• Downward pressure: version-only detections massively overcount. Nessus flags every 9.0.13-9.0.62 install, but many of those hosts do not run clustering at all, and many clustered hosts do not expose cluster traffic across untrusted networks.
• Downward pressure: availability-only impact. This is a DoS scenario, not pre-auth RCE, not auth bypass, and not a broad confidentiality/integrity failure.
• Downward pressure: niche deployment assumption. The vulnerable condition is effectively 'you believed EncryptInterceptor made hostile-network clustering safe'—that is a rare architecture decision in mature enterprises.

Why not higher?

It is not higher because the exploit chain assumes internal or otherwise special network access to a Tomcat cluster channel that many enterprises never expose. On top of that, the impact is service disruption rather than durable compromise, and the reviewed sources do not show KEV status or broad active exploitation.

Why not lower?

It is not IGNORE because there is still a real class of deployments that used EncryptInterceptor as a security boundary and may have stretched clustering over networks they should not trust. If you have internet-routable or inter-zone-reachable Tribes traffic, the issue becomes operationally relevant even if it is still not an emergency-tier bug.

1. Block cluster ports at boundaries — Deny Tomcat Tribes membership and receiver traffic across untrusted or unnecessary segments, especially multicast 228.0.0.4:45564 and receiver ports in 4000-4100. For a LOW verdict there is no noisgate mitigation SLA; do this as normal hardening/backlog hygiene.
2. Audit for clustering before patching blindly — Confirm whether affected hosts actually use <Cluster> and EncryptInterceptor in server.xml before spending patch labor. For a LOW verdict, treat this as inventory cleanup and applicability triage during regular operations.
3. Collapse unnecessary east-west reachability — If app teams do not need session replication, remove or disable clustering and close the receiver path entirely. For this severity, fold the change into standard network and platform hygiene work rather than emergency maintenance.
4. Prefer trusted transport for any remaining cluster links — Where clustering must cross zones, move the trust boundary to VPN or tightly controlled network segmentation rather than assuming EncryptInterceptor alone is enough. Again, LOW means no deadline-driven emergency action unless your own architecture is unusually exposed.

Run this on the target Tomcat host as a user that can read the Tomcat install and conf/server.xml; root is only needed if permissions are locked down. Save as check_tomcat_cve_2022_29885.sh and run bash check_tomcat_cve_2022_29885.sh /opt/tomcat or point it at CATALINA_BASE.

#!/usr/bin/env bash
# check_tomcat_cve_2022_29885.sh
# Detect likely applicability of CVE-2022-29885 on Apache Tomcat 9.x
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

INPUT_BASE="${1:-}"

find_base() {
  local candidates=()
  if [[ -n "$INPUT_BASE" ]]; then candidates+=("$INPUT_BASE"); fi
  [[ -n "${CATALINA_BASE:-}" ]] && candidates+=("$CATALINA_BASE")
  [[ -n "${CATALINA_HOME:-}" ]] && candidates+=("$CATALINA_HOME")
  candidates+=(/opt/tomcat /usr/share/tomcat /usr/share/tomcat9 /var/lib/tomcat9 /opt/apache-tomcat* /usr/local/tomcat)

  for c in "${candidates[@]}"; do
    for path in $c; do
      [[ -d "$path" ]] || continue
      if [[ -f "$path/conf/server.xml" || -x "$path/bin/catalina.sh" || -x "$path/bin/version.sh" ]]; then
        echo "$path"
        return 0
      fi
    done
  done
  return 1
}

get_version() {
  local base="$1"
  local out=""

  if [[ -x "$base/bin/version.sh" ]]; then
    out=$("$base/bin/version.sh" 2>/dev/null | tr -d '\r')
  elif [[ -x "$base/bin/catalina.sh" ]]; then
    out=$("$base/bin/catalina.sh" version 2>/dev/null | tr -d '\r')
  fi

  if [[ -n "$out" ]]; then
    echo "$out" | sed -nE 's/.*Server number:[[:space:]]*([0-9]+\.[0-9]+\.[0-9]+).*/\1/p' | head -n1
    return 0
  fi

  # Fallback: parse RELEASE-NOTES or manifest-ish text if present
  for f in "$base/RELEASE-NOTES" "$base/RUNNING.txt" "$base/lib/catalina.jar"; do
    [[ -e "$f" ]] || continue
    strings "$f" 2>/dev/null | sed -nE 's/.*Apache Tomcat Version[[:space:]]*([0-9]+\.[0-9]+\.[0-9]+).*/\1/p' | head -n1
    return 0
  done

  return 1
}

ver_lt() {
  [[ "$1" == "$2" ]] && return 1
  [[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" == "$1" ]]
}

ver_ge() {
  [[ "$1" == "$2" ]] && return 0
  ! ver_lt "$1" "$2"
}

BASE=$(find_base) || {
  echo "UNKNOWN: could not locate Tomcat base/home"
  exit 2
}

VERSION=$(get_version "$BASE")
if [[ -z "${VERSION:-}" ]]; then
  echo "UNKNOWN: could not determine Tomcat version under $BASE"
  exit 2
fi

SERVER_XML="$BASE/conf/server.xml"
if [[ ! -f "$SERVER_XML" ]]; then
  # Try common distro split-path location
  if [[ -f "/etc/tomcat9/server.xml" ]]; then
    SERVER_XML="/etc/tomcat9/server.xml"
  else
    echo "UNKNOWN: version $VERSION found but server.xml not readable"
    exit 2
  fi
fi

# Plugin scope in question is Tomcat 9.0.13 < 9.0.63
if ver_lt "$VERSION" "9.0.13" || ver_ge "$VERSION" "9.0.63"; then
  echo "PATCHED: Tomcat version $VERSION is outside the affected 9.0.13-9.0.62 range"
  exit 0
fi

CLUSTER_ENABLED=0
ENCRYPT_INTERCEPTOR=0
RECEIVER_PRESENT=0
MEMBERSHIP_PRESENT=0

grep -Eq '<Cluster[[:space:]>]' "$SERVER_XML" && CLUSTER_ENABLED=1
grep -Eq 'EncryptInterceptor' "$SERVER_XML" && ENCRYPT_INTERCEPTOR=1
grep -Eq '<Receiver[[:space:]>]' "$SERVER_XML" && RECEIVER_PRESENT=1
grep -Eq '<Membership[[:space:]>]' "$SERVER_XML" && MEMBERSHIP_PRESENT=1

if [[ $CLUSTER_ENABLED -eq 1 && $ENCRYPT_INTERCEPTOR -eq 1 ]]; then
  echo "VULNERABLE: Tomcat $VERSION is in range and server.xml shows Cluster + EncryptInterceptor (review trust boundaries to cluster ports)"
  exit 1
fi

if [[ $CLUSTER_ENABLED -eq 1 ]]; then
  echo "UNKNOWN: Tomcat $VERSION is in range and clustering is enabled, but EncryptInterceptor was not found in readable config"
  exit 2
fi

echo "UNKNOWN: Tomcat $VERSION is in range, but clustering/EncryptInterceptor were not found in readable config; version-only scanner hit may be non-applicable"
exit 2

Sources

1. Tenable plugin 160894
2. Apache Tomcat 9 security page
3. Apache Tomcat 9 changelog
4. NVD CVE-2022-29885
5. Tomcat clustering how-to
6. CISA vulnerability bulletin SB22-136
7. Ubuntu CVE page for CVE-2022-29885
8. Debian security tracker for CVE-2022-29885