Nginx leaks internal LAN IP address

Syncloud.it Feature requests and development
1

Hi Boris,
I wrote a small diagnostic tool to check the security of my infrastructure from the outside. In the process, I noticed the following minor issue related to Nginx on the SynCloud appliance:

Bug Report: nginx leaks internal LAN IP address in redirect `Location` header**

Summary

The nginx reverse proxy bundled with the Syncloud appliance discloses the device’s internal LAN IP address to unauthenticated external clients. When an HTTP request is sent without a `Host` header (e.g. plain HTTP/1.0), any nginx-generated redirect (such as the automatic “add trailing slash” redirect for a directory path) uses the server’s internal address instead of the public hostname in the `Location` response header.
This allows anyone on the internet — including routine internet-wide scanners (e.g. Shodan, Censys), which commonly send minimal/no-Host requests — to learn the private LAN IP address of the device behind the router/NAT, without any authentication.

Affected Component

  • nginx bundled/managed by the Syncloud platform, serving the Syncloud web UI over HTTPS (port 443).

  • Observed nginx version: 1.24.0

Environment

  • Syncloud appliance on a Raspberry Pi, behind a FritzBox router doing NAT/port-forwarding of the appliance’s device port 443 to the router’s public IP.

  • Device’s internal LAN IP at time of testing: 192.168.178.222.

  • Router’s public IP at time of testing: <redacted, dynamic>.

  • Domain configured for the instance: <redacted>.syncloud.it (Let’s Encrypt certificate, CN and SAN both set to that domain).

Steps to Reproduce

  1. Open a raw TCP connection to the appliance’s public IP on port 443 and complete a TLS handshake (no SNI / hostname required — a bare IP connection works).

  2. Send a plain HTTP/1.0 request without a Host header for any directory-style path that nginx will redirect with a trailing slash, e.g.:

    GET /images HTTP/1.0

    (Two trailing CRLFs, no Host: line — valid per the HTTP/1.0 spec.)

    Equivalent one-liner used to reproduce this:

printf 'GET /images HTTP/1.0\r\n\r\n' \
  | openssl s_client -connect <public-ip>:443 -quiet
  1. Observe the response.

Actual Result

HTTP/1.1 301 Moved Permanently
Server: nginx/1.24.0
Date: Sun, 04 Oct 2026 15:33:48 GMT
Content-Type: text/html
Content-Length: 169
Location: https://192.168.178.222/images/
Connection: close
Strict-Transport-Security: max-age=31536000; includeSubdomains
Access-Control-Allow-Origin: *
Cache-Control: no-cache

(<public-ip> in the request above was the router’s real public IP at test time; omitted here since it is dynamic and not needed to understand or reproduce the bug on any other Syncloud instance.)

The Location header contains the device’s private RFC 1918 LAN address (192.168.178.222), not the public hostname.

For comparison, the same request with a Host header (e.g. Host: <public-ip> or Host: <domain>.syncloud.it) correctly returns a Location header using that same host, with no internal IP disclosed.

Expected Result

The Location header should always use the externally-known hostname (or at minimum omit the authority entirely and issue a relative redirect such as Location: /images/), regardless of what Host header the client did or did not send. The internal LAN IP address should never be disclosed to an external client under any circumstances.

Impact

  • Information disclosure of internal network topology (private LAN IP addressing scheme) to any unauthenticated remote party.

  • No direct data access or authentication bypass results from this alone, but it is useful reconnaissance for an attacker: it confirms the device sits behind NAT, reveals the LAN’s addressing scheme (e.g. 192.168.178.0/24 and that this host is .222), and is exactly the kind of detail that gets indexed by internet-wide scanners and later correlated with other data.

  • Related to the pattern described in CWE-200 (information exposure) and is the same class of issue as the long-standing CVE-2000-0649 “web server reveals its internal or real IP in the Location header via a request with HTTP/1.0”).

  • Severity: low-to-medium. Not independently exploitable, but should be fixed as defense-in-depth / information-leakage hardening.

Suggested Fix (nginx configuration)

Either of the following standard nginx fixes resolves the issue:

  1. Disable absolute redirects so nginx emits relative Location headers that never include a host/IP at all:

    absolute_redirect off;

  2. Or explicitly set server_name to the real domain and reject requests with an unexpected/missing Host header (e.g. via a catch-all server { ... return 444; } default server block), so nginx never falls back to using its own bind address for the redirect target.

Could you please check?

Regards,
Ralf