# Nginx leaks internal LAN IP address

**URL:** <https://syncloud.discourse.group/t/nginx-leaks-internal-lan-ip-address/688>\
**Category:** Feature requests and development\
**Created:** [5 October 2026 10:04 UTC](https://syncloud.discourse.group/t/nginx-leaks-internal-lan-ip-address/688 "2026-10-05T10:04:04Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ralfb](https://yyz2.discourse-cdn.com/free1/user_avatar/syncloud.discourse.group/ralfb/32/288_2.png) [@ralfb](https://syncloud.discourse.group/u/ralfb)\
**Post date:** [5 October 2026 10:04 UTC](https://syncloud.discourse.group/t/nginx-leaks-internal-lan-ip-address/688/1 "2026-10-05T10:04:04Z")

</div>

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.:

```auto
printf 'GET /images HTTP/1.0\r\n\r\n' \
  | openssl s_client -connect <public-ip>:443 -quiet

```

1. Observe the response.

## Actual Result

```auto
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](https://nvd.nist.gov/vuln/detail/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:

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