The Apache HTTP Server 2

CVE-2016-1546 is an availability-only flaw in Apache HTTP Server's early mod_http2 implementation. In vulnerable builds, a client can abuse HTTP/2 flow-control windows so Apache keeps stream worker threads tied up for too long, eventually starving the worker pool. The affected upstream versions are 2.4.17 and 2.4.18 only, and only when mod_http2 is enabled and HTTP/2 is actually exposed with h2 or h2c.

The raw vendor/NVD baseline of 5.9 / MEDIUM is a little generous for enterprise patch triage in 2025. Yes, it is unauthenticated and remote, but the attack surface is sharply narrowed by an old two-version window, an optional module, and an HTTP/2-specific configuration requirement; there is also no confidentiality or integrity impact and no strong evidence of broad in-the-wild abuse. For a 10,000-host estate, this is backlog cleanup unless you still have externally exposed Apache 2.4.17/2.4.18 with HTTP/2 turned on.

Why this verdict

• Downward adjustment: optional feature gate — exploitation requires mod_http2, not plain Apache. In many real estates, that single prerequisite wipes out most of the nominally affected population.
• Downward adjustment: tiny version window — only 2.4.17 and 2.4.18 upstream are affected. This is not a sprawling 'all 2.4.x' bug.
• Downward adjustment: post-fingerprint precision — an attacker must find servers that are old *and* HTTP/2-enabled *and* directly reachable. That is materially narrower than a generic internet-wide web bug.
• Still not IGNORE — if the server is actually exposed, the attack is unauthenticated and remote and can cause real service degradation with modest attacker bandwidth.

Why not higher?

It is not higher because the blast radius is limited to availability, and the exploit chain is gated by a specific legacy configuration rather than normal Apache exposure. No strong primary-source evidence shows broad in-the-wild abuse, and modern estates often terminate HTTP/2 upstream or have long since moved past these releases.

Why not lower?

It is not lower because the attack does not require credentials, user interaction, or prior compromise. If you still run a directly exposed Apache 2.4.17/2.4.18 instance with HTTP/2 enabled, a remote adversary can realistically cause an outage on that node.

1. Disable HTTP/2 on stragglers — If a legacy server cannot be upgraded immediately, remove h2 / h2c from Protocols or unload mod_http2. For a LOW verdict, noisgate assigns no formal SLA here; do it in the next routine web maintenance cycle, and sooner if the host is internet-facing.
2. Terminate HTTP/2 upstream — Put the service behind a load balancer, CDN, or reverse proxy that terminates HTTP/2 and talks HTTP/1.1 to the old Apache backend. This breaks the vulnerable protocol path without changing application behavior; for LOW, treat this as backlog hygiene rather than an emergency change.
3. Tune connection and request timeouts — Shorter keepalive behavior, request timeouts, and HTTP/2-aware limits reduce how long a slow-reader can pin resources. This is a compensating control, not a guaranteed fix, and it should be applied during normal hardening work for any host you cannot retire yet.
4. Watch for H2 worker starvation — Instrument Apache status, reverse-proxy metrics, and host monitoring to alert on long-lived HTTP/2 streams with poor throughput and rising busy workers. For a LOW finding, fold this into standard observability improvements instead of spinning up a special response project.

Run this on the target Linux/Unix Apache host as a local auditor. Invoke it with bash check_cve_2016_1546.sh or bash check_cve_2016_1546.sh /usr/sbin/apachectl; it needs only enough privilege to execute apachectl/httpd config inspection commands, not full root in most deployments.

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

set -u

APACHECTL="${1:-}"

find_apachectl() {
  local candidates=(
    "$APACHECTL"
    /usr/sbin/apachectl
    /usr/sbin/httpd
    /usr/local/apache2/bin/apachectl
    /usr/local/bin/apachectl
    apachectl
    httpd
  )
  local c
  for c in "${candidates[@]}"; do
    [ -n "$c" ] || continue
    if command -v "$c" >/dev/null 2>&1; then
      command -v "$c"
      return 0
    elif [ -x "$c" ]; then
      echo "$c"
      return 0
    fi
  done
  return 1
}

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

APACHE_BIN="$(find_apachectl)" || {
  echo "UNKNOWN - could not locate apachectl/httpd"
  exit 2
}

VSTR="$($APACHE_BIN -v 2>/dev/null | awk -F'Apache/' '/Server version/ {print $2}' | awk '{print $1}')"
if [ -z "$VSTR" ]; then
  echo "UNKNOWN - could not determine Apache version via '$APACHE_BIN -v'"
  exit 2
fi

MAJMINPATCH="$VSTR"
MODULES="$($APACHE_BIN -M 2>/dev/null || true)"
RUNCFG="$($APACHE_BIN -t -D DUMP_RUN_CFG 2>/dev/null || true)"
FULLCFG="$($APACHE_BIN -t -D DUMP_VHOSTS 2>/dev/null || true)"

HTTP2_LOADED=0
if echo "$MODULES" | grep -Eq '(^|\s)http2_module(\s|$)'; then
  HTTP2_LOADED=1
fi

H2_ENABLED=0
if echo "$RUNCFG" | grep -Eiq '\bh2(c)?\b'; then
  H2_ENABLED=1
fi
# Fallback: parse common config locations if run_cfg did not expose protocol lines
if [ "$H2_ENABLED" -eq 0 ]; then
  for f in /etc/httpd/conf/httpd.conf /etc/apache2/apache2.conf /etc/apache2/sites-enabled/* /usr/local/apache2/conf/httpd.conf; do
    [ -r "$f" ] || continue
    if grep -Eiq '^[[:space:]]*Protocols[[:space:]].*\bh2(c)?\b' "$f" 2>/dev/null; then
      H2_ENABLED=1
      break
    fi
  done
fi

# Known-safe outcomes first
if ! echo "$MAJMINPATCH" | grep -Eq '^2\.4\.(17|18)$'; then
  if ver_ge "$MAJMINPATCH" "2.4.20"; then
    echo "PATCHED - Apache version $MAJMINPATCH is at or above upstream fix 2.4.20"
    exit 0
  fi
  # Older or vendor-backported builds are ambiguous
  if [ "$HTTP2_LOADED" -eq 0 ] || [ "$H2_ENABLED" -eq 0 ]; then
    echo "PATCHED - vulnerable HTTP/2 path not active (http2_module loaded=$HTTP2_LOADED, h2 enabled=$H2_ENABLED)"
    exit 0
  fi
  echo "UNKNOWN - Apache version $MAJMINPATCH is not an exact upstream vulnerable version, but runtime/backport status is unclear"
  exit 2
fi

# Exact upstream vulnerable versions
if [ "$HTTP2_LOADED" -eq 1 ] && [ "$H2_ENABLED" -eq 1 ]; then
  echo "VULNERABLE - Apache $MAJMINPATCH with mod_http2 loaded and HTTP/2 enabled"
  exit 1
fi

if [ "$HTTP2_LOADED" -eq 0 ] || [ "$H2_ENABLED" -eq 0 ]; then
  echo "PATCHED - Apache $MAJMINPATCH present, but vulnerable path not active (http2_module loaded=$HTTP2_LOADED, h2 enabled=$H2_ENABLED)"
  exit 0
fi

echo "UNKNOWN - unable to conclusively determine mod_http2/HTTP2 runtime state"
exit 2

Sources

1. Apache HTTP Server 2.4 vulnerabilities entry for CVE-2016-1546
2. NVD CVE-2016-1546
3. Apache mod_http2 documentation
4. Debian security tracker CVE-2016-1546
5. Ubuntu CVE-2016-1546 status
6. CISA Known Exploited Vulnerabilities Catalog
7. Imperva HTTP/2 in-depth analysis report
8. PRETT2 academic paper referencing CVE-2016-1546