This is a smoke alarm wired to an empty closet
Plugin 193423 is nominally titled Apache 2.4.x < 2.4.54 Multiple Vulnerabilities, but Tenable’s own plugin metadata ties it to CVE-2022-30522 (apache_2_4_54_cve-2022-30522.nasl). The actual flaw is a denial of service in mod_sed: if Apache HTTP Server 2.4.53 is configured to run mod_sed transformations on very large request or response bodies, the module can make oversized memory allocations and abort. That is much narrower than the plugin title suggests, and upstream Apache documents mod_sed as experimental.
Tenable’s High / 7.5 label is technically defensible in CVSS-land because the bug is network-reachable and availability-impacting, but it badly overstates enterprise reality. You need the exact vulnerable release, the uncommon mod_sed module, and a live InputSed / OutputSed path handling large content. Upstream Apache called this issue low, and for a 10,000-host patch queue that is the right instinct: this finding is mostly version-based noise unless you knowingly use mod_sed.
4 steps from start to impact.
Land on a true 2.4.53 target
CVE-2022-30522. That already excludes many distro-packaged systems because Ubuntu, Debian, and others backported fixes into older-looking package versions, while this Nessus plugin only keys off version lineage.- Apache HTTP Server behavior equivalent to vulnerable
2.4.53 - No distro backport already fixing
CVE-2022-30522 - Attacker can reach the affected HTTP service
- Many enterprise Linux builds are backported and look older than upstream
- The plugin explicitly says it relied on self-reported version, not exploit testing
193423 is version-only. Local package advisory/changelog validation is required to separate true exposure from backport noise.Hit a path that actually uses mod_sed
mod_sed to be loaded and used as an input or output filter. In practice that means specific config like InputSed, OutputSed, AddInputFilter Sed, or AddOutputFilter Sed on a live route.mod_sedis loadedmod_sedis attached to request or response processing for reachable content
- Apache documents
mod_sedas experimental - Most estates never load or use
mod_sedat all - Internet scanners cannot infer this from a banner
apachectl -M plus grep across active config includes.Feed mod_sed very large content
mod_sed attempts excessive memory allocation. Public summaries describe this as large-content processing rather than a neat one-packet crash primitive.- A request/response path exists where
mod_sedprocesses large content - Upstream limits or intermediary body caps do not block the payload
- Reverse proxies, CDNs, app servers, or upload limits often cap body size first
- Not every
mod_seddeployment handles attacker-controlled large data
Cause worker abort and service degradation
- Memory allocation succeeds far enough to destabilize the process
- Operational protections do not absorb the failure
- Impact is availability-only
- Process supervision may restart workers quickly
- Blast radius can stay limited to the affected route or worker pool
AH error bursts, kernel OOM messages, and short-lived 5xx spikes are the practical signals.mod_sed where unused — If mod_sed is not a deliberate business requirement, remove or comment out the module load and reload Apache. For a LOW verdict there is no formal mitigation SLA; do this as backlog hygiene in the next normal maintenance cycle.InputSed / OutputSed from large-body routes — If you must keep mod_sed, keep it off upload paths and any route that can process very large request or response bodies. That eliminates the practical trigger condition without waiting on a major platform refresh; again, for LOW, handle during routine change windows.Banner hidingdoes not help; the problem is module behavior, not whether theServerheader discloses a version.Generic WAF signaturesare weak here because the trigger is size plus config path, not a distinctive exploit string.Treat every<2.4.54host as equally urgentis the wrong control; the plugin title is broader than the true exposure condition.
The supporting signals.
| What this plugin is *really* about | Tenable plugin 193423 is backed by CVE-2022-30522 (apache_2_4_54_cve-2022-30522.nasl), despite the generic multiple vulnerabilities title. |
|---|---|
| In-the-wild status | No active exploitation evidence found in authoritative sources reviewed, and not listed in CISA KEV as of 2026-06-01. |
| Public exploit / PoC status | Tenable marks Exploit Available: true, and public aggregators point to crash-reproducer material, but I found no mature weaponized campaign evidence. Treat this as DoS repro availability, not a turnkey intrusion kit. |
| EPSS | Tenable currently shows EPSS 0.11939. Public feeds around this CVE cluster in the ~11.6% probability / low-to-mid 90s percentile range; that is higher than its practical exploitability suggests, so use it as a *threat-interest signal*, not as proof your fleet is truly exposed. |
| KEV status | Not KEV-listed. That matters: there is no CISA-backed evidence that this niche Apache DoS is a routine attacker favorite. |
| CVSS label mismatch | NVD/Tenable score it 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H because it is remotely reachable and availability-impacting. Apache upstream labels it low, which better reflects the *real deployment prerequisites*. |
| Affected versions | For CVE-2022-30522, the meaningful upstream exposure is Apache HTTP Server 2.4.53 with mod_sed configured to transform very large content. The plugin’s prior to 2.4.54 wording over-broadens that condition. |
| Fixed versions | Upstream fix is 2.4.54. Example distro backports: Ubuntu 22.04 LTS 2.4.52-1ubuntu4.1, 20.04 LTS 2.4.41-4ubuntu3.12; Debian bullseye fixed in 2.4.54-1~deb11u1. |
| Exposure reality | This only matters if you both load mod_sed and bind it to reachable request/response paths with large content. Apache’s own docs mark mod_sed as experimental; that sharply narrows exposed population. |
| Scanner fidelity | The plugin itself says Nessus did not test exploitation and relied on self-reported version number. For prioritization, that is the whole story: this is a weak-fidelity finding until local config proves mod_sed is in play. |
Sources.
Why this verdict
- Start from Tenable's 7.5, then cut hard for prerequisites: the crash path exists only when the host is effectively vulnerable
2.4.53,mod_sedis loaded, and that module is attached to a reachable large-content flow. - Attacker position is easy, but population is tiny: this is *unauthenticated remote* in theory, yet the required config implies a very small slice of real Apache deployments compared with generic public web serving.
- Modern edge controls remove many attempts before Apache sees them: body-size caps in CDNs, WAFs, reverse proxies, and app gateways often stop the oversized content needed to hit the bug.
- Blast radius is limited to DoS: the realistic outcome is worker abort / service degradation, not authentication bypass, data theft, or code execution.
- The scanner overstates exposure: plugin
193423is explicitly version-only and does not validatemod_sed,InputSed,OutputSed, or large-body reachability.
Why not higher?
There is no KEV listing, no solid evidence of active exploitation, and no meaningful confidentiality or integrity impact. More importantly, the exploit chain depends on an uncommon experimental module and specific content-filter configuration, which sharply reduces the reachable enterprise population.
Why not lower?
This is still remotely triggerable DoS if the exact module/config combination exists on an internet-facing host. If you do use mod_sed on upload or large-response paths, the issue stops being theoretical and can disrupt service, so it is not pure ignore-tier noise.
Crowdsourced verification payload.
Run this on the target Apache host, not from a scanner box. Invoke it as sudo bash ./check-cve-2022-30522.sh; root is recommended so apachectl can enumerate loaded modules and the script can read all config includes. It outputs VULNERABLE, PATCHED, or UNKNOWN based on version, distro backport evidence, mod_sed load state, and active Sed directives.
#!/usr/bin/env bash
# check-cve-2022-30522.sh
# Determine practical exposure to Apache HTTP Server CVE-2022-30522
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
CVE="CVE-2022-30522"
APACHE_CTL=""
APACHE_BIN=""
CONFIG_ROOTS=(/etc/httpd /etc/apache2 /usr/local/apache2/conf)
find_apache() {
for x in apachectl apache2ctl; do
if command -v "$x" >/dev/null 2>&1; then
APACHE_CTL="$(command -v "$x")"
break
fi
done
for x in httpd apache2 apache; do
if command -v "$x" >/dev/null 2>&1; then
APACHE_BIN="$(command -v "$x")"
break
fi
done
}
ver_ge() {
# returns 0 if $1 >= $2
[ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}
ver_gt() {
[ "$1" != "$2" ] && ver_ge "$1" "$2"
}
get_version() {
local out ver
out=""
if [ -n "$APACHE_BIN" ]; then
out="$($APACHE_BIN -v 2>/dev/null || true)"
fi
if [ -z "$out" ] && [ -n "$APACHE_CTL" ]; then
out="$($APACHE_CTL -v 2>/dev/null || true)"
fi
ver="$(printf '%s' "$out" | sed -n 's/.*Apache\/\([0-9][0-9.]*\).*/\1/p' | head -n1)"
printf '%s' "$ver"
}
has_backport_fix() {
# Debian/Ubuntu package changelog
if command -v dpkg-query >/dev/null 2>&1; then
if dpkg-query -W apache2 >/dev/null 2>&1; then
if zgrep -qi "$CVE" /usr/share/doc/apache2/changelog.Debian.gz 2>/dev/null; then
return 0
fi
if grep -Rqi "$CVE" /usr/share/doc/apache2* 2>/dev/null; then
return 0
fi
fi
fi
# RPM package changelog
if command -v rpm >/dev/null 2>&1; then
if rpm -q httpd >/dev/null 2>&1; then
if rpm -q --changelog httpd 2>/dev/null | grep -qi "$CVE"; then
return 0
fi
fi
fi
return 1
}
mod_sed_loaded() {
local mods
mods=""
if [ -n "$APACHE_CTL" ]; then
mods="$($APACHE_CTL -M 2>/dev/null || true)"
elif [ -n "$APACHE_BIN" ]; then
mods="$($APACHE_BIN -M 2>/dev/null || true)"
fi
printf '%s' "$mods" | grep -Eq '(^|[[:space:]])sed_module[[:space:]]'
}
sed_directives_present() {
local root found=1
for root in "${CONFIG_ROOTS[@]}"; do
if [ -d "$root" ]; then
if grep -RIEq '^\s*(InputSed|OutputSed|AddInputFilter\s+Sed\b|AddOutputFilter\s+Sed\b)' "$root" 2>/dev/null; then
return 0
fi
fi
done
return 1
}
say() {
printf '%s\n' "$1"
}
find_apache
if [ -z "$APACHE_BIN" ] && [ -z "$APACHE_CTL" ]; then
say "UNKNOWN: Apache binary/control utility not found"
exit 2
fi
VERSION="$(get_version)"
if [ -z "$VERSION" ]; then
say "UNKNOWN: Could not determine Apache version"
exit 2
fi
# First, honor distro backport evidence.
if has_backport_fix; then
say "PATCHED: Package metadata/changelog references ${CVE}; likely fixed via distro backport"
exit 0
fi
# Upstream logic for CVE-2022-30522 is much narrower than '<2.4.54'.
if ver_gt "$VERSION" "2.4.53"; then
say "PATCHED: Apache version ${VERSION} is newer than upstream vulnerable 2.4.53"
exit 0
fi
if [ "$VERSION" != "2.4.53" ]; then
say "PATCHED: Upstream CVE-2022-30522 is tied to 2.4.53 behavior, not generic older Apache"
exit 0
fi
# Exactly 2.4.53: now check practical exposure.
if mod_sed_loaded; then
if sed_directives_present; then
say "VULNERABLE: Apache 2.4.53 with mod_sed loaded and active Sed directives present"
exit 1
else
say "UNKNOWN: Apache 2.4.53 has mod_sed loaded, but no active Sed directives were found in common config roots"
exit 2
fi
else
say "PATCHED: Apache 2.4.53 detected, but mod_sed is not loaded so the CVE-2022-30522 code path is not active"
exit 0
fi