Internal Network Disclosure

Description

Internal network disclosure occurs when an application unintentionally reveals information about its private network environment to external users. This includes RFC-1918 IP addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x), internal DNS hostnames, service banners, infrastructure component names, and network topology details. CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor covers this broad class of information leakage.

While the CVSS score is low because this vulnerability is not directly exploitable on its own, its significance in a real-world attack chain is consistently underestimated. Internal network details convert general reconnaissance into targeted attacks: knowing that a database server is named prod-mysql-01.internal and sits at 10.20.5.10 allows an attacker who gains any foothold to pivot precisely rather than scanning blindly.

This finding is classified under A05:2021 — Security Misconfiguration because the disclosure is almost always a result of verbose error messages, debug headers, or improperly handled server responses that were never intended to reach production.

How It Works

Common disclosure locations found during penetration tests:

HTTP response headers — reverse proxies and load balancers frequently forward internal routing headers:

HTTP/1.1 200 OK
X-Forwarded-Server: internal-nginx-02.prod.example.local
Via: 1.1 10.0.1.45 (nginx/1.18.0)
X-Backend-Host: app-server-03:8080

Application error messages — unhandled exceptions often include stack traces with file system paths, internal hostnames, and connection strings:

com.example.db.ConnectionException: Cannot connect to 10.20.5.10:5432 (prod-postgres-primary.internal)
  at com.example.db.Pool.getConnection(Pool.java:142)

Redirect responses — when an application generates absolute redirect URLs for internal routing, the Location header may contain internal addresses:

HTTP/1.1 302 Found
Location: http://10.0.0.23/dashboard

DNS rebinding artefacts and CORS responses — misconfigured CORS policies that reflect the Origin header can inadvertently confirm internal hostname formats accepted by the server.

Impact

• Reconnaissance acceleration — attackers skip network scanning phases and target specific hosts directly, reducing detection probability.
• SSRF target identification — internal IP addresses and hostnames discovered from disclosures can be fed directly into SSRF payloads to access internal services.
• Credential reuse targeting — internal hostname patterns often reveal naming conventions that identify other hosts not directly disclosed.
• Phishing and social engineering enhancement — knowledge of internal service names makes pretexting attacks more convincing to internal staff.

Detection

1. Inspect all HTTP response headers — use Burp Suite's Proxy history to search responses for RFC-1918 address patterns (10\., 172\.(1[6-9]|2[0-9]|3[01])\., 192\.168\.) and .internal, .local, .corp hostname suffixes.
2. Trigger error conditions deliberately — send malformed requests, invalid content types, and oversized inputs to force unhandled exceptions that may include internal network details in stack traces.
3. Test redirect flows — follow all redirects manually and inspect Location headers for internal addressing.
4. Check API response bodies — JSON and XML responses for resource creation or status endpoints sometimes include internal URLs in href, self, or links fields in HATEOAS-style APIs.
5. Review DNS and certificate transparency — certificate transparency logs often contain internal SANs that were mistakenly included in public TLS certificates.

Remediation

Suppress verbose error messages in production. Configure all application frameworks to return generic error pages to clients. Log full stack traces server-side only. In Express.js this means never passing err objects directly to res.send(); in Spring Boot, set server.error.include-stacktrace=never.

Strip internal headers at the edge. Configure reverse proxies (Nginx, HAProxy, Cloudflare) to remove or replace headers like Via, X-Forwarded-Server, X-Backend-Host, and Server before responses reach external clients.

Use generic hostnames in connection configurations. Reference database and service connections by DNS aliases rather than IP addresses; ensure those DNS names are not included in external-facing responses.