This is leaving the make and trim badge on the getaway car, not leaving the keys in it
Tenable plugin 106232 fires when an Apache HTTP Server returns a verbose Server header because ServerTokens is not effectively constrained to Prod. Apache's own documentation says ServerTokens controls the Server response header, and older official docs show the default can be Full, which may disclose the Apache version, OS family, and sometimes compiled-in module details. This is configuration-dependent across Apache HTTP Server branches; it is not a software defect tied to a fixed vulnerable version range or a vendor patch train.
Tenable's MEDIUM baseline is too high for enterprise patch prioritization. In the real world, this finding gives an unauthenticated remote user only reconnaissance data, then still requires a second reachable and exploitable weakness to matter; reverse proxies, CDNs, and load balancers also frequently rewrite or suppress the backend header, which further narrows practical value.
3 steps from start to impact.
Collect the banner with curl / Nessus
HEAD or GET request and reads the Server header. If Apache is configured with verbose ServerTokens, the response may reveal the product, version, OS family, and occasionally module information. Tenable detects this remotely with a passive header check; there is no memory corruption, auth bypass, or parser bug here.- Unauthenticated network reachability to the HTTP or HTTPS listener
- Apache is directly exposed or its header survives the proxy chain
- The
Serverheader is not normalized toApacheor removed upstream
- CDNs, reverse proxies, WAFs, and load balancers often overwrite or hide the origin banner
- Some deployments already force
ServerTokens Prod, making the finding disappear without software changes - The header can be stale or misleading relative to the actual backend build
curl -I, browser dev tools, Shodan-style banner collection, and most web scanners can all see this immediately.Map disclosed details to a follow-on exploit
- The banner exposes enough detail to narrow to a specific version, OS, or module set
- A separately exploitable weakness exists on the same target or adjacent stack component
- That second weakness is reachable from the attacker's position
- Banner strings do not prove actual vulnerability state because of backports, custom builds, or intermediaries
- A matching CVE may not exist for the disclosed version at all
- Modern patching, virtual patching, and compensating controls break the chain at this stage
Exploit the separate weakness
- A real exploitable bug or misconfiguration beyond verbose headers
- Attacker tooling for that second issue such as Metasploit, custom exploit code, or credential attacks
- Defensive stack does not stop the follow-on attempt
- EDR, WAF, MFA, segmentation, and routine patching can stop the actual compromise stage
- Many enterprises terminate TLS and normalize headers at edge infrastructure, limiting host-level attribution
- Even successful fingerprinting often lands on well-maintained, non-vulnerable web tiers
ServerTokens leak. Treat the verbose header as a hygiene signal and the subsequent exploit attempt as the true alertable event.The supporting signals.
| In-the-wild status | No active exploitation evidence located for this finding class. It is a configuration disclosure, not a CVE-backed exploit primitive, and I found no CISA or GreyNoise evidence tying ServerTokens banner leakage itself to active campaigns. |
|---|---|
| Proof-of-concept availability | Trivial to reproduce, but not really a PoC class. curl -I https://target or any scanner can read the header; Tenable's own plugin is a remote passive check rather than exploit code. |
| EPSS | N/A. There is no CVE identifier for plugin 106232, so there is no FIRST EPSS score or percentile to anchor on. |
| KEV status | Not applicable / not listed. CISA's KEV catalog is CVE-based, and this is a header-hardening issue rather than a cataloged exploited vulnerability. |
| CVSS vector meaning | Tenable assigns CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N (5.3). That translates to *network-reachable low-grade confidentiality leakage only* with no integrity or availability impact. |
| Affected scope | Configuration-dependent across Apache HTTP Server deployments. Any Apache instance that returns a verbose Server header because ServerTokens is more permissive than Prod can trigger the finding; older Apache 2.2 docs show ServerTokens Full as the default behavior. |
| Fixed state | No patch version exists. The effective fix is configuration hardening: set ServerTokens Prod; in practice pair it with ServerSignature Off. Distro backports are irrelevant because this is not a code flaw. |
| Scanning / exposure reality | Exposure tracks your public web footprint, not a vulnerable build range. Censys and Shodan both support queries against HTTP Server headers, which means already-public Apache listeners are easy to inventory at internet scale if the banner is exposed. |
| Disclosure timeline | Tenable published plugin 106232 on 2018-01-22 and updated it on 2020-04-22. |
| Reporting / reference orgs | Detection logic is from Tenable; hardening guidance is consistent with Apache HTTP Server documentation, OWASP Secure Headers, and GitLab DAST guidance on removing version-revealing Server headers. |
noisgate verdict.
The decisive factor is that this finding is pure reconnaissance: it requires only an exposed web listener and returns only banner metadata, not code execution or trust-boundary bypass. Its value is further diluted because many real deployments front Apache with CDNs, reverse proxies, or load balancers that rewrite the header and because a separate exploitable flaw is still required for compromise.
Why this verdict
- Start at Tenable's 5.3: the vendor scores this as network-readable confidentiality loss only, with no integrity or availability consequence.
- Downward adjustment for attacker value: the leak does not execute attacker-controlled input, bypass auth, or expose secrets by itself; it only improves fingerprinting and target selection.
- Downward adjustment for compounding friction: practical abuse assumes a prior condition chain of public exposure, unmodified origin banner, and then a *second* reachable vulnerability that matches the disclosed stack details.
Why not higher?
There is no direct exploitation path from this plugin alone. Even perfect fingerprinting does not deliver shell, data access, or account takeover unless a separate weakness exists and remains reachable after proxies, patching, and controls are factored in.
Why not lower?
It is still externally observable reconnaissance data on many public web tiers, and at scale that matters for adversary target selection. For internet-facing Apache estates, normalizing headers is worthwhile baseline hardening even if it should not consume urgent patching bandwidth.
What to do — in priority order.
- Set
ServerTokens Prod— Configure Apache to return onlyServer: Apacheinstead of version, OS, or module details. Because this is a LOW finding, there is no formal SLA; fold it into normal web-tier hardening and deploy during the next routine configuration cycle. - Set
ServerSignature Off— Suppress Apache-generated footer details on error pages and status-style content so you do not hide the header while still leaking the same metadata elsewhere. Pair this with theServerTokenschange in the same maintenance window. - Normalize headers at the edge — If traffic passes through a CDN, reverse proxy, or load balancer, strip or overwrite verbose
Serverheaders there as a defense-in-depth control. This is often faster than touching every origin and is the right move for large fleets. - Validate the web baseline — Use a simple header audit across internet-facing VIPs to catch drift, inherited distro defaults, and forgotten legacy vhosts. For a 10,000-host estate, this belongs in your standard hardening baseline rather than your emergency patch lane.
- Upgrading Apache alone does not solve this if the effective configuration still emits a verbose
Serverheader. - EDR on the host does not prevent the disclosure because the banner is returned as part of normal HTTP behavior before any malicious payload appears.
- Removing only
X-Powered-Byor app-framework headers is incomplete if Apache still advertises version or OS details inServer.
Crowdsourced verification payload.
Run this on the target Apache host as a local auditor or via your config-management runner. Invoke it with sudo bash check_servertokens.sh; root is preferred so the script can read Apache config files, but it can still probe localhost headers without elevation.
#!/usr/bin/env bash
# check_servertokens.sh
# Purpose: determine whether Apache is vulnerable to verbose ServerTokens disclosure.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
status="UNKNOWN"
reason=""
have_cmd() { command -v "$1" >/dev/null 2>&1; }
trim() {
sed -E 's/^[[:space:]]+//; s/[[:space:]]+$//'
}
probe_header() {
local url="$1"
if ! have_cmd curl; then
return 1
fi
curl -ksSI --max-time 5 "$url" 2>/dev/null | awk 'BEGIN{IGNORECASE=1} /^Server:/ {sub(/\r$/, ""); print; exit}'
}
header_is_verbose() {
local line="$1"
local value
value="${line#Server: }"
# Vulnerable if Apache discloses version, OS, or module detail.
# Safe if exactly 'Apache' (case-insensitive) or no Apache header at all.
if [[ -z "$value" ]]; then
return 1
fi
shopt -s nocasematch
if [[ "$value" =~ ^Apache$ ]]; then
shopt -u nocasematch
return 1
fi
if [[ "$value" =~ ^Apache(/|[[:space:]]+\(|[[:space:]]+[A-Za-z0-9_-]) ]]; then
shopt -u nocasematch
return 0
fi
shopt -u nocasematch
return 1
}
collect_configs() {
local files=()
local roots=(
/etc/httpd/conf/httpd.conf
/etc/httpd/conf.modules.d/*.conf
/etc/httpd/conf.d/*.conf
/etc/apache2/apache2.conf
/etc/apache2/httpd.conf
/etc/apache2/conf-enabled/*.conf
/etc/apache2/conf.d/*.conf
/usr/local/apache2/conf/httpd.conf
)
local p
for p in "${roots[@]}"; do
for f in $p; do
[[ -r "$f" ]] && files+=("$f")
done
done
printf '%s\n' "${files[@]}" | awk 'NF && !seen[$0]++'
}
config_servertokens_state() {
local files
files=$(collect_configs)
[[ -z "$files" ]] && return 1
awk '
BEGIN { IGNORECASE=1 }
/^[[:space:]]*#/ { next }
{
line=$0
sub(/[[:space:]]*#.*/, "", line)
if (match(line, /^[[:space:]]*ServerTokens[[:space:]]+([^[:space:]]+)/, m)) {
last=m[1]
}
}
END {
if (last != "") print last
}
' $files 2>/dev/null | tail -n 1
}
http_header=$(probe_header "http://127.0.0.1/")
https_header=$(probe_header "https://127.0.0.1/")
config_state=$(config_servertokens_state | trim)
if [[ -n "$http_header" ]] && header_is_verbose "$http_header"; then
echo "VULNERABLE"
echo "Reason: verbose live HTTP header: $http_header"
exit 1
fi
if [[ -n "$https_header" ]] && header_is_verbose "$https_header"; then
echo "VULNERABLE"
echo "Reason: verbose live HTTPS header: $https_header"
exit 1
fi
shopt -s nocasematch
if [[ -n "$config_state" ]]; then
if [[ "$config_state" =~ ^Prod(uctOnly)?$ ]]; then
if [[ -n "$http_header" || -n "$https_header" ]]; then
echo "PATCHED"
echo "Reason: live localhost header is not verbose and config sets ServerTokens $config_state"
exit 0
else
echo "PATCHED"
echo "Reason: config sets ServerTokens $config_state (no live localhost header observed)"
exit 0
fi
elif [[ "$config_state" =~ ^(Full|OS|Minor|Major|Min|Minimal)$ ]]; then
echo "VULNERABLE"
echo "Reason: Apache config sets ServerTokens $config_state"
exit 1
fi
fi
shopt -u nocasematch
if [[ -n "$http_header" || -n "$https_header" ]]; then
echo "PATCHED"
echo "Reason: live localhost header is not verbose"
exit 0
fi
echo "UNKNOWN"
echo "Reason: could not read an Apache config decision or observe a localhost Apache header"
exit 2
If you remember one thing.
ServerTokens Prod plus ServerSignature Off into your next standard web-tier configuration cycle rather than burning urgent patch capacity on it.Sources
- Tenable Nessus Plugin 106232
- Apache HTTP Server 2.4 Server-Wide Configuration
- Apache HTTP Server 2.2 Core `ServerTokens` Directive
- OWASP Secure Headers Project
- GitLab DAST: Server header exposes version information
- MITRE CWE-200
- CISA Known Exploited Vulnerabilities Catalog
- Censys Search Language for HTTP Server headers
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.