← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:158900 · Disclosed 2022-03-14

Apache 2

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

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.

"Real issue, inflated scanner finding: one broadly relevant smuggling bug, three niche bugs, plus lots of backport false positives."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach a vulnerable Apache front end

The attacker targets an internet-facing Apache 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Nessus coverage is broad but shallow here: it detects version, not exploitability. External scanners and EASM platforms will find exposure; only config-aware checks or changelog/package validation separate vulnerable from backported.
STEP 02

Weaponize CVE-2022-22720 with a malformed body

The realistic path is 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Dynamic detection is better than static versioning. Burp-style request-smuggling testing can validate exposure; network sensors may log malformed Transfer-Encoding/body handling anomalies, but many orgs lack precise detections.
STEP 03

Turn desync into security impact

Once the socket state is desynchronized, the attacker tries to smuggle a second request that the downstream stack interprets differently. Typical outcomes are cache poisoning, auth boundary bypass, internal path reachability, or request confusion against another user's transaction rather than direct single-shot RCE.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Look for anomalous 400/408 bursts, backend request/response mismatches, impossible cache behavior, and frontend/backend log disagreement on request counts.
STEP 04

Alternative branch: hit optional modules

If 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.
Conditions required:
  • mod_sed loaded for CVE-2022-23943, or mod_lua plus r:parsebody() usage for CVE-2022-22719, or 32-bit plus oversized XML body limits for CVE-2022-22721
Where this breaks in practice:
  • mod_sed and mod_lua are optional and comparatively uncommon in enterprise web fleets
  • The CVE-2022-22721 path 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
Detection/coverage: Local config review is the key control: apachectl -M, package/module inventory, and grepping configs for Lua*, SEDExtension, and LimitXMLRequestBody expose whether the high-CVSS branches are even reachable.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 availabilityExploit 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.
EPSSCVE-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 statusNot 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 checkNVD 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 versionsUpstream 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 backportsUpstream 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 dataCurrent 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 timelineApache 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.
ResearchersCVE-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.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.4/10)

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.

HIGH Optional-module and non-default-config friction materially reduce real-world exploitability
HIGH Version-only scanner logic creates backport false positives on distro-managed hosts
MEDIUM Actual business impact of `CVE-2022-22720` depends on proxy/cache/backend topology

Why this verdict

  • Downward adjustment for prerequisite sprawl: CVE-2022-23943 needs mod_sed, CVE-2022-22719 needs mod_lua plus r:parsebody() usage, and CVE-2022-22721 needs 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-22720 is 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. Disable mod_sed and mod_lua if unused — Removing optional modules collapses three-fourths of this advisory's scary surface area, especially CVE-2022-23943 and CVE-2022-22719. Inventory and remove them within 30 days on internet-facing hosts first.
  3. Keep ProxyRequests Off unless 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.
  4. 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.
  5. Review body-size limits on legacy 32-bit systems — If you still have 32-bit Apache anywhere, verify LimitXMLRequestBody is not set above roughly 350MB and is not effectively unlimited. This is niche but fast to audit, and it should be done within 30 days.
What doesn't work
  • Hiding the Server header does not mitigate request smuggling, module memory corruption, or distro backport confusion.
  • EDR on the host is weak compensation for CVE-2022-22720 because 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.53 is the wrong move on distro-managed systems; older package numbers can still be patched via backport.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning: split this finding into three buckets. First, identify internet-facing Apache nodes that are truly unpatched and either self-built or not covered by distro backports; those get handled first. Second, close out false positives by validating Ubuntu/Debian/RHEL backports from local package metadata. Third, on the remaining exposed hosts, remove 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

  1. Tenable Nessus Plugin 158900
  2. Apache HTTP Server 2.4 vulnerabilities
  3. NVD CVE-2022-22720
  4. NVD CVE-2022-22721
  5. NVD CVE-2022-23943
  6. Ubuntu CVE-2022-23943
  7. Debian security tracker CVE-2022-23943
  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.