This is less a skeleton key than a fire alarm you can keep ringing if Apache itself answers the HTTP/2 door
Tenable plugin 192923 rolls up three issues fixed in Apache HTTP Server 2.4.59: CVE-2024-27316 (HTTP/2 CONTINUATION-frame memory exhaustion DoS, affecting 2.4.17 through 2.4.58), plus CVE-2024-24795 and CVE-2023-38709 (response-splitting / desync style bugs affecting Apache through 2.4.58). The latter two are not clean pre-auth server-takeover bugs; they need malicious or exploitable backend content/header generation. Upstream fix is 2.4.59, with distro backports available in some package streams.
The vendor HIGH label is anchored to the worst CVSS in the bundle, but reality is narrower. The only broadly pre-auth bug here is an *availability* issue, and it matters mainly when Apache is directly terminating HTTP/2 on the internet; the other two flaws assume a compromised or attacker-influenced backend path. For an enterprise patch queue, that's a downgrade to MEDIUM unless you have a lot of directly exposed Apache mod_http2 listeners.
4 steps from start to impact.
Find Apache endpoints that actually speak HTTP/2
nmap, curl --http2, or masscan-plus-bannering can identify externally reachable listeners and whether ALPN offers h2.- Target is internet- or attacker-reachable
- Apache is directly exposed or reachable from the attacker's network segment
- HTTP/2 is enabled on the Apache service
- Many enterprises terminate HTTP/2 at Cloudflare, Akamai, ALB, NGINX, or Envoy before traffic ever hits Apache
- Internal-only Apache tiers are already post-initial-access scope, not internet perimeter scope
- Version-only scanner findings do not prove direct HTTP/2 reachability
Negotiate a direct HTTP/2 session
CVE-2024-27316, the attacker must establish a valid HTTP/2 connection and keep feeding header continuation traffic. This is a protocol abuse case, not a malformed-auth or RCE chain; the goal is resource pressure, not code execution.- Successful TCP/TLS connection to Apache
- ALPN or cleartext upgrade reaches Apache's HTTP/2 stack
- No upstream control strips or normalizes the session
- WAFs, CDNs, reverse proxies, and L7 gateways may terminate or inspect the session first
- Connection limits and timeout tuning can reduce effective attack throughput
- Some estates never load
mod_http2on Apache at all
Flood CONTINUATION frames with public PoC tooling
HTTP/2 CONTINUATION Flood technique, including repos referenced by threat-intel aggregators such as aeyesec/CVE-2024-27316_poc. The abuse keeps sending headers past expected limits so nghttp2 buffers data while Apache tries to prepare an error response.- Attacker can send sustained HTTP/2 traffic
- Apache version is in the vulnerable range or an unpatched distro build
- No effective upstream throttling stops the session
- Attack success is bandwidth and concurrency dependent
- Rate limiting, per-IP quotas, bot controls, and upstream HTTP/2 normalization can blunt the effect
- If Apache sits behind a proxy that converts client HTTP/2 to HTTP/1.1 upstream, this path dies there
Exhaust memory or workers and degrade availability
- Sustained malicious session volume reaches the vulnerable service
- No compensating edge control sheds the traffic
- Operational thresholds allow enough resource consumption to matter
- Autoscaling, LB health checks, and aggressive timeouts can contain outage duration
- Redundant web tiers reduce single-node impact
- This plugin does not include a clean privilege-gain or data-theft path
The supporting signals.
| In-the-wild status | No evidence found that these CVEs are in CISA KEV, and Tenable still states *no known exploits are available* for the plugin bundle. That matters because this is not a currently weaponized perimeter fire like prior Apache RCEs. |
|---|---|
| Proof-of-concept availability | CVE-2024-27316 has public research and PoC activity tied to the broader HTTP/2 CONTINUATION Flood work by Bartek Nowotarski; threat-intel aggregators also point to GitHub PoCs such as aeyesec/CVE-2024-27316_poc. Public writeups also exist for the response-splitting bugs, but those are less operationally useful without backend influence. |
| EPSS | For the dominant pre-auth issue CVE-2024-27316, Bitsight shows 89.41% EPSS, 100th percentile. That's a warning about attacker interest in the pattern, but it does not erase the reachability friction that Apache must directly terminate HTTP/2. |
| KEV status | Not KEV-listed for CVE-2024-27316, CVE-2024-24795, or CVE-2023-38709 based on current CISA catalog checks. |
| CVSS vector reality check | The bundle inherits HIGH from CVE-2024-27316 at 7.5 / CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Read that literally: *network, no auth, no user interaction, availability only*. No confidentiality or integrity loss is what keeps this out of the top patch tier. |
| Affected versions | CVE-2024-27316: Apache HTTP Server 2.4.17 to 2.4.58. CVE-2024-24795 and CVE-2023-38709: Apache HTTP Server through 2.4.58. |
| Fixed versions | Upstream fix is Apache HTTP Server 2.4.59. Example distro backports: Debian tracked fixes at 2.4.59-1~deb10u1, 2.4.59-1~deb11u1, and 2.4.59-1~deb12u1; Amazon Linux 1 shipped httpd24-2.4.59-1.102.amzn1 for the DoS issue. |
| Exposure/scanning data | Bitsight's Groma page for CVE-2024-27316 reports 4,229,863 total observations over the prior 30 days, with the US at 1,305,398 observations. That's *broad product footprint*, not proof every target is directly exploitable for this plugin; direct Apache HTTP/2 exposure is the real gate. |
| Disclosure timeline | Apache released 2.4.59 on 2024-04-04. The continuation-flood coordination work shows Apache httpd was confirmed affected on 2024-02-23 in Nowotarski's timeline. |
| Reporting researchers | CVE-2024-27316 traces to Bartek Nowotarski's HTTP/2 CONTINUATION Flood research. CVE-2024-24795 credits Keran Mu and Jianjun Chen from Tsinghua University and Zhongguancun Laboratory. CVE-2023-38709 is associated with Apache's April 2024 advisory stream. |
noisgate verdict.
The decisive downgrade factor is reachability: the headline 7.5 bug only matters where Apache itself is directly terminating HTTP/2, and that is narrower than raw Apache install count suggests in modern estates. The rest of the bundle depends on attacker-influenced backend behavior, which makes them post-misconfiguration or post-compromise amplifiers rather than clean perimeter takeover bugs.
Why this verdict
- Start at 7.5 because the bundle includes an unauthenticated network DoS on a very common web server, and public PoC material exists for the
CONTINUATIONflood technique. - Downgrade for attacker position and exposure reality: the exploit path requires the attacker to reach *Apache's own* HTTP/2 stack. If a CDN, ALB, WAF, NGINX, or Envoy terminates
h2first, the dominant bug is off the table. - Downgrade again for impact: the broadly reachable flaw is availability-only, while the response-splitting flaws require malicious or exploitable backend output. That is materially weaker than pre-auth RCE or auth bypass.
- No exploitation pressure override: no KEV listing and no convincing in-the-wild campaign evidence means there is no reason to keep this in the same bucket as actively exploited edge bugs.
Why not higher?
This is not a perimeter RCE, not an auth bypass, and not a data-theft issue. The highest-risk path is a DoS that depends on direct Apache HTTP/2 exposure, and many real deployments put a different HTTP/2 terminator in front of Apache. Without KEV or active exploitation, HIGH overstates the Monday-morning urgency.
Why not lower?
Don't get lazy here: if you do expose Apache mod_http2 directly, the dominant bug is unauthenticated and cheap for an attacker to exercise. Apache is also common enough that even a pure availability bug can create ugly operational blast radius on customer-facing estates, so this is still above backlog hygiene.
What to do — in priority order.
- Terminate HTTP/2 upstream — Move
h2termination to a patched CDN, load balancer, or reverse proxy where possible, or temporarily disablemod_http2on internet-facing Apache nodes. For a MEDIUM verdict there is no noisgate mitigation SLA; use this selectively on exposed edge systems while you work the normal remediation window. - Rate-limit abusive header behavior — Apply connection caps, request-rate controls, bot management, and header-size / timeout enforcement at the edge so continuation-flood traffic dies before it can pin Apache memory. Again, no noisgate mitigation SLA for MEDIUM, so prioritize only the directly exposed listeners.
- Audit proxy and backend header handling — Review applications and reverse-proxy flows for user-controlled values reaching response headers, because
CVE-2024-24795andCVE-2023-38709need backend/header influence to become useful. Fold this into your normal hardening and remediate within the MEDIUM patch window. - Tune visibility on HTTP/2 failures — Alert on memory spikes, worker exhaustion, restart loops, and unusual HTTP/2 connection patterns on Apache front ends. This won't fix the bug, but it shortens mean time to detect if someone starts stress-testing your edge.
- Relying on EDR alone does not help much; this is protocol abuse over normal sockets, not malware execution.
- Hiding or removing the Apache version banner does not materially reduce risk; the attacker cares about reachable HTTP/2 behavior, not your
Serverheader. - Blocking vulnerability scanner IPs is irrelevant; exploitation does not require a scanner or a special signature.
Crowdsourced verification payload.
Run this on the target Apache host with local shell access; root is preferred because module and package checks are more reliable. Save as check_apache_2459.sh, then run bash check_apache_2459.sh or bash check_apache_2459.sh /usr/sbin/httpd. It outputs VULNERABLE, PATCHED, or UNKNOWN and exits 0, 1, or 2 respectively.
#!/usr/bin/env bash
# check_apache_2459.sh
# Detect likely exposure for Tenable plugin 192923 (Apache httpd < 2.4.59 bundle)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
APACHE_BIN="${1:-}"
OS_ID=""
OS_VERSION_ID=""
STATUS="UNKNOWN"
DETAILS=()
add_detail() {
DETAILS+=("$1")
}
version_lt() {
# returns 0 if $1 < $2
[ "$(printf '%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}
version_ge() {
# returns 0 if $1 >= $2
! version_lt "$1" "$2"
}
load_os_release() {
if [ -r /etc/os-release ]; then
# shellcheck disable=SC1091
. /etc/os-release
OS_ID="${ID:-}"
OS_VERSION_ID="${VERSION_ID:-}"
fi
}
find_apache_bin() {
if [ -n "$APACHE_BIN" ] && [ -x "$APACHE_BIN" ]; then
return 0
fi
for b in /usr/sbin/httpd /usr/sbin/apache2 /usr/local/apache2/bin/httpd $(command -v httpd 2>/dev/null) $(command -v apache2 2>/dev/null); do
if [ -n "$b" ] && [ -x "$b" ]; then
APACHE_BIN="$b"
return 0
fi
done
return 1
}
get_upstream_version() {
local out ver
out="$($APACHE_BIN -v 2>/dev/null || true)"
ver="$(printf '%s\n' "$out" | sed -n 's/^Server version: .*\/\([0-9][0-9.]*\).*/\1/p' | head -n1)"
printf '%s' "$ver"
}
http2_enabled() {
local ctl out
for ctl in apachectl apache2ctl "$APACHE_BIN"; do
if command -v "$ctl" >/dev/null 2>&1 || [ -x "$ctl" ]; then
out="$($ctl -M 2>/dev/null || true)"
if printf '%s' "$out" | grep -Eq 'http2_module|mod_http2'; then
return 0
fi
fi
done
return 1
}
check_dpkg_backport() {
if ! command -v dpkg-query >/dev/null 2>&1 || ! command -v dpkg >/dev/null 2>&1; then
return 2
fi
local pkgver fixed
pkgver="$(dpkg-query -W -f='${Version}' apache2 2>/dev/null || true)"
[ -n "$pkgver" ] || return 2
add_detail "dpkg apache2=$pkgver"
case "$OS_VERSION_ID" in
10) fixed='2.4.59-1~deb10u1' ;;
11) fixed='2.4.59-1~deb11u1' ;;
12) fixed='2.4.59-1~deb12u1' ;;
*) return 2 ;;
esac
if dpkg --compare-versions "$pkgver" ge "$fixed"; then
STATUS="PATCHED"
add_detail "Debian backport threshold met ($fixed)"
return 0
else
STATUS="VULNERABLE"
add_detail "Debian package below fixed threshold ($fixed)"
return 1
fi
}
check_rpm_backport() {
if ! command -v rpm >/dev/null 2>&1; then
return 2
fi
local pkgver
pkgver="$(rpm -q --qf '%{VERSION}-%{RELEASE}' httpd24 2>/dev/null || true)"
if [ -n "$pkgver" ] && [ "$pkgver" != 'package httpd24 is not installed' ]; then
add_detail "rpm httpd24=$pkgver"
case "$OS_ID" in
amzn)
if printf '%s\n' "$pkgver" | grep -Eq '^2\.4\.59-1\.102\.amzn1'; then
STATUS="PATCHED"
add_detail "Amazon Linux 1 httpd24 fixed build detected"
return 0
fi
;;
esac
fi
pkgver="$(rpm -q --qf '%{VERSION}-%{RELEASE}' httpd 2>/dev/null || true)"
if [ -n "$pkgver" ] && ! printf '%s' "$pkgver" | grep -q '^package '; then
add_detail "rpm httpd=$pkgver"
fi
return 2
}
main() {
load_os_release
if ! find_apache_bin; then
echo "UNKNOWN - Apache binary not found"
exit 2
fi
add_detail "apache_bin=$APACHE_BIN"
[ -n "$OS_ID" ] && add_detail "os=$OS_ID $OS_VERSION_ID"
local ver
ver="$(get_upstream_version)"
if [ -z "$ver" ]; then
echo "UNKNOWN - Could not determine Apache version (${DETAILS[*]})"
exit 2
fi
add_detail "upstream_version=$ver"
# First handle known distro backports so we do not false-positive on package-maintained builds.
check_dpkg_backport || true
if [ "$STATUS" = "PATCHED" ]; then
echo "PATCHED - ${DETAILS[*]}"
exit 0
elif [ "$STATUS" = "VULNERABLE" ]; then
echo "VULNERABLE - ${DETAILS[*]}"
exit 1
fi
check_rpm_backport || true
if [ "$STATUS" = "PATCHED" ]; then
echo "PATCHED - ${DETAILS[*]}"
exit 0
fi
# Upstream version logic
if version_ge "$ver" "2.4.59"; then
echo "PATCHED - ${DETAILS[*]}"
exit 0
fi
if version_ge "$ver" "2.4.17" && version_lt "$ver" "2.4.59"; then
if http2_enabled; then
add_detail "http2_module=enabled"
else
add_detail "http2_module=not-detected"
fi
echo "VULNERABLE - ${DETAILS[*]}"
exit 1
fi
echo "UNKNOWN - Version outside expected vulnerable range or unsupported packaging (${DETAILS[*]})"
exit 2
}
main "$@"
If you remember one thing.
192923, then immediately separate internet-facing Apache nodes that directly terminate HTTP/2 from everything else. For this MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but if you find edge nodes with direct mod_http2 exposure, use temporary controls like upstream HTTP/2 termination or rate limits while you schedule the upgrade. Apply any temporary control on those exposed nodes now as a risk-reduction choice, then complete the actual upgrade to 2.4.59 or distro-fixed backports inside the noisgate remediation SLA of ≤365 days.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.