JUNG Unchained: Host Header Hijacking in Smart Visu Server

The JUNG Smart Visu Server (SV-SERVER) is the brain of a modern KNX smart home installation. It’s the shiny box that lets you dim the lights, check the thermostat, and lock the doors from your iPad. It’s designed to be 'set and forget'—tucked away in a server closet, running quietly. Under the hood, however, it’s running a web stack that includes Jetty 9.2.12.v20150709. For those keeping score, that version of Jetty was released in 2015. In internet years, that’s the Paleolithic era.

But outdated software isn't the primary star of this show; it's a classic logic flaw. The device exposes a REST API (/rest/items) used by the frontend to render the status of switches and sensors. To navigate this API, the server provides hypermedia controls—links to related resources. The problem? The server has an identity crisis. It doesn't know who it is, so it asks the person talking to it. And as we know in security, trusting the client is the original sin.

Web servers often sit behind load balancers or reverse proxies. To ensure the backend knows the original domain requested by the user, proxies add headers like X-Forwarded-Host. A well-behaved application validates this header against a whitelist or ignores it entirely in favor of a hardcoded configuration. The JUNG Smart Visu Server, however, treats X-Forwarded-Host as gospel truth.

When a request comes in, the application logic constructs absolute URLs for its JSON responses. Instead of using relative paths (e.g., /rest/items/1) or a configured canonical hostname, it dynamically builds the URL using the host header provided in the request. If the standard Host header is present, it uses that. But if X-Forwarded-Host appears, it takes precedence without sanitization.

This is a textbook Host Header Injection. The application logic effectively says: "Oh, you say you're connecting to evil-hacker.com? Sure thing, I'll update all my internal links to point there." This transforms the server into an open redirection generator and, more dangerously, a vehicle for cache poisoning.

While the source code is proprietary, the behavior is observable through black-box testing. The vulnerability manifests in the /rest/items endpoint. The server returns a JSON array of smart home objects (switches, dimmers), each containing a link field.

Here is the logic flow in pseudocode based on the observed behavior:

// Pseudo-code reconstruction of the flaw
String targetHost = request.getHeader("X-Forwarded-Host");
if (targetHost == null) {
    targetHost = request.getHeader("Host");
}
 
// The Fatal Flaw: Concatenating input directly into the response payload
String itemUrl = "http://" + targetHost + "/rest/items/" + itemId;
jsonResponse.add("link", itemUrl);

Because there is no validation (if (!whitelist.contains(targetHost))), any string passed in the header is reflected. This includes IP addresses, domain names, or even potentially malicious schemes if the protocol isn't hardcoded (though in this specific CVE, the focus is the Host).

Let's walk through a Cache Poisoning scenario. Suppose the JUNG server is sitting behind a caching reverse proxy (common in larger deployments or ISP setups) or the user's browser caches the API response.

Step 1: The attacker sends a crafted request.

curl "http://TARGET_IP:8080/rest/items" \
 -H "X-Forwarded-Host: phishing-site.com"

Step 2: The server responds with poisoned JSON.

[
  {
    "name": "Living_Room_Lights",
    "type": "SwitchItem",
    "link": "http://phishing-site.com/rest/items/Living_Room_Lights",
    "state": "OFF"
  }
]

Step 3: The Victim's UI loads. The legitimate user opens their smart home dashboard. The dashboard requests /rest/items. If the cache returns the poisoned response above, the dashboard will render buttons that, when clicked (or polled), send traffic to phishing-site.com instead of the local controller. This could be used to harvest session tokens (if sent via query params or headers) or serve a fake login page claiming the device needs a "firmware update."

As of the disclosure in February 2026, the vendor has not released a firmware update. This leaves the remediation burden on the network administrator. The most effective fix is to perform the validation that the application skips.

Option 1: Reverse Proxy Filtering If you run Nginx or HAProxy in front of the SV-SERVER, strip the header explicitly:

# Nginx Configuration
location / {
    proxy_pass http://jung_backend;
    # Force the Host to be the real IP/Domain
    proxy_set_header Host $host;
    # Drop the malicious header
    proxy_set_header X-Forwarded-Host "";
}

Option 2: Network Segmentation Ensure these devices are never exposed directly to the internet. They should live on a dedicated IoT VLAN with no inbound access from the WAN. If remote access is needed, use a VPN. Relying on the device's built-in security is rarely a winning strategy.