Web Server HTTP Header Internal IP Disclosure

Tenable plugin 10759 is a symptom check, not a modern exploit chain. It fires when a web stack leaks an internal RFC1918 IP or internal hostname in headers such as Location, Content-Location, or WWW-Authenticate. Tenable maps it to CVE-2000-0649, whose original case was Microsoft IIS 4.0 returning an internal IP after a specially crafted HTTP/1.0 request against a basic-auth protected page with no realm defined; modern hits are often similar misconfigurations on IIS, reverse proxies, load balancers, or Exchange front ends rather than the exact 2000-era bug.

The vendor's LOW call is basically right, and if anything the practical enterprise risk is even lower. The leak is recon-only: it can help an attacker map origin infrastructure or confirm NAT/proxy topology, but it does not grant code execution, authentication bypass, or direct data access. The biggest reality check is request friction: mainstream browsers use HTTP/1.1+ and send Host, so most findings require deliberate malformed probing rather than ambient internet traffic.

Why this verdict

• Malformed request prerequisite: the interesting code path is usually reached with HTTP/1.0 or a missing/NULL Host header, which implies intentional probing rather than ambient user traffic.
• Impact is limited to confidentiality of topology: the leak exposes a private IP or internal hostname, but does not create code execution, auth bypass, or arbitrary read/write.
• Reachable population is narrower than the plugin name suggests: the original CVE is ancient IIS behavior, while many modern detections are configuration quirks on only some URIs, redirects, or auth flows.
• Modern controls often intercept it: reverse proxies, WAFs, canonical-host rules, and strict request parsing commonly stop or normalize the request before the origin leaks anything.
• EPSS is not the deciding signal here: the current EPSS value is high for the CVE record, but the practical enterprise outcome is still a weak recon primitive with limited standalone value.

Why not higher?

To rate higher, this would need to create an attacker foothold or materially shorten time-to-compromise across a broad exposed population. It does neither. The attacker still needs a separate exploitable bug, valid credentials, or another trust boundary failure before the leaked address becomes operationally useful.

Why not lower?

I am not putting this in IGNORE because it can still reveal internal naming and addressing on public services, and that does have reconnaissance value in real attack chains. It also frequently points to sloppy edge or redirect configuration, which is worth cleaning up during normal hardening.

1. Reject malformed host-less requests — At the edge proxy, WAF, or web server, block or normalize HTTP/1.0 requests and requests with missing/NULL Host headers where business-safe. For a LOW finding, deploy during the next normal hardening cycle; there is no accelerated SLA, but this is the cleanest way to suppress the behavior across many hosts at once.
2. Set a canonical public hostname — On IIS-family systems, ensure redirects and server-runtime settings return the public FQDN rather than the origin IP; on other stacks, review Location, Content-Location, and auth/error templates. Do this as backlog hygiene in the next web-tier config sprint.
3. Fix redirect and auth flows — Test folder redirects, auth challenges, and error pages specifically, because those are the paths most likely to leak origin details. Fold this into routine web application hardening rather than emergency change windows.
4. Constrain origin exposure — If the service sits behind a reverse proxy or load balancer, keep the origin unexposed from the internet and restrict direct access with ACLs or network policy. That limits the usefulness of any leaked private address even if the header bug remains.

Run this from an auditor workstation or jump host that can reach the target URL; no admin privileges are required. Save as check-internal-ip-leak.sh and run bash check-internal-ip-leak.sh https://target.example.com /owa/ or bash check-internal-ip-leak.sh http://target.example.com /.

#!/usr/bin/env bash
# check-internal-ip-leak.sh
# Purpose: Detect RFC1918/internal IP disclosure in HTTP response headers using a raw HTTP/1.0 request.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE

set -u

usage() {
  echo "Usage: $0 <url> [path]"
  echo "Example: $0 https://example.com /owa/"
  exit 3
}

[ $# -lt 1 ] && usage

URL="$1"
PATH_PART="${2:-/}"

if [[ ! "$URL" =~ ^https?:// ]]; then
  echo "UNKNOWN - URL must start with http:// or https://"
  exit 2
fi

SCHEME="${URL%%://*}"
REST="${URL#*://}"
HOSTPORT="${REST%%/*}"
HOST="${HOSTPORT%%:*}"
PORT="${HOSTPORT##*:}"

if [[ "$HOST" == "$PORT" ]]; then
  if [[ "$SCHEME" == "https" ]]; then PORT=443; else PORT=80; fi
fi

REQ=$(printf 'GET %s HTTP/1.0\r\nUser-Agent: noisgate-check/1.0\r\nAccept: */*\r\nConnection: close\r\n\r\n' "$PATH_PART")
TMP=$(mktemp)
trap 'rm -f "$TMP"' EXIT

if [[ "$SCHEME" == "https" ]]; then
  RESP=$(printf "%s" "$REQ" | timeout 10 openssl s_client -quiet -connect "${HOST}:${PORT}" -servername "$HOST" 2>/dev/null || true)
else
  RESP=$(printf "%s" "$REQ" | timeout 10 nc "$HOST" "$PORT" 2>/dev/null || true)
fi

if [[ -z "$RESP" ]]; then
  echo "UNKNOWN - no response from ${HOST}:${PORT}"
  exit 2
fi

# Keep only header section
printf '%s\n' "$RESP" | awk 'BEGIN{RS="\r\n\r\n|\n\n"} NR==1{print}' > "$TMP"

if [[ ! -s "$TMP" ]]; then
  echo "UNKNOWN - unable to parse HTTP headers"
  exit 2
fi

# RFC1918, loopback, link-local, CGNAT
IP_REGEX='((10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})|(172\.(1[6-9]|2[0-9]|3[0-1])\.[0-9]{1,3}\.[0-9]{1,3})|(192\.168\.[0-9]{1,3}\.[0-9]{1,3})|(127\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})|(169\.254\.[0-9]{1,3}\.[0-9]{1,3})|(100\.(6[4-9]|[7-9][0-9]|1[01][0-9]|12[0-7])\.[0-9]{1,3}\.[0-9]{1,3}))'

LEAK_LINES=$(grep -E -i '^(Location|Content-Location|WWW-Authenticate|Refresh|Content-Base|URI|Link|Server):' "$TMP" | grep -E "$IP_REGEX" || true)

if [[ -n "$LEAK_LINES" ]]; then
  echo "VULNERABLE - internal/private IP found in response headers"
  echo "$LEAK_LINES"
  exit 1
fi

STATUS=$(head -n 1 "$TMP" | tr -d '\r')
if [[ "$STATUS" =~ ^HTTP/ ]]; then
  echo "PATCHED - no internal/private IP found in tested response headers"
  exit 0
fi

echo "UNKNOWN - non-HTTP response"
exit 2

Sources

1. Tenable Nessus Plugin 10759
2. NVD CVE-2000-0649
3. MITRE CVE record
4. Microsoft support article on IIS internal IP disclosure
5. Rapid7 Metasploit module for IIS internal IP disclosure
6. CISA Known Exploited Vulnerabilities catalog
7. Tenable CVE page with EPSS