T09 · Insecure Skill Coding Practices
Warning
- Location
- snippets/common-configs.md:37
- Finding
- Gateway Configuration Binds to All Network Interfaces## Vulnerability Details **File Location**: `snippets/common-configs.md:37-45` **Vulnerability Type**: Insecure network exposure **Risk Level**: Medium ### Vulnerable Code ```json { "gateway": { "host": "0.0.0.0", "port": 8080 } } ``` ### Technical Analysis The ready-to-use configuration binds the gateway to `0.0.0.0`, causing it to listen on every available IPv4 network interface. The example does not include authentication, TLS, firewall restrictions, or an explicit warning about remote exposure. Binding to all interfaces is not inherently vulnerable when appropriate controls exist, but presenting it as a default configuration without corresponding safeguards creates an unsafe deployment pattern. The actual exploitability depends on the gateway's authentication controls and the host's firewall and network configuration. ### Attack Path 1. A user copies the documented gateway configuration. 2. The gateway starts listening on port `8080` on all IPv4 interfaces. 3. The host firewall or surrounding network allows access to that port. 4. An attacker on a reachable local or external network discovers the service. 5. The attacker connects to the exposed gateway and attempts to access any endpoints not protected by adequate authentication or authorization. ### Impact Assessment The maximum impact depends on the gateway capabilities and its independent security controls. If sensitive endpoints are insufficiently protected, a remote attacker could access gateway data or operations available to the service. The configuration itself does not grant operating-system privileges, and the reviewed files do not establish that authentication is absent; therefore, compromise is conditional rather than guaranteed.
- Remediation
- ## Remediation Suggestions - Change the default bind address to `127.0.0.1` so the gateway is locally accessible only. - Require users to opt in explicitly when remote access is necessary. - Add authentication and authorization requirements to any remote-access example. - Terminate TLS directly at the service or through a securely configured reverse proxy. - Restrict inbound access using host and network firewalls, preferably to an explicit allowlist. - Add a prominent warning explaining that `0.0.0.0` exposes the service on all IPv4 interfaces. - Document verification steps, such as inspecting listening sockets and testing access from an untrusted network segment.