CWE-1327

CUPS is a standards-based, open-source printing system, and `cups-browsed` contains network printing functionality including, but not limited to, auto-discovering print services and shared printers. `cups-browsed` binds to `INADDR_ANY:631`, causing it to trust any packet from any source, and can cause the `Get-Printer-Attributes` IPP request to an attacker controlled URL. When combined with other vulnerabilities, such as CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177, an attacker can execute arbitrary commands remotely on the target machine without authentication when a malicious printer is printed to.

Instruments with Illumina Universal Copy Service v2.x are vulnerable due to binding to an unrestricted IP address. An unauthenticated malicious actor could use UCS to listen on all IP addresses, including those capable of accepting remote communications.

argocd-mcp 0.8.0 binds its HTTP transport to every network interface and accepts MCP sessions without requiring caller credentials when ARGOCD_API_TOKEN is configured. Attackers who can reach the listener can invoke the full tool surface using the operator's stored token to create applications, request syncs, and modify Argo CD resources.

PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.59, ToolsMCPServer.run_sse and launch_tools_mcp_server bind to 0.0.0.0 and create /sse and /messages/ routes without invoking the available SecurityConfig authentication, origin-validation, or DNS-rebinding controls. Any reachable client can list and invoke registered tools, and a browser can target a local instance through DNS rebinding, with impact determined by the registered file, shell, and code-execution tools. This vulnerability is fixed in praisonaiagents 1.6.59.

OpenClaw version 2026.1.14-1 prior to 2026.2.12 contains an improper network binding vulnerability in the Chrome extension (must be installed and enabled) relay server that treats wildcard hosts as loopback addresses, allowing the relay HTTP/WS server to bind to all interfaces when a wildcard cdpUrl is configured. Remote attackers can access relay HTTP endpoints off-host to leak service presence and port information, or conduct denial-of-service and brute-force attacks against the relay token header.

A vulnerability in the Silicon One integration for Cisco Nexus 9000 Series Switches could allow an unauthenticated, remote attacker to execute code with root privileges. This vulnerability exists because TCP ports 43210 and 43211 are accessible in the default Layer 3 (L3) virtual routing and forwarding (VRF). A successful exploit could allow the attacker to connect to an affected device and send crafted input that could be executed as code with root privileges. The exploitation of this vulnerability could also cause the S1HAL process to crash, which could cause the device to reload.

fastify-cli starts the Node.js Inspector when a debug flag is used, but it ignores the explicit bind address the user supplies and binds the Inspector to a broadly reachable address instead of the intended loopback. As a result the debugging interface can be exposed beyond the local machine, and because the Inspector protocol allows arbitrary code evaluation, a remote party that reaches it can achieve remote code execution on the developer's machine. This affects fastify-cli from 1.5.0 up to 8.0.1. Users should upgrade to fastify-cli 8.0.1, which honors the configured Inspector bind address.

dbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications. Prior to versions 1.6.15, 1.7.15, and 1.8.1, Binding to `INADDR_ANY (0.0.0.0)` or `IN6ADDR_ANY (::)` exposes an application on all network interfaces, increasing the risk of unauthorized access. As stated in the Python docs, a special form for address is accepted instead of a host address: `''` represents `INADDR_ANY`, equivalent to `"0.0.0.0"`. On systems with IPv6, '' represents `IN6ADDR_ANY`, which is equivalent to `"::"`. A user who serves docs on an unsecured public network, may unknowingly be hosting an unsecured (http) web site for any remote user/system to access on the same network. The issue has has been mitigated in dbt-core v1.6.15, dbt-core v1.7.15, and dbt-core v1.8.1 by binding to localhost explicitly by default in `dbt docs serve`.

Vulnerabilities* in ActADUR local server product, developed and maintained by ProTNS, allows Remote Code Inclusion on host systems.  * vulnerabilities: * Improper Neutralization of Special Elements used in a Command ('Command Injection') * Use of Hard-coded Credentials * Improper Authentication * Binding to an Unrestricted IP Address The vulnerability has been rated as critical.This issue affects ActADUR: from v2.0.1.9 before v2.0.2.0., hence updating to version v2.0.2.0. or above is required.

A binding to an unrestricted IP address vulnerability was discovered in Productivity Suite software version v4.4.1.19. The vulnerability allows an unauthenticated remote attacker to interact with the ProductivityService PLC simulator and read, write, or delete arbitrary files and folders on the target machine

A vulnerability in Apache IoTDB. This issue affects Apache IoTDB: from 1.0.0 before 1.3.7, from 2.0.0 before 2.0.7. Users are recommended to upgrade to version 1.3.7 or 2.0.7, which fixes the issue.

Binding to an unrestricted ip address in Azure IoT Explorer allows an unauthorized attacker to disclose information over a network.

Excessive attack surface due to binding to an unrestricted IP address. The following products are affected: Acronis Agent (Linux, macOS, Windows) before build 30430, Acronis Cyber Protect 15 (Linux, macOS, Windows) before build 35979.

IBM Documentation Offline 1.0.0 through 1.4.1 IBM Documentation could allow a remote attacker to obtain sensitive information due to a security misconfiguration where the documentation server binds to an unrestricted IP address.

Server receiving a malformed message based on a list of IPs resulting in heap corruption causing a denial of service. See Honeywell Security Notification for recommendations on upgrading and versioning.

Deployment of the VPS.org one-click Supabase template deploys a PostgreSQL instance that is published on all interfaces (0.0.0.0:5432) with a default database password set to "postgres". Because Docker installs its own iptables rules, this exposure bypasses a standard host UFW configuration.

A vulnerability exists in Keycloak's server distribution where enabling debug mode (--debug <port>) insecurely defaults to binding the Java Debug Wire Protocol (JDWP) port to all network interfaces (0.0.0.0). This exposes the debug port to the local network, allowing an attacker on the same network segment to attach a remote debugger and achieve remote code execution within the Keycloak Java virtual machine.

In JetBrains PyCharm before 2022.1 exposure of the debugger port to the internal network was possible

Binding to an unrestricted ip address in GitHub allows an unauthorized attacker to execute code over a network.

gopls by default communicates via pipe. However, -port and -listen flags are supported as means of debugging. If -listen is given a value without an explicit host (e.g. :8080), or -port is used, gopls will listen on 0.0.0.0.  As a result, users might inadvertently cause gopls to bind 0.0.0.0. This can allow a malicious party on the same network to execute code arbitrarily via gopls.

9Router is an AI router & token saver. Prior to 0.5.2, 9router determines whether a /v1 LLM proxy request is local by reading the client-controlled Host header, allowing a remote unauthenticated attacker to send Host: localhost and bypass API-key authentication. In the default configuration, this exposes the /v1 proxy to upstream provider calls using stored provider credentials and allows /v1/search with the searxng provider_options.baseUrl parameter to drive server-side requests to internal or cloud-metadata hosts. This issue is fixed in version 0.5.2.

Unrestricted IP address binding in the AMD Device Metrics Exporter (ROCm ecosystem) could allow a remote attacker to perform unauthorized changes to the GPU configuration, potentially resulting in loss of availability

The Boot Dashboard Docker integration in Spring Tools publishes container control ports on all of the host's network interfaces (0.0.0.0) rather than restricting them to loopback. Affected Spring Products and Versions: Spring Tools for Eclipse: 5.2.0 and earlier

Penpot before 2.18.0 binds the MCP server plugin WebSocket bridge to all network interfaces without authentication in single-user mode. Unauthenticated attackers on adjacent networks can connect to the WebSocket port to impersonate the Penpot browser plugin, intercept task payloads, and return forged results to the MCP client.

GitHub CLI (gh) is GitHub's official command line tool. Versions 2.28.0 through 2.97.0 bind the local listener created by gh codespace ports forward to all available network interfaces by default. While port forwarding is active, a service in a Codespace can therefore become reachable through the user's non-loopback local IP addresses by other hosts that can route to the user's machine. This behavior does not change the GitHub-side visibility of the Codespaces port. Instead, it exposes the forwarded service through a wildcard-bound listener on the user's local machine, even when the source Codespaces port remains private. Exploitation requires a network-adjacent attacker to reach the victim's machine while forwarding is active. This issue is fixed in version 2.98.0.

LlamaFarm through 0.0.34 contains an insecure default configuration that binds its unauthenticated FastAPI server to 0.0.0.0 on port 14345, while the lf CLI silently discards HOST overrides. Network-adjacent attackers can call the project and dataset management API to read stored provider API keys, modify projects, trigger ingestion, and irreversibly delete projects.

Excessive attack surface in acep-collector service due to binding to an unrestricted IP address. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 38690.

Excessive attack surface in acep-importer service due to binding to an unrestricted IP address. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 38690.

Excessive attack surface in archive-server service due to binding to an unrestricted IP address. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 38690.

IBM App Connect Enterprise 13.0.1.0 through 13.0.8.2 could allow a remote attacker to obtain sensitive information due to binding to an unrestricted IP address.

## Summary On the Home Assistant add-on, the dashboard serves a trusted ingress site that skips authentication because the supervisor authenticates the request upstream. That site was binding `0.0.0.0`. The add-on runs in host network mode for mDNS, so binding all interfaces also bound the host's LAN interface, and any device on the local network could reach `http://<ha-ip>:<ingress_port>/` and get the full dashboard with no credentials. ## Details The HA add-on ingress site is intentionally unauthenticated: the supervisor's ingress proxy authenticates the browser upstream, and the dashboard's threat model assumes the site is reachable only through the supervisor's docker network. The protection depended on physically binding the site to the supervisor, but the site bound `0.0.0.0` instead. Because the add-on uses host networking, `0.0.0.0` includes the host's LAN address, so the no-auth site was reachable directly from the LAN, bypassing the supervisor and its authentication entirely. This is an auth bypass on a boundary the dashboard explicitly defends. `docs/THREAT_MODEL.md` names, under the surface it still defends, "anything that lets external traffic reach the ingress site without going through the supervisor." The bug is exactly that. The fix, in PR #1565, mirrors what the legacy add-on's nginx did: - Bind the ingress site to loopback plus the supervisor gateway (`127.0.0.1` and `172.30.32.1`) instead of all interfaces. Loopback serves HA core's host-network ESPHome integration, which connects to `127.0.0.1:<ingress_port>` without credentials by design; the gateway serves the supervisor's ingress proxy. The LAN interface is no longer bound; an explicit `--ingress-host` still overrides the bind. - Add `ingress_peer_guard`, which returns 403 to any TCP peer other than loopback or the supervisor (`172.30.32.2`), so another hassio bridge add-on reaching the gateway cannot use the site either. This mirrors the legacy nginx `allow 127.0.0.1; allow 172.30.32.2; deny all`. The password-gated public port (6052) is not affected; this only affects the host-network HA add-on's ingress port. ## Impact Any device on the same local network as the Home Assistant host could open the dashboard with no credentials and gain its full authenticated capability. Per `docs/THREAT_MODEL.md`, that capability is host equivalent: an authenticated caller can run arbitrary Python at compile time via `external_components:`, run arbitrary shell through the compile and validation subprocesses, and read or write arbitrary files in the config and data directories. So the practical impact is full compromise of the add-on, including the Home Assistant config directory it mounts and the ESPHome devices it manages. The exposure was present by default on every host-network HA add-on install; no operator misconfiguration was required. The standalone Docker dashboard and the password-gated public port are not affected. ## Severity rationale An unauthenticated network client reaches a dashboard site that performs no authentication of its own, and a client that reaches the dashboard has host equivalent capability. ESPHome's [threat model](https://github.com/esphome/device-builder/blob/main/docs/THREAT_MODEL.md) documents that a dashboard caller can run arbitrary code at compile time and read or write files in the config and data directories, so confidentiality, integrity, and availability are all High, with no credentials, no user interaction, and low attack complexity. The exposed surface is the Home Assistant host's local network interface rather than the internet, so the attack vector is adjacent, giving a CVSS base score of 8.8. The rating is anchored at the worst case because the exposure was present by default on every host-network HA add-on install, the dominant deployment, and required nothing of the victim. Any party able to reach the host's local network, including a guest network that is not isolated, an untrusted IoT device, or a compromised local host, obtains full control with a single unauthenticated request. Operational risk is lower for installations on a single trusted home or business network behind a firewall, since reaching the dashboard there requires an attacker who is already inside that network, and ESPHome is [designed for deployment on trusted networks](https://esphome.io/guides/security_best_practices/) with the network perimeter as the primary defense. That deployment context reduces real world exposure; it does not change the base severity. The ingress site is intended to require the supervisor's authentication even on the local network, and the fix restores that. ## Patches Fixed in device-builder 1.0.10 (PR #1565). The ingress site is bound to loopback and the supervisor gateway only, and a peer guard rejects any TCP peer other than loopback or the supervisor regardless of `--ingress-host`. The esphome container delivers the fix by bundling device-builder 1.0.10 or newer. ## Workarounds Upgrade to 1.0.10 or newer (an esphome container bundling device-builder 1.0.10+). Without upgrading, restrict access to the add-on's ingress port at the network layer, for example a host or router firewall rule that allows only the Home Assistant host and the supervisor to reach it, and keep the Home Assistant host on a trusted LAN segment. Accessing the dashboard through Home Assistant's normal ingress URL is unaffected and stays authenticated. ## Resources - Fix: esphome/device-builder#1565 - Ingress site introduction: esphome/device-builder#25 - Originating investigation: esphome/device-builder#1560 - ESPHome security best practices: https://esphome.io/guides/security_best_practices/