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.
4 steps from start to impact.
Find a direct Apache origin with the right module loaded
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.- Internet or internal network reachability to the Apache origin
- Affected upstream version or an unpatched backport
mod_http2loaded forCVE-2018-1333ormod_mdloaded forCVE-2018-8011
- Tenable flags by self-reported version, so many hits are not actually vulnerable
mod_mdpopulation is tiny because it is experimental- Some distro builds did not even enable HTTP/2 in affected releases
111788 is version-based only; configuration-aware validation is required.Negotiate the vulnerable protocol or endpoint
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.- HTTP/2 actually enabled and reachable for
CVE-2018-1333 - Relevant
mod_mdchallenge handling reachable forCVE-2018-8011
- 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
HTTP/2.0 negotiation and repeated malformed requests; reverse proxies may see this first.Send crafted frames or requests to burn workers or crash a child
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.- Sustained ability to send crafted requests
- No upstream control blocking abusive connection patterns
- 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
server-status, worker saturation, AH crash messages, child restarts, and origin 5xx bursts.Cause localized availability impact, not takeover
- Target service is business-relevant enough that degraded availability matters
- No confidentiality or integrity impact
- HA pairs, autoscaling, and reverse proxies reduce business impact
- Attacker gets disruption, not foothold
The supporting signals.
| In-the-wild status | No 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 availability | No 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. |
| EPSS | CVE-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 status | Not listed in the CISA KEV catalog as of the catalog results currently available. |
| CVSS vector | CVSS: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 versions | CVE-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 versions | Upstream 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 reality | Apache 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 timeline | Apache 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 / reporting | CVE-2018-1333 was credited to Craig Young of Tripwire VERT. CVE-2018-8011 was credited to Daniel Caminada. |
noisgate verdict.
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.
Why this verdict
- Downgrade for feature gating:
CVE-2018-1333only exists if HTTP/2 is actually built, loaded, and reachable;CVE-2018-8011only exists on2.4.33with experimentalmod_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
111788explicitly relies on self-reported version and does not test exploitability, so2.4.31/2.4.32and 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.
What to do — in priority order.
- Disable HTTP/2 where you do not need it — On confirmed vulnerable pre-
2.4.34origins, removingmod_http2or droppingProtocols h2collapses theCVE-2018-1333path entirely. Because this verdict isMEDIUM, there is no mitigation SLA; apply in the normal change cycle, focusing first on public-facing origins. - Unload
mod_mdif unused — If you are not using Apache-managed ACME certificate workflows, remove or disablemod_md; that eliminates theCVE-2018-8011path. This is especially attractive becausemod_mdis an optional, experimental module rather than core web serving functionality. - 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. - 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.
EDRwill not meaningfully stop an HTTP/2 worker-starvation bug; this is a protocol-path availability issue, not malware execution.WAFsignatures 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.32builds make that signal noisy.
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.
#!/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
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.