Double Free and possible RCE vulnerability in Apache HTTP Server with the HTTP/2 protocol

CVE-2026-23918 is a CWE-415 double-free in Apache HTTP Server's mod_http2 early-reset path. The vendor advisory, NVD, and oss-security all line up on one key fact: the affected upstream release is Apache HTTP Server 2.4.66, fixed in 2.4.67. In practice, a host is meaningfully exposed only when mod_http2 is loaded and HTTP/2 is actually enabled for reachable listeners.

The vendor's HIGH 8.8 baseline is directionally fair for an actually exposed host because the attacker position is strong: network reachability, no user interaction, and denial-of-service is credible with possible RCE under favorable heap conditions. But the real-world population is much smaller than a typical Apache bug because this is a single-version regression, many enterprise distros shipped fixes via backports or were never on 2.4.66 at all, and there is no KEV listing or solid in-the-wild exploitation evidence. That pushes this down from panic-grade to targeted-high.

Why this verdict

• Downgraded for exposure math: this is not a broad Apache class break; it is a single-version regression centered on upstream 2.4.66.
• Downgraded for deployment prerequisites: the host also needs mod_http2 loaded and HTTP/2 enabled on a reachable service path. That excludes a meaningful chunk of Apache fleets behind proxies, CDNs, or HTTP/1.1-only configs.
• Downgraded for distro reality: Debian bullseye is marked not affected, Ubuntu says only 26.04 LTS was affected in its supported set, and Red Hat tracking says RHEL mod_http2 builds were confirmed not vulnerable.
• Held at HIGH because attacker position is still strong on exposed nodes: the vulnerable path is remote, no user interaction is needed, and public tooling exists to exercise the bug path.
• Held at HIGH because possible RCE rides on top of a memory-safety flaw: even if most real outcomes are crash-first, internet-facing memory corruption in a web server should not be treated as routine backlog work.

Why not higher?

There is no KEV entry, no solid public evidence of active exploitation in the reviewed sources, and no demonstrated ecosystem-wide reliable RCE chain. Most importantly, the affected population is constrained by a single upstream version plus a protocol/module requirement, which sharply limits the number of enterprise hosts that are actually reachable to this bug.

Why not lower?

Once you do have an exposed 2.4.66 + HTTP/2 host, the attacker does not need prior foothold, phishing, or local access. That keeps this above MEDIUM: it is still an internet-facing memory-corruption issue with at least credible denial-of-service and plausible code-execution upside.

1. Disable HTTP/2 where you can — Remove h2/h2c from Protocols or unload mod_http2 on affected Apache 2.4.66 systems that cannot be patched immediately. This directly removes the vulnerable code path and, for a HIGH verdict, should be deployed within 30 days.
2. Put a proxy in front of stragglers — If the application must stay up, terminate HTTP/2 on a CDN, load balancer, or reverse proxy and speak HTTP/1.1 to the backend Apache node. That reduces direct attacker reachability to the vulnerable parser and should be implemented within 30 days for any remaining exposed 2.4.66 instances.
3. Alert on child crashes and restarts — Create detections for httpd/apache2 segfaults, core dumps, abnormal worker exits, and restart bursts. This will not stop exploitation, but it is the best short-term signal for attempted trigger activity while mitigations are being rolled out within the 30-day window.
4. Hunt for exact version plus module state — Inventory hosts for upstream 2.4.66, then intersect with http2_module loaded and Protocols exposing h2 or h2c. Do this first so you patch the real blast radius instead of burning cycles on unaffected Apache servers; complete the hunt inside the 30-day HIGH mitigation window.

Run this on the target Linux host that runs Apache, not from an auditor workstation. Invoke it as bash cve-2026-23918-check.sh with a user that can run apachectl/httpd -M and read Apache config files; root is helpful but not strictly required.

#!/usr/bin/env bash
# CVE-2026-23918 Apache HTTP/2 exposure check
# Exit codes:
#   0 = PATCHED / not vulnerable
#   1 = VULNERABLE
#   2 = UNKNOWN / could not determine

set -u

say() { printf '%s\n' "$*"; }
fail_unknown() { say "UNKNOWN - $*"; exit 2; }
patched() { say "PATCHED - $*"; exit 0; }
vuln() { say "VULNERABLE - $*"; exit 1; }

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

[ -n "$APACHECTL" ] || fail_unknown "Apache control binary not found"

VER_OUT="$($APACHECTL -v 2>/dev/null || true)"
[ -n "$VER_OUT" ] || fail_unknown "Could not read Apache version with '$APACHECTL -v'"

SERVER_VER="$(printf '%s\n' "$VER_OUT" | sed -n 's#.*Apache/\([0-9][0-9.]*\).*#\1#p' | head -n1)"
[ -n "$SERVER_VER" ] || fail_unknown "Could not parse Apache version from: $VER_OUT"

MODULES="$($APACHECTL -M 2>/dev/null || true)"
if [ -z "$MODULES" ]; then
  MODULES="$($APACHECTL -l 2>/dev/null || true)"
fi

HTTP2_LOADED="no"
printf '%s\n' "$MODULES" | grep -Eiq '(^|\s)http2_module(\s|$)|mod_http2' && HTTP2_LOADED="yes"

CONF_ROOTS="/etc/apache2 /etc/httpd /usr/local/apache2/conf"
HTTP2_ENABLED="unknown"
FOUND_PROTOCOLS=""
for root in $CONF_ROOTS; do
  if [ -d "$root" ]; then
    MATCHES="$(grep -RniE '^[[:space:]]*Protocols[[:space:]].*(h2|h2c)' "$root" 2>/dev/null || true)"
    if [ -n "$MATCHES" ]; then
      HTTP2_ENABLED="yes"
      FOUND_PROTOCOLS="$MATCHES"
      break
    fi
  fi
done

if [ "$HTTP2_ENABLED" = "unknown" ]; then
  if [ "$HTTP2_LOADED" = "no" ]; then
    HTTP2_ENABLED="no"
  fi
fi

PKG_INFO=""
if command -v dpkg-query >/dev/null 2>&1; then
  PKG_INFO="$(dpkg-query -W -f='${Package} ${Version}\n' apache2 2>/dev/null || true)"
elif command -v rpm >/dev/null 2>&1; then
  PKG_INFO="$(rpm -q httpd mod_http2 2>/dev/null || true)"
fi

# Known safe/not-affected distro cases from vendor/distro advisories
if printf '%s\n' "$PKG_INFO" | grep -Eq 'apache2 2\.4\.52-1ubuntu4\.20|apache2 2\.4\.58-1ubuntu8\.12|apache2 2\.4\.64-1ubuntu3\.4|apache2 2\.4\.66-2ubuntu2\.1'; then
  patched "Ubuntu fixed package detected: $(printf '%s' "$PKG_INFO" | tr '\n' '; ')"
fi
if printf '%s\n' "$PKG_INFO" | grep -Eq 'apache2 2\.4\.67-1~deb11u1|apache2 2\.4\.67-1~deb12u2|apache2 2\.4\.67-1~deb13u2|apache2 2\.4\.67-1\b'; then
  patched "Debian fixed package detected: $(printf '%s' "$PKG_INFO" | tr '\n' '; ')"
fi
if printf '%s\n' "$PKG_INFO" | grep -Eq '^httpd-|^mod_http2-' ; then
  # RHEL/Fedora packaging is complicated here; Red Hat says RHEL builds were not vulnerable,
  # but we avoid over-claiming for all RPM-based environments without exact product context.
  :
fi

if [ "$SERVER_VER" != "2.4.66" ]; then
  patched "Apache version is $SERVER_VER, and upstream advisory limits CVE-2026-23918 to 2.4.66"
fi

# At this point Apache version is 2.4.66.
if [ "$HTTP2_LOADED" = "no" ]; then
  patched "Apache 2.4.66 is present, but mod_http2 does not appear to be loaded"
fi

if [ "$HTTP2_ENABLED" = "yes" ]; then
  vuln "Apache 2.4.66 with mod_http2 loaded and HTTP/2 enabled detected. Matching Protocols lines: $(printf '%s' "$FOUND_PROTOCOLS" | head -n 3 | tr '\n' ' ' )"
fi

if [ "$HTTP2_ENABLED" = "no" ]; then
  patched "Apache 2.4.66 with mod_http2 loaded, but no HTTP/2 Protocols directives were found"
fi

fail_unknown "Apache 2.4.66 detected and mod_http2 appears loaded, but HTTP/2 enablement could not be determined from standard config paths"

Sources

1. Apache HTTP Server 2.4 vulnerabilities
2. NVD CVE-2026-23918
3. oss-security disclosure
4. Debian Security Tracker CVE-2026-23918
5. Ubuntu USN-8239-1
6. Apache mod_http2 documentation
7. GitHub Advisory GHSA-p8fm-9c82-pw4g
8. CISA Known Exploited Vulnerabilities Catalog