Like finding a fire exit jammed open, but only in the HTTP/2 wing of the building
Tenable plugin 183391 rolls up the Apache HTTP Server 2.4.58 security release, but the operationally relevant issues are the HTTP/2 flaws: CVE-2023-43622 and CVE-2023-45802. They affect Apache httpd versions 2.4.55 through 2.4.57 and 2.4.17 through 2.4.57 respectively, and only matter if mod_http2 is actually in play. The same release also fixed CVE-2023-31122 in mod_macro, but Apache labels that one low and it is rarely the driver for enterprise priority.
The vendor HIGH rating is too hot for most fleets. These are availability-only issues, not code execution, and the attack path narrows fast: the target needs exposed Apache, HTTP/2 enabled, enough attacker connection budget to pin workers or grow memory, and enough time to matter before normal timeouts, rate limits, upstream proxies, CDNs, or LB connection controls interfere. For public edge Apache with HTTP/2 enabled, it is worth fixing; for internal or HTTP/1.1-only deployments, this is patch-window work, not emergency work.
4 steps from start to impact.
Find an Apache target that actually speaks HTTP/2
mod_http2 enabled and HTTP/2 negotiated over TLS or cleartext upgrade paths. A version-only fingerprint is not enough; the issue is materially relevant only when the HTTP/2 code path is active.- Unauthenticated network reachability to the web server
- Apache httpd in an affected branch
mod_http2loaded and serving traffic
- Many enterprise Apache deployments still terminate HTTP/2 at a CDN, reverse proxy, or load balancer instead of at origin
- Internal-only Apache nodes are post-perimeter targets, not broad internet exposure
- Version-based scanners can overcall backported distro packages
apachectl -M or httpd -M rather than trusting banner strings alone.Abuse HTTP/2 flow control or RST behavior
- Ability to speak raw or scripted HTTP/2 to the target
- No authentication required
- Sufficient concurrent sockets or request churn
- This is protocol abuse, not a single-packet crash; the attacker needs sustained traffic control
- Connection limits, LB idle timeouts, CDN shielding, and HTTP/2 rate controls reduce practical leverage
- Apache itself notes the CVE-2023-45802 condition is unlikely during normal traffic
Accumulate worker or memory pressure
- Server has finite worker pool or constrained memory headroom
- Enough concurrent attacker traffic to outpace normal cleanup
- No upstream component absorbing or terminating the abuse first
- Horizontally scaled front ends, autoscaling, and upstream buffering dilute the effect
- EDR is irrelevant here, but WAF/CDN/LB controls often matter more than endpoint tooling
- Many enterprise services will fail open to upstream retries before full outage
Cause service degradation, not takeover
- Attack sustained long enough to impact capacity
- Target service is business-critical enough that partial outage matters
- Blast radius is usually one service tier, not instant estate-wide compromise
- Restart, timeout expiry, and upstream failover commonly restore service once traffic stops
The supporting signals.
| In-the-wild status | No CISA KEV listing was found for CVE-2023-43622 or CVE-2023-45802 in the retrieved CISA results, and Tenable says no known exploits are available for plugin 183391. |
|---|---|
| Proof-of-concept availability | No authoritative public PoC was surfaced in the retrieved primary sources for these exact CVEs. The closest practical weaponization path is adapting generic HTTP/2 abuse tooling and lessons from CVE-2023-44487 Rapid Reset. |
| EPSS / threat signal | FIRST documents daily EPSS scoring and API access, but the retrieved primary sources did not expose a current per-CVE number inline. The only vendor-side risk prior available here is Tenable VPR 4.4 / Medium, which aligns better with reality than the plugin's HIGH severity. |
| KEV status | Not KEV-listed in the retrieved CISA catalog results for either CVE-2023-43622 or CVE-2023-45802. |
| CVSS reality check | Tenable anchors the plugin on CVSS 7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H from CVE-2023-43622. That score assumes direct network reachability and full availability impact, but it does not account for the real friction of needing HTTP/2 enabled, sufficient socket budget, and an origin not shielded by upstream controls. |
| Affected versions | Apache lists CVE-2023-43622 as affecting 2.4.55–2.4.57 and CVE-2023-45802 as affecting 2.4.17–2.4.57. The same 2.4.58 release also fixed CVE-2023-31122 in mod_macro through 2.4.57. |
| Fixed versions | Upstream fix is Apache HTTP Server 2.4.58. Distros backported: Ubuntu fixed 22.04 LTS at 2.4.52-1ubuntu4.7 and 20.04 LTS at 2.4.41-4ubuntu3.15; Debian fixed bookworm at 2.4.59-1~deb12u1 and bullseye at 2.4.59-1~deb11u1. |
| Scanner fidelity | Tenable explicitly notes plugin 183391 relies on the application's self-reported version number and did not test exploitation. That means false positives are plausible on vendor-backported packages unless module state and distro package level are verified. |
| Disclosure timeline | Apache released 2.4.58 on 2023-10-19. NVD shows CVE-2023-43622 and CVE-2023-45802 published on 2023-10-23. |
| Reporting researchers | Apache credits Prof. Sven Dietrich, Isa Jafarov, Prof. Heejo Lee, and Choongin Lee for CVE-2023-43622; and Will Dormann and David Warren of Vul Labs for CVE-2023-45802. David Shoon reported the lower-value mod_macro issue CVE-2023-31122. |
noisgate verdict.
The decisive friction is feature-gated exposure: this matters primarily when Apache itself is serving HTTP/2, not merely when Apache is installed. On top of that, the impact is DoS only, with no strong evidence here of broad in-the-wild exploitation, which keeps this out of the HIGH bucket for most enterprise fleets.
Why this verdict
- Down from vendor CVSS because the path is narrower than the score implies: the meaningful issues require
mod_http2to be enabled, which cuts exposure sharply versus 'Apache installed somewhere.' - Availability impact only: the dominant CVEs here are worker starvation and memory growth, not RCE, auth bypass, or data theft.
- No strong real-world exploitation pressure in retrieved sources: no KEV hit, no authoritative public PoC surfaced, and Tenable itself says no known exploits are available.
- Operational controls often blunt it before patching does: CDNs, reverse proxies, LB idle timeouts, HTTP/2 connection controls, and rate-limiting materially reduce exploitability on real edge stacks.
- Detection quality is mediocre if you trust version strings alone: this is a version-based finding with backport caveats, so some flagged hosts will be effectively patched already.
Why not higher?
If this were an unauthenticated memory corruption or request-smuggling bug with straightforward internet reachability, it would stay HIGH. Instead, this is an HTTP/2-specific resource exhaustion problem whose blast radius is usually limited to the affected web tier and whose practical success depends on sustained traffic and topology gaps.
Why not lower?
Internet-facing Apache origins that terminate HTTP/2 directly are common enough that this is not ignorable hygiene. A successful attack can still cause painful outages on customer-facing services, and the affected version span for CVE-2023-45802 is broad enough that some real fleets will have reachable exposure.
What to do — in priority order.
- Disable
mod_http2where you do not need it — If a service does not require HTTP/2 end-to-end on Apache, turning it off collapses the main attack path for the two meaningful CVEs. Because this is a MEDIUM finding there is no noisgate mitigation SLA; use this as targeted hardening on exposed high-availability sites while you patch in the normal remediation window. - Push HTTP/2 termination upstream — Terminate HTTP/2 at a CDN, WAF, or load balancer and speak HTTP/1.1 to origin where architecture allows. This reduces direct origin exposure to protocol-abuse traffic and is a strong compensating control when patching must wait for maintenance windows.
- Tighten connection and rate controls — Lower abusive session dwell time with LB idle timeouts, per-client connection limits, and edge rate controls for anomalous HTTP/2 behavior. This does not fix the bug, but it raises attacker cost and reduces the chance of worker or memory exhaustion.
- Validate distro backports before opening change tickets — For Debian, Ubuntu, and SUSE fleets, check package versions against vendor advisories before treating every
Apache/2.4.57banner as vulnerable. This prevents wasting patch capacity on already-fixed backports during the ≤365 day remediation window.
- EDR on the web server does not meaningfully stop protocol-level worker starvation or memory pressure; this is a service-exhaustion problem, not a malware execution problem.
- Banner hiding does not help; the attacker only needs a reachable HTTP/2 origin, not a perfect version fingerprint.
- WAF signatures alone are weak here because the abuse is in connection behavior and HTTP/2 framing patterns, not a classic malicious URI or payload.
Crowdsourced verification payload.
Run this on the target Apache host as a user who can execute apachectl/httpd and read loaded modules; root is preferred but not strictly required. Example: sudo bash verify_apache_2458.sh — the script checks Apache version, loaded modules, and common distro package versions, then prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env bash
# verify_apache_2458.sh
# Purpose: assess exposure to Apache HTTP Server issues fixed in 2.4.58
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
status="UNKNOWN"
reason=""
have_cmd() { command -v "$1" >/dev/null 2>&1; }
ver_ge() {
# returns 0 if $1 >= $2 using sort -V
[ "$(printf '%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}
ver_gt() {
[ "$1" != "$2" ] && ver_ge "$1" "$2"
}
ver_lt() {
! ver_ge "$1" "$2"
}
get_httpd_info() {
local out=""
if have_cmd apachectl; then
out="$(apachectl -V 2>/dev/null || true)"
if [ -n "$out" ]; then printf '%s' "$out"; return 0; fi
fi
if have_cmd httpd; then
out="$(httpd -V 2>/dev/null || true)"
if [ -n "$out" ]; then printf '%s' "$out"; return 0; fi
fi
if have_cmd apache2ctl; then
out="$(apache2ctl -V 2>/dev/null || true)"
if [ -n "$out" ]; then printf '%s' "$out"; return 0; fi
fi
return 1
}
get_modules() {
local out=""
if have_cmd apachectl; then
out="$(apachectl -M 2>/dev/null || true)"
if [ -n "$out" ]; then printf '%s' "$out"; return 0; fi
fi
if have_cmd httpd; then
out="$(httpd -M 2>/dev/null || true)"
if [ -n "$out" ]; then printf '%s' "$out"; return 0; fi
fi
if have_cmd apache2ctl; then
out="$(apache2ctl -M 2>/dev/null || true)"
if [ -n "$out" ]; then printf '%s' "$out"; return 0; fi
fi
return 1
}
HTTPD_INFO="$(get_httpd_info || true)"
MODULES="$(get_modules || true)"
BASE_VER=""
if [ -n "$HTTPD_INFO" ]; then
BASE_VER="$(printf '%s\n' "$HTTPD_INFO" | sed -n 's/.*Server version: Apache\/\([0-9][0-9.]*\).*/\1/p' | head -n1)"
fi
HAS_HTTP2=0
HAS_MACRO=0
printf '%s\n' "$MODULES" | grep -Eq 'http2_module|mod_http2' && HAS_HTTP2=1
printf '%s\n' "$MODULES" | grep -Eq 'macro_module|mod_macro' && HAS_MACRO=1
# Check distro package versions first where possible, because backports matter.
if have_cmd dpkg-query; then
PKG_VER="$(dpkg-query -W -f='${Version}' apache2 2>/dev/null || true)"
if [ -n "$PKG_VER" ]; then
. /etc/os-release 2>/dev/null || true
UBUNTU_CODENAME="${VERSION_CODENAME:-}"
case "$UBUNTU_CODENAME" in
jammy)
if dpkg --compare-versions "$PKG_VER" ge "2.4.52-1ubuntu4.7"; then
echo "PATCHED - Ubuntu jammy apache2 package $PKG_VER includes fixes/backports relevant to 2.4.58 issues."
exit 0
fi
;;
focal)
if dpkg --compare-versions "$PKG_VER" ge "2.4.41-4ubuntu3.15"; then
echo "PATCHED - Ubuntu focal apache2 package $PKG_VER includes fixes/backports relevant to 2.4.58 issues."
exit 0
fi
;;
mantic)
if dpkg --compare-versions "$PKG_VER" ge "2.4.57-2ubuntu2.1"; then
echo "PATCHED - Ubuntu mantic apache2 package $PKG_VER includes fixes/backports relevant to 2.4.58 issues."
exit 0
fi
;;
lunar)
if dpkg --compare-versions "$PKG_VER" ge "2.4.55-1ubuntu2.1"; then
echo "PATCHED - Ubuntu lunar apache2 package $PKG_VER includes fixes/backports relevant to 2.4.58 issues."
exit 0
fi
;;
esac
# Debian bookworm/bullseye fixed in 2.4.59-1~deb12u1 / 2.4.59-1~deb11u1.
if printf '%s' "$PKG_VER" | grep -q 'deb12'; then
if dpkg --compare-versions "$PKG_VER" ge "2.4.59-1~deb12u1"; then
echo "PATCHED - Debian bookworm apache2 package $PKG_VER includes fixes/backports relevant to 2.4.58 issues."
exit 0
fi
fi
if printf '%s' "$PKG_VER" | grep -q 'deb11'; then
if dpkg --compare-versions "$PKG_VER" ge "2.4.59-1~deb11u1"; then
echo "PATCHED - Debian bullseye apache2 package $PKG_VER includes fixes/backports relevant to 2.4.58 issues."
exit 0
fi
fi
fi
fi
# Fall back to upstream-style version logic.
if [ -z "$BASE_VER" ]; then
echo "UNKNOWN - Could not determine Apache httpd version from apachectl/httpd."
exit 2
fi
if [ "$HAS_HTTP2" -eq 0 ] && [ "$HAS_MACRO" -eq 0 ]; then
echo "PATCHED - Neither mod_http2 nor mod_macro appears loaded; the 2.4.58 issues tracked by this check are not reachable in the active config."
exit 0
fi
VULN=0
DETAILS=""
if [ "$HAS_HTTP2" -eq 1 ]; then
if ver_ge "$BASE_VER" "2.4.17" && ver_lt "$BASE_VER" "2.4.58"; then
VULN=1
DETAILS="$DETAILS mod_http2-loaded: vulnerable to CVE-2023-45802;"
fi
if ver_ge "$BASE_VER" "2.4.55" && ver_lt "$BASE_VER" "2.4.58"; then
VULN=1
DETAILS="$DETAILS mod_http2-loaded: vulnerable to CVE-2023-43622;"
fi
fi
if [ "$HAS_MACRO" -eq 1 ]; then
if ver_lt "$BASE_VER" "2.4.58"; then
VULN=1
DETAILS="$DETAILS mod_macro-loaded: vulnerable to CVE-2023-31122;"
fi
fi
if [ "$VULN" -eq 1 ]; then
echo "VULNERABLE - Apache $BASE_VER.$DETAILS"
exit 1
fi
if ver_ge "$BASE_VER" "2.4.58"; then
echo "PATCHED - Upstream Apache version $BASE_VER is not below 2.4.58."
exit 0
fi
echo "UNKNOWN - Apache $BASE_VER is older than 2.4.58, but loaded-module or distro-backport evidence is inconclusive."
exit 2
If you remember one thing.
mod_http2 enabled versus everything else, and validate whether the finding is real or just version-string noise from distro backports. Because this is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use that noisgate remediation SLA to patch genuine exposures in the next normal server cycle, with edge-facing HTTP/2 origins first and backported Debian/Ubuntu/SUSE packages closed out as exceptions once verified.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.