← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:170113 · Disclosed 2023-01-17

Apache 2

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

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.

"This is scanner-loud but fleet-level medium: the dangerous path needs niche Apache configs, not just an old version."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find an Apache edge that actually uses mod_proxy_ajp

The attacker starts with standard recon using 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.
Conditions required:
  • Target is externally reachable over HTTP/S
  • Apache is acting as a reverse proxy
  • mod_proxy_ajp is enabled and in use for at least one route
Where this breaks in practice:
  • 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
Detection/coverage: Nessus/Tenable detects by version only here; config-aware coverage is weaker unless you inspect loaded modules and proxy mappings.
STEP 02

Probe for desync behavior with request-smuggling tooling

An attacker then uses 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.
Conditions required:
  • Frontend request parsing and AJP forwarding remain in the vulnerable code path
  • Connection reuse or backend request handling allows a useful desync outcome
Where this breaks in practice:
  • 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
Detection/coverage: WAFs and reverse-proxy logs may show malformed Content-Length / transfer anomalies, but many detections are noisy and not specific to this CVE.
STEP 03

Land a backend-visible smuggled request

If the desync works, the attacker can push a hidden request to the AJP-served application behind Apache. That can create auth bypass edge cases, cache poisoning, or unintended request routing depending on the backend app and how trust headers, sessions, and paths are handled.
Conditions required:
  • Backend application trusts the frontend too much
  • There is a sensitive route where a smuggled request changes auth, cache, or session handling
Where this breaks in practice:
  • Impact depends heavily on app behavior, not just Apache itself
  • Many backends are internal-only apps with limited blast radius per vhost or tenant
Detection/coverage: Look for mismatched frontend/backend logs, duplicate request IDs, unexpected internal paths, or cache anomalies.
STEP 04

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.
Conditions required:
  • For CVE-2022-37436: attacker controls or compromises the proxied backend
  • For CVE-2006-20001: mod_dav is enabled and reachable
Where this breaks in practice:
  • Both paths require niche module usage or prior compromise
  • Neither is a broad unauthenticated RCE against every Apache host below 2.4.55
Detection/coverage: Config review is more valuable than generic scanning for these two paths.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 statusNot KEV-listed as of review; no active-exploitation amplifier from CISA here.
PoC / weaponizationNo 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.
EPSSPublic 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 vectorThe 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 versionsCVE-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 versionsUpstream 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 realityExternal 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 timelineApache 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 researchersCVE-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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.8/10)

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.

HIGH Downgrade from Tenable's plugin-level `Critical` severity
MEDIUM Exact prevalence of vulnerable `mod_proxy_ajp` deployments in your estate

Why this verdict

  • Downward pressure: requires specific edge topologyCVE-2022-36760 only 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 designCVE-2022-37436 needs a malicious or already-compromised backend, which implies the attacker is already deep in the chain.
  • Downward pressure: one flaw is mostly availability-onlyCVE-2006-20001 is tied to mod_dav and 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.

05 · Compensating Control

What to do — in priority order.

  1. Inventory mod_proxy_ajp and mod_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.
  2. 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-day remediation deadline.
  3. Disable unused WebDAV — Turn off mod_dav and DAV-enabled locations unless there is a documented business need. This strips out the CVE-2006-20001 path and should be handled during normal configuration hygiene before the remediation window closes.
  4. 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.
What doesn't work
  • A generic version-only vulnerability exception does not prove safety, because some hosts are genuinely exposed through mod_proxy_ajp or mod_dav even 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-36760 if the vulnerable Apache frontend is already reachable and forwarding to it.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning, do not let this plugin sit in the same queue as true unauthenticated Apache RCEs. Use config inventory to split the fleet into three buckets: internet-facing Apache nodes that still use 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

  1. Tenable Nessus Plugin 170113
  2. Apache HTTP Server 2.4 vulnerability history
  3. OSV record for CVE-2022-36760
  4. OSV record for CVE-2022-37436
  5. OSV record for CVE-2006-20001
  6. Ubuntu advisory for CVE-2022-37436
  7. Debian OSV/backport record for CVE-2006-20001
  8. CISA Known Exploited Vulnerabilities Catalog
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.