This is three different locks on three different side doors, not one front-door skeleton key
Tenable plugin 170113 rolls up three flaws fixed in Apache HTTP Server 2.4.55 on January 17, 2023: CVE-2022-36760 in mod_proxy_ajp (request smuggling, affects 2.4.54 and earlier), CVE-2022-37436 in mod_proxy (response/header splitting triggered by a *malicious backend*, affects versions before 2.4.55), and CVE-2006-20001 in mod_dav (crafted If: header can crash the process, affects 2.4.54 and earlier). The plugin is version-only, so it fires on any host reporting Apache <2.4.55 whether or not mod_proxy_ajp, mod_proxy, or mod_dav are actually exposed in a reachable path.
The vendor labeling overshoots reality for most enterprises. The only pre-auth internet-relevant issue in the bundle is the AJP request-smuggling bug, and even that requires a fairly specific reverse-proxy design that many shops trimmed back after Ghostcat; the second issue assumes an already-malicious backend, and the third is mostly a crash bug gated by WebDAV usage. That makes critical a bad fleet-wide default and medium the right planning bucket unless you knowingly run internet-facing Apache reverse proxies to AJP backends.
4 steps from start to impact.
Find an Apache edge that actually uses mod_proxy_ajp
nmap, httpx, or internet census data plus application behavior to identify Apache front ends and infer an AJP-backed reverse-proxy path. The bug that matters most here, CVE-2022-36760, is not a generic 'Apache old version' exploit; it needs Apache to parse the inbound request and forward it through mod_proxy_ajp to an AJP backend.- Target is externally reachable over HTTP/S
- Apache is acting as a reverse proxy
mod_proxy_ajpis enabled and in use for at least one route
- AJP-backed Apache reverse proxies are a minority pattern in modern estates
- Many orgs restricted or removed AJP exposure and usage after
CVE-2020-1938/ Ghostcat - Version-only scanners cannot confirm this prerequisite
Probe for desync behavior with request-smuggling tooling
Smuggler or Burp's HTTP Request Smuggler techniques to craft ambiguous requests that Apache and the downstream AJP service interpret differently. The goal is to get Apache to forward a smuggled request segment into the backend stream while the frontend still treats the connection as clean.- Frontend request parsing and AJP forwarding remain in the vulnerable code path
- Connection reuse or backend request handling allows a useful desync outcome
- Request smuggling often breaks on real-world edge stacks because of CDNs, WAFs, load balancers, or normalizers upstream
- Reliable exploitation usually takes target-specific tuning rather than one-shot commodity exploitation
Content-Length / transfer anomalies, but many detections are noisy and not specific to this CVE.Land a backend-visible smuggled request
- Backend application trusts the frontend too much
- There is a sensitive route where a smuggled request changes auth, cache, or session handling
- Impact depends heavily on app behavior, not just Apache itself
- Many backends are internal-only apps with limited blast radius per vhost or tenant
Alternative paths are weaker than the headline suggests
CVE-2022-37436 needs a *malicious or compromised backend* to feed Apache crafted headers, so it is usually post-compromise hardening debt, not an initial access bug. CVE-2006-20001 needs mod_dav exposure and primarily threatens availability via a process crash rather than clean remote code execution.- For
CVE-2022-37436: attacker controls or compromises the proxied backend - For
CVE-2006-20001:mod_davis enabled and reachable
- Both paths require niche module usage or prior compromise
- Neither is a broad unauthenticated RCE against every Apache host below
2.4.55
The supporting signals.
| In-the-wild status | No evidence found that any of CVE-2022-36760, CVE-2022-37436, or CVE-2006-20001 are in CISA KEV; Tenable also states no known exploits are available for plugin 170113. |
|---|---|
| KEV status | Not KEV-listed as of review; no active-exploitation amplifier from CISA here. |
| PoC / weaponization | No authoritative public exploit repo stood out for this bundle. The practical weaponization path is generic HTTP desync tooling such as Smuggler / Burp request-smuggling methods against CVE-2022-36760, but exploitation still requires the right AJP proxy topology. |
| EPSS | Public EPSS mirrors keep this set in the low-to-mid likelihood range rather than breakout territory: CVE-2022-36760 about 0.145% / 35.6th percentile, CVE-2022-37436 about 0.50% / 65.5th percentile, and CVE-2006-20001 about 0.47% / 65th percentile. |
| Dominant CVSS vector | The bundle inherits the harshest score from CVE-2022-36760: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H (9.0 / Critical). That vector assumes the vulnerable AJP reverse-proxy pattern is actually present. |
| Affected versions | CVE-2022-36760: Apache HTTP Server 2.4.54 and earlier with mod_proxy_ajp; CVE-2022-37436: versions before 2.4.55 in mod_proxy with a malicious backend; CVE-2006-20001: 2.4.54 and earlier where mod_dav is in play. |
| Fixed versions | Upstream fix is 2.4.55. Distro backports matter: Ubuntu fixed CVE-2022-37436 in packages such as 2.4.52-1ubuntu4.3 for Jammy and 2.4.41-4ubuntu3.13 for Focal; Debian 11 fixed related Apache issues in 2.4.56-1~deb11u1 even though the source package version string does not equal upstream 2.4.55. |
| Scanning / exposure reality | External census can find Apache broadly, but it cannot reliably tell you whether mod_proxy_ajp or mod_dav is actually enabled on a vulnerable route. The highest-risk path is therefore much narrower than the plugin footprint. |
| Disclosure timeline | Apache released 2.4.55 on 2023-01-17. Apache's vulnerability page records reports on 2022-07-12 (CVE-2022-36760), 2022-07-14 (CVE-2022-37436), and 2022-08-10 (CVE-2006-20001). |
| Reporting researchers | CVE-2022-36760: ZeddYu_Lu of Qi'anxin Research Institute of Legendsec; CVE-2022-37436: Dimas Fariski Setyawan Putra (@nyxsorcerer); CVE-2006-20001: issue described historically in *The Art of Software Security Assessment* and later tracked/fixed by Apache. |
noisgate verdict.
The decisive downgrade is attacker reachability: the serious path requires an internet-facing Apache reverse proxy that still uses mod_proxy_ajp, which sharply narrows the exposed population. The other two CVEs are even less urgent in practice because one assumes a malicious backend and the other is mainly a WebDAV-gated crash bug.
Why this verdict
- Downward pressure: requires specific edge topology —
CVE-2022-36760only matters if Apache is both internet-reachable and actively proxying to AJP; that is a much smaller set than 'all Apache below 2.4.55'. - Downward pressure: one flaw is post-compromise by design —
CVE-2022-37436needs a malicious or already-compromised backend, which implies the attacker is already deep in the chain. - Downward pressure: one flaw is mostly availability-only —
CVE-2006-20001is tied tomod_davand primarily crashes the process rather than handing over clean code execution. - Downward pressure: no strong exploitation evidence — no KEV listing and no strong authoritative sign of widespread in-the-wild exploitation for this bundle.
- Not lower because edge proxies matter — if you do run exposed Apache-to-AJP reverse proxies, request smuggling on a trust boundary can produce meaningful security outcomes even without RCE.
Why not higher?
I am not keeping this at HIGH or CRITICAL because the plugin score is dominated by a request-smuggling CVE that assumes a specific, less-common deployment pattern. In real estates, each extra prerequisite compounds: internet exposure, Apache reverse proxy role, mod_proxy_ajp usage, and a backend path where desync has useful impact.
Why not lower?
I am not dropping this to LOW because Apache still sits on security boundaries, and request smuggling on boundary systems can punch above its weight when the topology matches. Also, large environments often have a few forgotten legacy reverse proxies where AJP or WebDAV stayed enabled longer than expected.
What to do — in priority order.
- Inventory
mod_proxy_ajpandmod_dav— Find the small subset of hosts where this bundle is *actually* reachable by checking loaded modules and vhost configs. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but do the inventory in the next normal review cycle so you can separate true exposure from scanner noise. - Retire AJP where possible — If you still proxy to Tomcat or similar backends over AJP, move to HTTP/S or strictly constrain that path to trusted internal links. There is no mitigation SLA for a MEDIUM verdict, but removing AJP is the single highest-value hardening move before the
365-dayremediation deadline. - Disable unused WebDAV — Turn off
mod_davand DAV-enabled locations unless there is a documented business need. This strips out theCVE-2006-20001path and should be handled during normal configuration hygiene before the remediation window closes. - Normalize and inspect edge traffic — Enforce strict request normalization on upstream load balancers/WAFs and alert on malformed or desync-style requests hitting Apache reverse proxies. This does not replace patching, but it raises attacker cost while you work through the MEDIUM bucket.
- A generic version-only vulnerability exception does not prove safety, because some hosts are genuinely exposed through
mod_proxy_ajpormod_daveven if most are not. - Relying on a WAF alone is weak protection against request smuggling; parsing disagreements often happen *between* layers, which is the whole problem.
- Simply hiding the backend AJP port from the internet does not solve
CVE-2022-36760if the vulnerable Apache frontend is already reachable and forwarding to it.
Crowdsourced verification payload.
Run this on the target Linux host as a local auditor or through your config-management/EDR shell. Invoke it with sudo bash ./check_apache_2455_bundle.sh; root is recommended so the script can read package metadata, loaded modules, and Apache config paths. It prints VULNERABLE, PATCHED, or UNKNOWN and exits 1, 0, or 2 respectively.
#!/usr/bin/env bash
# check_apache_2455_bundle.sh
# Detect likely exposure to Tenable plugin 170113 / Apache httpd < 2.4.55 bundle
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
out() {
echo "$1"
exit "$2"
}
have() {
command -v "$1" >/dev/null 2>&1
}
get_httpd_version() {
local bin
for bin in apache2 httpd /usr/sbin/apache2 /usr/sbin/httpd /usr/local/apache2/bin/httpd; do
if [ -x "$bin" ]; then
"$bin" -v 2>/dev/null | awk -F/ '/Server version/ {print $2}' | awk '{print $1}'
return 0
fi
done
return 1
}
ver_ge() {
# semantic-ish compare for upstream Apache versions
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}
check_modules_and_configs() {
local mods=""
local cfgs=""
local bin
for bin in apache2 httpd /usr/sbin/apache2 /usr/sbin/httpd /usr/local/apache2/bin/httpd; do
if [ -x "$bin" ]; then
mods="$($bin -M 2>/dev/null || true)"
cfgs="$($bin -t -D DUMP_VHOSTS 2>/dev/null || true)"
break
fi
done
echo "$mods" | grep -qi 'proxy_ajp_module' && AJP_LOADED=1 || AJP_LOADED=0
echo "$mods" | grep -qi 'dav_module' && DAV_LOADED=1 || DAV_LOADED=0
echo "$mods" | grep -qi 'proxy_module' && PROXY_LOADED=1 || PROXY_LOADED=0
}
check_debian_ubuntu() {
local pkgver osid codename fixed reason
pkgver="$(dpkg-query -W -f='${Version}' apache2 2>/dev/null || true)"
[ -n "$pkgver" ] || return 1
osid=""
codename=""
if [ -r /etc/os-release ]; then
. /etc/os-release
osid="${ID:-}"
codename="${VERSION_CODENAME:-}"
fi
if [ "$osid" = "ubuntu" ]; then
case "$codename" in
jammy) fixed='2.4.52-1ubuntu4.3' ;;
focal) fixed='2.4.41-4ubuntu3.13' ;;
bionic) fixed='2.4.29-1ubuntu4.26' ;;
kinetic) fixed='2.4.54-2ubuntu1.1' ;;
noble|oracular|plucky|questing|resolute) fixed='2.4.55-1ubuntu1' ;;
*) fixed='' ;;
esac
if [ -n "$fixed" ]; then
if dpkg --compare-versions "$pkgver" ge "$fixed"; then
out "PATCHED" 0
else
check_modules_and_configs
reason="package apache2=$pkgver is below Ubuntu fixed level $fixed"
echo "$reason" >&2
out "VULNERABLE" 1
fi
fi
fi
if [ "$osid" = "debian" ]; then
case "${VERSION_ID:-}" in
11) fixed='2.4.56-1~deb11u1' ;;
12|13|14) fixed='2.4.55-1' ;;
*) fixed='' ;;
esac
if [ -n "$fixed" ]; then
if dpkg --compare-versions "$pkgver" ge "$fixed"; then
out "PATCHED" 0
else
check_modules_and_configs
reason="package apache2=$pkgver is below Debian fixed level $fixed"
echo "$reason" >&2
out "VULNERABLE" 1
fi
fi
fi
return 1
}
check_rpm_family() {
local pkgver changelog upstream
if ! have rpm; then
return 1
fi
pkgver="$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' httpd 2>/dev/null || true)"
[ -n "$pkgver" ] || return 1
changelog="$(rpm -q --changelog httpd 2>/dev/null || true)"
if echo "$changelog" | grep -q 'CVE-2022-36760' && \
echo "$changelog" | grep -q 'CVE-2022-37436' && \
echo "$changelog" | grep -q 'CVE-2006-20001'; then
out "PATCHED" 0
fi
upstream="$(get_httpd_version || true)"
if [ -n "$upstream" ] && ver_ge "$upstream" '2.4.55'; then
out "PATCHED" 0
fi
echo "RPM package detected but no reliable backport evidence found in changelog; manual advisory check required" >&2
out "UNKNOWN" 2
}
main() {
local upstream
check_debian_ubuntu || true
check_rpm_family || true
upstream="$(get_httpd_version || true)"
if [ -z "$upstream" ]; then
echo "Apache binary not found or version unreadable" >&2
out "UNKNOWN" 2
fi
check_modules_and_configs
if ver_ge "$upstream" '2.4.55'; then
out "PATCHED" 0
fi
# For source-built or non-packaged Apache, upstream version is the best evidence available.
echo "Apache reports upstream version $upstream (< 2.4.55)" >&2
echo "Loaded modules: proxy=$PROXY_LOADED proxy_ajp=$AJP_LOADED dav=$DAV_LOADED" >&2
out "VULNERABLE" 1
}
main "$@"
If you remember one thing.
mod_proxy_ajp, hosts exposing mod_dav, and everyone else. Because this is a MEDIUM reassessment there is no noisgate mitigation SLA — go straight to the 365-day remediation window for the general fleet; use the noisgate remediation SLA to get the actual 2.4.55-equivalent vendor fixes or distro backports applied within 365 days, while pulling any AJP-backed edge proxies forward into your next normal patch cycle because they are the only subset with meaningful pre-auth edge risk.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.