← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:111788 · Disclosed 2018-07-15

Apache 2

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

This is a fire alarm wired to every building even though only the rooms with a specific heater can actually overheat

Tenable plugin 111788 rolls up two Apache httpd issues fixed in 2.4.34: CVE-2018-1333, a worker-exhaustion DoS in mod_http2, and CVE-2018-8011, a NULL dereference DoS in mod_md. The catch matters: CVE-2018-1333 affects 2.4.18-2.4.30 and 2.4.33 only, and only where HTTP/2 support is actually built, loaded, and reachable; CVE-2018-8011 affects only 2.4.33 and only if the experimental mod_md module is in play.

The vendor HIGH/7.5 baseline is technically defensible in CVSS terms because both bugs are unauthenticated and network-reachable, but it overstates operational reality. In enterprise fleets this is a configuration-gated, availability-only problem with a lot of false-positive surface from banner-based detection, distro backports, and untouched hosts on 2.4.31/2.4.32 that are below 2.4.34 yet not affected by either listed CVE.

"This is mostly a version-check scare: real risk exists, but only on the small slice running vulnerable HTTP/2 or mod_md"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a direct Apache origin with the right module loaded

The attacker first needs a host where the vulnerable code path is present, not just an old Apache banner. For CVE-2018-1333, that means mod_http2; for CVE-2018-8011, that means mod_md, which Apache documents as experimental and SUSE noted it did not ship at the time. Common recon tooling is just nmap, curl, or passive banner collection.
Conditions required:
  • Internet or internal network reachability to the Apache origin
  • Affected upstream version or an unpatched backport
  • mod_http2 loaded for CVE-2018-1333 or mod_md loaded for CVE-2018-8011
Where this breaks in practice:
  • Tenable flags by self-reported version, so many hits are not actually vulnerable
  • mod_md population is tiny because it is experimental
  • Some distro builds did not even enable HTTP/2 in affected releases
Detection/coverage: Nessus plugin 111788 is version-based only; configuration-aware validation is required.
STEP 02

Negotiate the vulnerable protocol or endpoint

For CVE-2018-1333, the attacker has to speak HTTP/2 using tools such as nghttp, curl --http2, or a custom frame sender. For CVE-2018-8011, a crafted HTTP request must reach the ACME challenge handling path exercised by mod_md.
Conditions required:
  • HTTP/2 actually enabled and reachable for CVE-2018-1333
  • Relevant mod_md challenge handling reachable for CVE-2018-8011
Where this breaks in practice:
  • Reverse proxies, CDNs, or load balancers may terminate client HTTP/2 before the origin
  • Internal-only admin or ACME challenge paths shrink exposure further
  • Some deployments expose only HTTP/1.1 to clients
Detection/coverage: Web server access logs can show HTTP/2.0 negotiation and repeated malformed requests; reverse proxies may see this first.
STEP 03

Send crafted frames or requests to burn workers or crash a child

With CVE-2018-1333, specially crafted HTTP/2 requests cause workers to stay allocated longer than needed, pushing the server toward exhaustion. With CVE-2018-8011, a crafted request can dereference a NULL pointer in the mod_md challenge handler and crash a child process. Commodity traffic generators are enough once the vulnerable path is confirmed.
Conditions required:
  • Sustained ability to send crafted requests
  • No upstream control blocking abusive connection patterns
Where this breaks in practice:
  • Rate limiting, connection caps, and proxy buffering can blunt worker starvation
  • Process managers and watchdog restarts reduce persistence of single-child crashes
  • Multi-tier architectures hide the origin behind more resilient edges
Detection/coverage: Look for spikes in server-status, worker saturation, AH crash messages, child restarts, and origin 5xx bursts.
STEP 04

Cause localized availability impact, not takeover

The practical end state is service degradation or outage on the affected origin, not code execution or data theft. Even on a successful attack, the blast radius is usually one web tier or vhost pool unless that Apache instance fronts something especially critical.
Conditions required:
  • Target service is business-relevant enough that degraded availability matters
Where this breaks in practice:
  • No confidentiality or integrity impact
  • HA pairs, autoscaling, and reverse proxies reduce business impact
  • Attacker gets disruption, not foothold
Detection/coverage: Synthetic uptime checks, load balancer health failures, and host service restarts should catch impact quickly.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo authoritative evidence of active exploitation found. Tenable marks Exploit Ease: No known exploits are available, and neither CVE appears in CISA KEV.
Proof-of-concept availabilityNo widely adopted named exploit chain surfaced in primary vendor references. Reproduction is low-complexity with standard tools like curl --http2 or nghttp once a vulnerable config is identified.
EPSSCVE-2018-1333 shows EPSS 0.15119 on Tenable. CVE-2018-8011 is listed by CIRCL with EPSS 0.77676 and 99.013 percentile, but that inflated exploit-likelihood signal does not match the tiny real-world exposure of experimental mod_md.
KEV statusNot listed in the CISA KEV catalog as of the catalog results currently available.
CVSS vectorCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — pure availability impact, no data access or integrity change.
Affected versionsCVE-2018-1333: 2.4.18-2.4.30 and 2.4.33, only with HTTP/2 support. CVE-2018-8011: only 2.4.33, only with mod_md.
Fixed versionsUpstream fix is Apache HTTP Server 2.4.34. Example distro backports include Ubuntu 18.04 package 2.4.29-1ubuntu4.4; older distro package numbers may still be patched despite looking older than 2.4.34.
Exposure realityApache is broadly deployed, but this vuln is not broadly reachable. Apache's own docs show HTTP/2 requires explicit build/module enablement, and Ubuntu notes some affected releases did not enable HTTP/2 in the build. Censys has shown HTTP/2 is common on the internet in general, but that is only an upper-bound protocol signal, not evidence that vulnerable Apache origins are exposed.
Disclosure timelineApache released 2.4.34 on 2018-07-15; the individual CVEs were published in mid-July 2018, and Tenable published plugin 111788 on 2018-08-16.
Researchers / reportingCVE-2018-1333 was credited to Craig Young of Tripwire VERT. CVE-2018-8011 was credited to Daniel Caminada.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.6/10)

The decisive factor is exposure narrowing: this is not a generic 'Apache <2.4.34' internet RCE, it is an availability-only issue that needs mod_http2 or the experimental mod_md to be present and reachable. That sharply cuts the affected population and turns many scanner hits into version-only noise rather than urgent enterprise patch work.

HIGH Severity downgrade from the vendor `HIGH` baseline
HIGH Configuration-gated exploitability (`mod_http2` / `mod_md`)
MEDIUM Real-world exposed population size in large fleets

Why this verdict

  • Downgrade for feature gating: CVE-2018-1333 only exists if HTTP/2 is actually built, loaded, and reachable; CVE-2018-8011 only exists on 2.4.33 with experimental mod_md.
  • Downgrade for attack outcome: both bugs are DoS-only. No credential theft, no auth bypass, no code execution, no durable foothold.
  • Downgrade for detection quality: plugin 111788 explicitly relies on self-reported version and does not test exploitability, so 2.4.31/2.4.32 and patched backports create avoidable false positives.
  • Hold at MEDIUM because attacker position is still remote unauthenticated: if you do run exposed vulnerable HTTP/2 origins, disruption is cheap to attempt and can hurt customer-facing uptime.

Why not higher?

It is not higher because this is not a broad, default-path remote compromise. Real exploitation requires a narrower subset of Apache deployments, and the impact ceiling is service degradation or child-process crashes rather than system takeover. In a 10,000-host estate, that means you should validate and target the exposed slice, not declare fleet-wide emergency patching.

Why not lower?

It is not lower because the attacker does not need credentials and can hit the service over the network if the right module is exposed. For internet-facing revenue or customer portals, even availability-only flaws can become operationally painful, so confirmed vulnerable edge hosts should not be ignored.

05 · Compensating Control

What to do — in priority order.

  1. Disable HTTP/2 where you do not need it — On confirmed vulnerable pre-2.4.34 origins, removing mod_http2 or dropping Protocols h2 collapses the CVE-2018-1333 path entirely. Because this verdict is MEDIUM, there is no mitigation SLA; apply in the normal change cycle, focusing first on public-facing origins.
  2. Unload mod_md if unused — If you are not using Apache-managed ACME certificate workflows, remove or disable mod_md; that eliminates the CVE-2018-8011 path. This is especially attractive because mod_md is an optional, experimental module rather than core web serving functionality.
  3. Put vulnerable origins behind a proxy with connection controls — Reverse proxies, CDNs, and load balancers can absorb abusive connection patterns and prevent raw client traffic from directly starving origin workers. For MEDIUM, do this opportunistically as part of standard hardening rather than as an emergency change.
  4. Tune worker and rate limits — Connection caps, request timeouts, and edge rate limiting reduce the practical effect of worker exhaustion attacks and shorten recovery from abusive clients. This does not fix the bug, but it lowers outage probability while you work through normal remediation.
What doesn't work
  • EDR will not meaningfully stop an HTTP/2 worker-starvation bug; this is a protocol-path availability issue, not malware execution.
  • WAF signatures are not a reliable answer here because the bug lives in protocol/module behavior and may trigger before app-layer logic is useful.
  • Blindly keying off the Apache version string does not work because distro backports and unaffected 2.4.31/2.4.32 builds make that signal noisy.
06 · Verification

Crowdsourced verification payload.

Run this on the target Apache host, not from an auditor workstation. Save as check_apache_111788.sh and execute sudo bash check_apache_111788.sh /usr/sbin/apachectl; root is recommended so module listing works reliably and package metadata can be read.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_apache_111788.sh
# Validate exposure for Tenable plugin 111788 / Apache < 2.4.34 multiple vulns
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

INPUT_BIN="${1:-}"
APACHECTL=""
HTTPD_BIN=""
PKGVER=""
UPSTREAM_VER=""
MODULES=""
HAS_HTTP2=0
HAS_MD=0

find_bin() {
  local x
  for x in "$@"; do
    if [ -n "$x" ] && command -v "$x" >/dev/null 2>&1; then
      command -v "$x"
      return 0
    fi
    if [ -n "$x" ] && [ -x "$x" ]; then
      echo "$x"
      return 0
    fi
  done
  return 1
}

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

version_gt() {
  [ "$1" != "$2" ] && version_ge "$1" "$2"
}

version_lt() {
  ! version_ge "$1" "$2"
}

# Locate control/binary
if [ -n "$INPUT_BIN" ]; then
  APACHECTL="$(find_bin "$INPUT_BIN")" || true
fi

if [ -z "$APACHECTL" ]; then
  APACHECTL="$(find_bin apachectl apache2ctl /usr/sbin/apachectl /usr/sbin/apache2ctl httpd /usr/sbin/httpd)" || true
fi

if [ -z "$APACHECTL" ]; then
  echo "UNKNOWN - Apache control binary not found"
  exit 2
fi

HTTPD_BIN="$APACHECTL"

# Collect version string
VER_OUT="$($HTTPD_BIN -v 2>/dev/null || true)"
UPSTREAM_VER="$(printf '%s\n' "$VER_OUT" | sed -n 's/.*Apache\/\([0-9][0-9.]*\).*/\1/p' | head -n1)"

if [ -z "$UPSTREAM_VER" ]; then
  echo "UNKNOWN - Could not parse Apache version from: $HTTPD_BIN"
  exit 2
fi

# Collect loaded modules
MODULES="$($APACHECTL -M 2>/dev/null || true)"
printf '%s\n' "$MODULES" | grep -Eq 'http2_module|mod_http2' && HAS_HTTP2=1 || true
printf '%s\n' "$MODULES" | grep -Eq 'md_module|mod_md' && HAS_MD=1 || true

# Package metadata for backport warning
if command -v rpm >/dev/null 2>&1; then
  PKGVER="$(rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}\n' httpd 2>/dev/null | head -n1)"
elif command -v dpkg-query >/dev/null 2>&1; then
  PKGVER="$(dpkg-query -W -f='${Package} ${Version}\n' apache2 2>/dev/null | head -n1)"
fi

# Distro backport guardrail: old package versions on enterprise distros are often patched.
# If package metadata suggests a distro build older than upstream 2.4.34, do not claim VULNERABLE solely from version.
if [ -n "$PKGVER" ] && printf '%s\n' "$PKGVER" | grep -Eq '(el[0-9]|ubuntu|deb)'; then
  # We can still make a strong call for unaffected versions and for upstream >= 2.4.34
  if version_ge "$UPSTREAM_VER" "2.4.34"; then
    echo "PATCHED - Upstream Apache version $UPSTREAM_VER is >= 2.4.34"
    exit 0
  fi
  if [ "$UPSTREAM_VER" = "2.4.31" ] || [ "$UPSTREAM_VER" = "2.4.32" ]; then
    echo "PATCHED - Versions 2.4.31 and 2.4.32 are below 2.4.34 but not affected by the CVEs in plugin 111788"
    exit 0
  fi
  if version_lt "$UPSTREAM_VER" "2.4.18"; then
    echo "PATCHED - This advisory's mod_http2 issue starts at 2.4.18 and mod_md issue is only 2.4.33"
    exit 0
  fi
  echo "UNKNOWN - Distro package/backport detected ($PKGVER). Need vendor advisory plus module check to confirm actual exposure. Modules: http2=$HAS_HTTP2 mod_md=$HAS_MD upstream=$UPSTREAM_VER"
  exit 2
fi

# Pure upstream logic
if version_ge "$UPSTREAM_VER" "2.4.34"; then
  echo "PATCHED - Apache $UPSTREAM_VER"
  exit 0
fi

if [ "$UPSTREAM_VER" = "2.4.31" ] || [ "$UPSTREAM_VER" = "2.4.32" ]; then
  echo "PATCHED - Apache $UPSTREAM_VER is not affected by CVE-2018-1333 or CVE-2018-8011"
  exit 0
fi

if version_lt "$UPSTREAM_VER" "2.4.18"; then
  echo "PATCHED - Plugin 111788 CVEs do not apply before 2.4.18 (mod_http2 issue) and 2.4.33 (mod_md issue)"
  exit 0
fi

if [ "$UPSTREAM_VER" = "2.4.33" ]; then
  if [ "$HAS_HTTP2" -eq 1 ] || [ "$HAS_MD" -eq 1 ]; then
    echo "VULNERABLE - Apache 2.4.33 with relevant module loaded (http2=$HAS_HTTP2 mod_md=$HAS_MD)"
    exit 1
  else
    echo "PATCHED - Apache 2.4.33 present but neither mod_http2 nor mod_md appears loaded"
    exit 0
  fi
fi

# 2.4.18 - 2.4.30: only the HTTP/2 issue applies
if version_ge "$UPSTREAM_VER" "2.4.18" && version_lt "$UPSTREAM_VER" "2.4.31"; then
  if [ "$HAS_HTTP2" -eq 1 ]; then
    echo "VULNERABLE - Apache $UPSTREAM_VER with mod_http2 loaded"
    exit 1
  else
    echo "PATCHED - Apache $UPSTREAM_VER present but mod_http2 does not appear loaded"
    exit 0
  fi
fi

echo "UNKNOWN - Unhandled combination: upstream=$UPSTREAM_VER http2=$HAS_HTTP2 mod_md=$HAS_MD pkg='$PKGVER'"
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat every 111788 hit as a fleet emergency. First, validate which hosts actually expose mod_http2 or mod_md; suppress the false positives from banner-only detection and unaffected 2.4.31/2.4.32 builds. Because this is a MEDIUM verdict, there is no noisgate mitigation SLA — go straight to the 365-day remediation window for confirmed vulnerable systems, with the actual patch or supported distro backport applied within the noisgate remediation SLA of ≤365 days; if you need immediate risk reduction on exposed edge nodes, disable HTTP/2 or unload unused mod_md during normal change control rather than launching a fleet-wide fire drill.

Sources

  1. Tenable plugin 111788
  2. Apache HTTP Server 2.4 vulnerability page
  3. Apache mod_http2 documentation
  4. Apache mod_md documentation
  5. Ubuntu CVE-2018-1333 advisory
  6. SUSE CVE-2018-8011 advisory
  7. CISA Known Exploited Vulnerabilities catalog
  8. Tenable CVE-2018-1333 record
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.