Apache 2

This maps to CVE-2018-11763 in Apache HTTP Server: by sending continuous oversized HTTP/2 SETTINGS frames, an attacker can keep a connection, a server thread, and CPU time tied up so normal timeout behavior never kicks in. Upstream says it affects Apache HTTP Server 2.4.17 through 2.4.34, and only when the server is actually using the h2/h2c protocol via mod_http2.

Tenable calling this MEDIUM is defensible in a vacuum, but for enterprise patch priority it lands lower. The decisive friction is that this is availability-only, feature-gated by HTTP/2, and not every Apache install even has mod_http2 built or enabled; several distro notes explicitly call out older releases as not affected because HTTP/2 was not enabled in the build. On a real 10,000-host estate, this is mostly an internet-edge web tier hygiene issue, not a fleet-wide emergency.

Why this verdict

• Downward pressure: requires origin-side HTTP/2 — Apache says the bug only affects servers with h2 enabled, and Apache requires explicit Protocols configuration for HTTP/2.
• Downward pressure: narrow real-world exposure — internal-only Apache, reverse-proxied Apache, and HTTP/1.1-only backends are out of scope even if the version string looks vulnerable.
• Downward pressure: availability-only impact — this is a worker/CPU exhaustion DoS, not auth bypass, data theft, or RCE.
• Baseline kept above IGNORE — it is still unauthenticated network-reachable on exposed sites and can cause customer-visible outage if enough sessions are sustained.
• More downward pressure: no KEV / no strong current campaign evidence — absent exploitation evidence matters when deciding what jumps the patch queue.

Why not higher?

If this were broadly reachable across default installs, or if there were reliable evidence of active exploitation, it could sit in MEDIUM. But requiring HTTP/2 at the Apache origin is a real deployment filter, and many enterprises terminate HTTP/2 upstream on a proxy/CDN where this Apache-specific path never lands.

Why not lower?

I would not mark it IGNORE because a directly exposed Apache edge node with HTTP/2 enabled can still be knocked over by an unauthenticated attacker. For customer-facing estates, even availability-only bugs deserve tracking when they are remotely triggerable.

1. Disable HTTP/2 where you do not need it — Remove h2/h2c from the Apache Protocols directive or unload mod_http2 on affected hosts that do not require origin-side HTTP/2. For a LOW verdict there is no SLA, so treat this as backlog hygiene unless the host is a business-critical public edge, where it is still a smart hardening move.
2. Terminate HTTP/2 upstream — If you already run a CDN, reverse proxy, or load balancer, prefer terminating HTTP/2 there and speaking HTTP/1.1 to legacy Apache backends. This removes the vulnerable protocol path without waiting on an origin refresh; for LOW, do it during normal change windows.
3. Enforce connection and rate controls — Use WAF/LB/CDN connection caps, per-IP rate limits, and HTTP/2 abuse protections to make sustained SETTINGS-frame abuse harder to scale. This is mitigation only, not a fix, and for LOW it belongs in routine tuning rather than emergency change.
4. Validate distro backports before opening tickets — Check package advisory status on Debian/Ubuntu/RHEL/SUSE before forcing upgrades just because a remote banner says < 2.4.35. For LOW, avoid wasting patch cycles on false positives caused by backported fixes.

Run this on the target Apache host as a user that can execute apachectl/httpd and read Apache config, ideally root or with sudo. Save as check_cve_2018_11763.sh and run sudo bash check_cve_2018_11763.sh /etc/httpd /etc/apache2; it checks the local Apache version, whether http2_module is loaded, and whether any config enables Protocols ... h2|h2c.

#!/usr/bin/env bash
# check_cve_2018_11763.sh
# Detect likely exposure to CVE-2018-11763 on Apache HTTP Server.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

CONFIG_PATHS=("${@}")
if [ ${#CONFIG_PATHS[@]} -eq 0 ]; then
  CONFIG_PATHS=(/etc/httpd /etc/apache2 /usr/local/etc/apache2)
fi

APACHECTL=""
for c in apachectl apache2ctl httpd; do
  if command -v "$c" >/dev/null 2>&1; then
    APACHECTL="$c"
    break
  fi
done

if [ -z "$APACHECTL" ]; then
  echo "UNKNOWN - apachectl/apache2ctl/httpd not found"
  exit 2
fi

get_version() {
  "$APACHECTL" -v 2>/dev/null | awk -F'[:/ ]+' '/Server version|Server built/ {for(i=1;i<=NF;i++) if($i ~ /^[0-9]+\.[0-9]+\.[0-9]+$/){print $i; exit}}'
}

ver_to_int() {
  local IFS=.
  local a b c
  read -r a b c <<< "$1"
  printf "%03d%03d%03d\n" "${a:-0}" "${b:-0}" "${c:-0}"
}

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

VINT="$(ver_to_int "$VERSION")"
LOW="$(ver_to_int "2.4.17")"
HIGH="$(ver_to_int "2.4.34")"
FIXED="$(ver_to_int "2.4.35")"

# Check whether mod_http2 is loaded.
MODULES="$($APACHECTL -M 2>/dev/null || true)"
HTTP2_LOADED=0
if printf '%s\n' "$MODULES" | grep -Eq '(^| )http2_module( |$)'; then
  HTTP2_LOADED=1
fi

# Search config for explicit Protocols enabling h2 or h2c.
HTTP2_ENABLED=0
SEARCH_HIT=""
for p in "${CONFIG_PATHS[@]}"; do
  if [ -e "$p" ]; then
    hit=$(grep -RIsnE '^\s*Protocols\s+.*\b(h2|h2c)\b' "$p" 2>/dev/null | head -n 1 || true)
    if [ -n "$hit" ]; then
      HTTP2_ENABLED=1
      SEARCH_HIT="$hit"
      break
    fi
  fi
done

# Backport caveat: package builds may be fixed while version remains < 2.4.35.
# If version is in range and HTTP/2 is enabled, report VULNERABLE-LIKELY.
if [ "$VINT" -lt "$LOW" ]; then
  echo "PATCHED - Apache $VERSION is older than 2.4.17; upstream says vulnerable code path starts at 2.4.17"
  exit 0
fi

if [ "$VINT" -ge "$FIXED" ]; then
  echo "PATCHED - Apache $VERSION is >= 2.4.35"
  exit 0
fi

if [ "$VINT" -ge "$LOW" ] && [ "$VINT" -le "$HIGH" ]; then
  if [ "$HTTP2_LOADED" -eq 1 ] && [ "$HTTP2_ENABLED" -eq 1 ]; then
    echo "VULNERABLE - Apache $VERSION is in the affected range, http2_module is loaded, and HTTP/2 appears enabled: $SEARCH_HIT"
    exit 1
  fi
  if [ "$HTTP2_LOADED" -eq 0 ] || [ "$HTTP2_ENABLED" -eq 0 ]; then
    echo "UNKNOWN - Apache $VERSION is in the affected range but HTTP/2 is not confirmed active (module_loaded=$HTTP2_LOADED, protocols_enabled=$HTTP2_ENABLED). Verify distro backports and runtime path."
    exit 2
  fi
fi

echo "UNKNOWN - unable to reach a confident verdict for Apache $VERSION"
exit 2

Sources

1. Tenable plugin 117807
2. Apache HTTP Server 2.4 vulnerability list
3. NVD CVE-2018-11763
4. Apache mod_http2 documentation
5. Apache HTTP/2 guide
6. Debian tracker CVE-2018-11763
7. Ubuntu CVE page
8. Red Hat RHSA-2019:0367