← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:192923 · CWE-770 · Disclosed 2024-04-04

Apache 2

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"High on paper, medium in practice: mostly an HTTP/2 DoS with real reachability friction and no current exploitation signal."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find Apache endpoints that actually speak HTTP/2

The attacker first needs a target where Apache itself, not a CDN or load balancer, is negotiating HTTP/2. Commodity tooling like nmap, curl --http2, or masscan-plus-bannering can identify externally reachable listeners and whether ALPN offers h2.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: External scanners will find the version, but they usually do not verify whether Apache itself is the HTTP/2 terminator.
STEP 02

Negotiate a direct HTTP/2 session

For 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.
Conditions required:
  • Successful TCP/TLS connection to Apache
  • ALPN or cleartext upgrade reaches Apache's HTTP/2 stack
  • No upstream control strips or normalizes the session
Where this breaks in practice:
  • 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_http2 on Apache at all
Detection/coverage: Look for unusually long-lived or repeated HTTP/2 sessions with oversized header activity, connection churn, and memory growth on the target.
STEP 03

Flood CONTINUATION frames with public PoC tooling

Public research and PoC code exist for the 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Network telemetry and reverse-proxy logs are more useful than host EDR here; the payload is protocol behavior, not malware.
STEP 04

Exhaust memory or workers and degrade availability

The impact is service instability: rising memory use, worker starvation, failed requests, and possible process restarts or node eviction. In clustered environments the blast radius is usually bounded to the directly hit web tier unless autoscaling or health checks amplify it.
Conditions required:
  • Sustained malicious session volume reaches the vulnerable service
  • No compensating edge control sheds the traffic
  • Operational thresholds allow enough resource consumption to matter
Where this breaks in practice:
  • 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
Detection/coverage: Expect spikes in resident memory, worker/thread exhaustion, 5xx rates, connection resets, and restart events. Nessus itself is version-based here and won't prove exploitability.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 availabilityCVE-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.
EPSSFor 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 statusNot KEV-listed for CVE-2024-27316, CVE-2024-24795, or CVE-2023-38709 based on current CISA catalog checks.
CVSS vector reality checkThe 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 versionsCVE-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 versionsUpstream 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 dataBitsight'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 timelineApache 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 researchersCVE-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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

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.

HIGH Technical characterization of the covered CVEs and fixed version
MEDIUM Population-level estimate that many enterprises terminate HTTP/2 upstream of Apache
MEDIUM Operational priority downgrade from vendor HIGH to enterprise MEDIUM

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 CONTINUATION flood 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 h2 first, 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.

05 · Compensating Control

What to do — in priority order.

  1. Terminate HTTP/2 upstream — Move h2 termination to a patched CDN, load balancer, or reverse proxy where possible, or temporarily disable mod_http2 on 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.
  2. 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.
  3. Audit proxy and backend header handling — Review applications and reverse-proxy flows for user-controlled values reaching response headers, because CVE-2024-24795 and CVE-2023-38709 need backend/header influence to become useful. Fold this into your normal hardening and remediate within the MEDIUM patch window.
  4. 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.
What doesn't work
  • 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 Server header.
  • Blocking vulnerability scanner IPs is irrelevant; exploitation does not require a scanner or a special signature.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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 "$@"
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: pull a list of all Apache findings for plugin 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

  1. Tenable plugin 192923
  2. Apache HTTP Server 2.4 vulnerabilities
  3. NVD CVE-2024-27316
  4. NVD CVE-2023-38709
  5. CERT/CC VU#421644 HTTP/2 CONTINUATION Flood
  6. Bartek Nowotarski HTTP/2 CONTINUATION Flood
  7. Debian security tracker CVE-2023-38709
  8. Bitsight Groma CVE-2024-27316 observation footprint
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.