This finding is a four-car pileup where only one wreck is usually in your lane
Tenable plugin 158900 fires on Apache HTTP Server versions earlier than 2.4.53 and bundles four flaws fixed on 2022-03-14: CVE-2022-22720 request smuggling in core request handling; CVE-2022-23943 out-of-bounds write in mod_sed; CVE-2022-22719 memory-read/DoS in mod_lua r:parsebody(); and CVE-2022-22721, an integer-overflow-to-OOB-write case that only matters on 32-bit builds when LimitXMLRequestBody is raised above ~350 MB or left effectively unlimited. Affected upstream versions are 2.4.52 and earlier for all four issues, but three of them require optional modules or non-default config.
Tenable's worst-case 9.8 scoring is technically defensible for the most dangerous individual CVEs, but it overstates fleet risk for a patching team. In real enterprise deployments, mod_sed is uncommon, mod_lua is rarer still, and the 32-bit giant-XML prerequisite is edge-case territory; the only broadly relevant issue is CVE-2022-22720, which is serious because it is unauthenticated and remote, but still needs the classic request-smuggling conditions to translate into meaningful impact. Add in the fact that this plugin is version-only and will over-flag distro backports, and this lands as HIGH, not CRITICAL.
4 steps from start to impact.
Reach a vulnerable Apache front end
2.4.52 or older host identified by banner grab, package inventory, or external scan data. The practical offensive tooling here is basic recon plus a request-smuggling client such as Burp Suite with the HTTP Request Smuggler workflow or custom netcat/curl payloads.- Apache HTTP Server is exposed to the attacker
- The host is actually unpatched, not just reporting an old distro version
- The service accepts persistent HTTP connections
- Tenable explicitly says this plugin relies on self-reported version and does not test exploitability
- RHEL/Ubuntu/Debian backports can leave an older-looking version string while the CVEs are already fixed
- WAF/CDN/load balancer layers may normalize or terminate malformed requests before Apache sees them
Weaponize CVE-2022-22720 with a malformed body
CVE-2022-22720: Apache can fail to close the inbound connection when an error occurs while discarding a request body. That gives an attacker a request-smuggling primitive to desynchronize how requests are interpreted across the chain.- Apache is running a vulnerable build affected by
CVE-2022-22720 - The attacker can send crafted HTTP requests directly or through a front-end proxy
- Connection reuse/pipelining behavior allows the desync to matter
- Request smuggling is not point-and-shoot; it often requires per-target tuning
- Impact depends on having another component or user request to poison, queue-jump, or confuse
- Modern reverse proxies, CDNs, and WAFs frequently break malformed smuggling attempts
Transfer-Encoding/body handling anomalies, but many orgs lack precise detections.Turn desync into security impact
- A proxy/cache/backend chain exists where interpretation diverges
- There is a valuable downstream target such as an authenticated path, cacheable response, or trusted backend route
- Many enterprises do not run Apache in the exact proxy topology that makes smuggling pay off
- Even when desync is present, exploitability may stop at weird responses or limited poisoning rather than code execution
- EDR will not help much here, but load balancer hardening and HTTP normalization often will
Alternative branch: hit optional modules
mod_sed is loaded, CVE-2022-23943 offers memory corruption potential; if mod_lua is in use and application Lua code calls r:parsebody(), CVE-2022-22719 can crash a process; if the server is 32-bit with oversized LimitXMLRequestBody, CVE-2022-22721 becomes relevant. These are the scary CVSS drivers, but they are not the default path on most fleets.mod_sedloaded forCVE-2022-23943, ormod_luaplusr:parsebody()usage forCVE-2022-22719, or 32-bit plus oversized XML body limits forCVE-2022-22721
mod_sedandmod_luaare optional and comparatively uncommon in enterprise web fleets- The
CVE-2022-22721path effectively disappears on standard 64-bit builds and default body limits - Public exploit evidence is much thinner for these branches than the raw CVSS suggests
apachectl -M, package/module inventory, and grepping configs for Lua*, SEDExtension, and LimitXMLRequestBody expose whether the high-CVSS branches are even reachable.The supporting signals.
| In-the-wild status | No current evidence of KEV-level active exploitation for the four 2.4.53-fixed CVEs. As of 2026-06-01, no matching entry was found in the CISA KEV catalog; that is an inference from current catalog/search results, not a vendor statement. |
|---|---|
| Proof-of-concept availability | Exploit research exists for the smuggling path: Tenable marks the plugin Exploit Available: true, and CVE-2022-22720 was reported by James Kettle of PortSwigger, which usually means real offensive methodology is available even if not packaged as one-click RCE. For CVE-2022-23943, public exploit evidence is much weaker. |
| EPSS | CVE-2022-22720: 27.46%, 97th percentile via Bitsight. CVE-2022-23943: 68.55%, 99th percentile via Bitsight. Those numbers show attacker interest, but not that your specific module/config path is reachable. |
| KEV status | Not listed in CISA KEV for CVE-2022-22719, CVE-2022-22720, CVE-2022-22721, or CVE-2022-23943 as checked on 2026-06-01. |
| CVSS reality check | NVD scores CVE-2022-22720 and CVE-2022-23943 at 9.8 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and CVE-2022-22721 at 9.1. That is a worst-case technical impact model, not a statement that all pre-2.4.53 hosts are one-request RCEs. |
| Affected versions | Upstream Apache HTTP Server 2.4.52 and earlier. CVE-2022-23943 affects 2.4.0 through 2.4.52; CVE-2022-22719, -22720, and -22721 also affect 2.4.52 and earlier per Apache/NVD. |
| Fixed versions and backports | Upstream fixed in 2.4.53 on 2022-03-14. Distro backports matter: Ubuntu lists fixes in older package lines such as Jammy 2.4.52-1ubuntu2, Focal 2.4.41-4ubuntu3.10, and Debian fixed older branches such as Buster 2.4.38-3+deb10u8 and Stretch 2.4.25-3+deb9u13. |
| Exposure data | Current EASM data still shows a very large exposed population. Bitsight reports 1,507,961 total observations for Apache HTTP Server 2.4.52 and 4,740,333 observations tied to CVE-2022-22720 over the prior 30 days, with the US the top observed country. |
| Disclosure timeline | Apache released 2.4.53 and published these fixes on 2022-03-14. Tenable published plugin 158900 the same day and later updated exploit metadata on 2023-11-06. |
| Researchers | CVE-2022-22720 was reported by James Kettle; CVE-2022-23943 by Ronald Crane; CVE-2022-22719 by Chamal De Silva; CVE-2022-22721 by an anonymous researcher working with Trend Micro ZDI. |
noisgate verdict.
The single biggest driver here is that three of the four CVEs require uncommon modules or edge-case configuration, so the plugin's 9.8 worst-case framing does not reflect most enterprise Apache fleets. This stays HIGH because CVE-2022-22720 is still an unauthenticated remote bug on a massively exposed product, and request smuggling can bypass meaningful security boundaries when the topology is right.
Why this verdict
- Downward adjustment for prerequisite sprawl:
CVE-2022-23943needsmod_sed,CVE-2022-22719needsmod_luaplusr:parsebody()usage, andCVE-2022-22721needs 32-bit plus oversized XML body settings. Those are compounding reachability filters, not broad default conditions. - Kept HIGH because one path is truly remote:
CVE-2022-22720is unauthenticated, network-reachable, and applies to ordinary Apache request handling. On public reverse proxies or edge nodes, request smuggling is a real attacker primitive. - Downward adjustment for post-condition dependence: request smuggling usually needs a cooperative chain to turn parser desync into cache poisoning, auth confusion, or backend reachability. That is materially less reliable than a straight unauthenticated RCE against a single host.
- Downward adjustment for detection quality: Tenable states it did not test the issue and relied on self-reported version only. That means older-looking but backported Ubuntu/Debian/RHEL packages will inflate the apparent blast radius.
- Not downgraded to MEDIUM because exposure is huge: Apache remains everywhere, and Bitsight still sees millions of observations tied to the vulnerable line/CVEs. Even a non-KEV smuggling flaw on a ubiquitous edge service deserves active patching attention.
Why not higher?
This is not a clean fleet-wide CRITICAL because the scary scores are being carried by branches that many hosts cannot reach at all. There is also no KEV listing or strong public evidence of widespread active exploitation for this specific 2.4.53 bundle as of 2026-06-01, and the most realistic bug is request smuggling rather than default-path RCE.
Why not lower?
It is still an internet-service finding on one of the most exposed server products in enterprise, and CVE-2022-22720 is unauthenticated remote. If you run Apache as a reverse proxy, cache, or front door, parser desync bugs can produce outsized downstream impact even when the base server itself is not trivially owned.
What to do — in priority order.
- Validate backports before you panic-patch — Check package changelogs and vendor advisories first, especially on Ubuntu, Debian, and RHEL-derived systems. Do this within the HIGH noisgate mitigation SLA of 30 days so you stop burning cycles on version-string false positives and focus on truly unpatched hosts.
- Disable
mod_sedandmod_luaif unused — Removing optional modules collapses three-fourths of this advisory's scary surface area, especiallyCVE-2022-23943andCVE-2022-22719. Inventory and remove them within 30 days on internet-facing hosts first. - Keep
ProxyRequests Offunless you explicitly need forward proxying — Forward-proxy behavior and complex proxy chains make request-smuggling outcomes far worse. Confirm the setting and tighten proxy use cases within 30 days on any Apache edge node. - Normalize HTTP at the edge — Enforce strict request parsing and malformed-request rejection on the CDN, load balancer, reverse proxy, or WAF sitting in front of Apache. That reduces the practical reach of
CVE-2022-22720; deploy or validate these controls within 30 days. - Review body-size limits on legacy 32-bit systems — If you still have 32-bit Apache anywhere, verify
LimitXMLRequestBodyis not set above roughly350MBand is not effectively unlimited. This is niche but fast to audit, and it should be done within 30 days.
- Hiding the
Serverheader does not mitigate request smuggling, module memory corruption, or distro backport confusion. - EDR on the host is weak compensation for
CVE-2022-22720because the initial abuse is often HTTP parser desync, cache poisoning, or proxy boundary confusion rather than obvious malware execution. - Closing the ticket because the package version is older than
2.4.53is the wrong move on distro-managed systems; older package numbers can still be patched via backport.
Crowdsourced verification payload.
Run this on the target Apache host as root or with sudo, because it inspects local package metadata and Apache config helpers. Save it as verify_apache_2453.sh and run sudo bash verify_apache_2453.sh; it prints exactly one of VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env bash
# verify_apache_2453.sh
# Checks whether local Apache HTTP Server is patched for the 2.4.53 bundle
# (CVE-2022-22719, CVE-2022-22720, CVE-2022-22721, CVE-2022-23943).
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
need_cves=("CVE-2022-22719" "CVE-2022-22720" "CVE-2022-22721" "CVE-2022-23943")
print_result() {
local status="$1"
case "$status" in
PATCHED) echo "PATCHED"; exit 0 ;;
VULNERABLE) echo "VULNERABLE"; exit 1 ;;
*) echo "UNKNOWN"; exit 2 ;;
esac
}
have_cmd() { command -v "$1" >/dev/null 2>&1; }
version_ge() {
# returns 0 if $1 >= $2
[ "$(printf '%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}
extract_ver() {
echo "$1" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1
}
APACHE_CTL=""
for c in apache2ctl apachectl httpd apache2; do
if have_cmd "$c"; then
APACHE_CTL="$c"
break
fi
done
[ -n "$APACHE_CTL" ] || print_result UNKNOWN
raw_ver="$($APACHE_CTL -v 2>/dev/null || true)"
ver="$(extract_ver "$raw_ver")"
# Fast path: upstream/newer version.
if [ -n "$ver" ] && version_ge "$ver" "2.4.53"; then
print_result PATCHED
fi
# Backport checks for Debian/Ubuntu.
if have_cmd dpkg-query; then
if dpkg-query -W -f='${Status}' apache2 2>/dev/null | grep -q 'install ok installed'; then
chlog="/usr/share/doc/apache2/changelog.Debian.gz"
if [ -r "$chlog" ]; then
hits=0
for cve in "${need_cves[@]}"; do
if zgrep -qi "$cve" "$chlog"; then
hits=$((hits+1))
fi
done
if [ "$hits" -eq 4 ]; then
print_result PATCHED
fi
fi
fi
fi
# Backport checks for RPM families.
if have_cmd rpm; then
for pkg in httpd apache2; do
if rpm -q "$pkg" >/dev/null 2>&1; then
hits=0
for cve in "${need_cves[@]}"; do
if rpm -q --changelog "$pkg" 2>/dev/null | grep -qi "$cve"; then
hits=$((hits+1))
fi
done
if [ "$hits" -eq 4 ]; then
print_result PATCHED
fi
fi
done
fi
# If we can confidently see an old upstream version and no backport proof, call it vulnerable.
if [ -n "$ver" ] && ! version_ge "$ver" "2.4.53"; then
print_result VULNERABLE
fi
print_result UNKNOWN
If you remember one thing.
mod_sed/mod_lua where unused and patch to a fixed build. For this HIGH verdict, the noisgate mitigation SLA is within 30 days for compensating controls like module removal, proxy hardening, and backport validation; the noisgate remediation SLA is within 180 days for the actual vendor package upgrade, though any public-facing reverse proxies should be moved much faster than that in practice.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.