← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:106232 · CWE-200 · Disclosed 2018-01-22

Apache ServerTokens Information Disclosure

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

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.

"This is recon fuel, not compromise: fix it as web-tier hygiene, not as a patch emergency."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Collect the banner with curl / Nessus

The attacker sends a normal 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.
Conditions required:
  • Unauthenticated network reachability to the HTTP or HTTPS listener
  • Apache is directly exposed or its header survives the proxy chain
  • The Server header is not normalized to Apache or removed upstream
Where this breaks in practice:
  • 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
Detection/coverage: Very high coverage. Nessus, Nmap NSE, curl -I, browser dev tools, Shodan-style banner collection, and most web scanners can all see this immediately.
STEP 02

Map disclosed details to a follow-on exploit

The attacker correlates the leaked version or module hints with public CVEs, exploit writeups, or hardening gaps. This is where the header becomes useful: it reduces guesswork and improves targeting efficiency, but it does not itself cross any trust boundary. Tools used at this stage are typical recon sources such as NVD, exploit repos, Censys, Shodan, or custom scanners.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Low fidelity on its own. Web logs show only ordinary requests; correlation must come from later exploit attempts, threat intel enrichment, or internet-exposure monitoring.
STEP 03

Exploit the separate weakness

Only after identifying a real second bug can the attacker attempt code execution, file disclosure, auth bypass, or another meaningful impact. The practical blast radius depends entirely on that second vulnerability and the exposed role of the web tier. This plugin therefore behaves like a recon aid, not a standalone intrusion path.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Detection depends on the follow-on exploit, not on the ServerTokens leak. Treat the verbose header as a hygiene signal and the subsequent exploit attempt as the true alertable event.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 availabilityTrivial 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.
EPSSN/A. There is no CVE identifier for plugin 106232, so there is no FIRST EPSS score or percentile to anchor on.
KEV statusNot 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 meaningTenable 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 scopeConfiguration-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 stateNo 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 realityExposure 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 timelineTenable published plugin 106232 on 2018-01-22 and updated it on 2020-04-22.
Reporting / reference orgsDetection 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.6/10)

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.

HIGH Standalone impact is limited to low-grade information disclosure
MEDIUM Observed real-world exposure varies because edge infrastructure often rewrites headers

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.

05 · Compensating Control

What to do — in priority order.

  1. Set ServerTokens Prod — Configure Apache to return only Server: Apache instead 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.
  2. 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 the ServerTokens change in the same maintenance window.
  3. Normalize headers at the edge — If traffic passes through a CDN, reverse proxy, or load balancer, strip or overwrite verbose Server headers there as a defense-in-depth control. This is often faster than touching every origin and is the right move for large fleets.
  4. 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.
What doesn't work
  • Upgrading Apache alone does not solve this if the effective configuration still emits a verbose Server header.
  • 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-By or app-framework headers is incomplete if Apache still advertises version or OS details in Server.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning, stop treating this like a patchable vulnerability and move it into your web hardening backlog. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA; treat it as backlog hygiene, verify which internet-facing VIPs still expose verbose Apache banners, and bundle ServerTokens Prod plus ServerSignature Off into your next standard web-tier configuration cycle rather than burning urgent patch capacity on it.

Sources

  1. Tenable Nessus Plugin 106232
  2. Apache HTTP Server 2.4 Server-Wide Configuration
  3. Apache HTTP Server 2.2 Core `ServerTokens` Directive
  4. OWASP Secure Headers Project
  5. GitLab DAST: Server header exposes version information
  6. MITRE CWE-200
  7. CISA Known Exploited Vulnerabilities Catalog
  8. Censys Search Language for HTTP Server headers
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.