fix(dev): bind dx serve to a private LAN IP only #378

Merged

David merged 1 commit from fix/MAPPS-dev-bind-private-ip into main

2026-06-28 23:24:16 +02:00

David commented

2026-06-28 23:13:55 +02:00

Owner

Re-implements the security fix from the stale PR #377 on top of current main.

The just dev recipe discovered the first non-loopback IPv4 on an en*/eth*/br*/wlan* interface and bound dx serve (port 4301) to it, with no public/private distinction. On this host br0 carries a public address, so the dev frontend was published on the internet. A sibling stack exposed the same way had its Postgres compromised by the PG_MEM botnet.

Discovery now keeps only RFC1918 (private) addresses (10/8, 172.16/12, 192.168/16) and falls back to 127.0.0.1 with a warning when no private candidate exists, so dx serve can never be published on a public interface. Retains the wider en*/eth*/br*/wlan* interface match that main's current recipe added. The dev-sso path already forced HOST_IP=127.0.0.1 and is unchanged.

PR #377 fixed the same hole but was authored against an older revision of the recipe (before main widened the interface match and added the empty-candidates error path), so it no longer applies cleanly (mergeable: false). Close #377 in favor of this.

Verified the discovery logic against three cases: mixed public+private picks the private address and skips public br0; public-only falls back to loopback; the 172.16-31 boundary is exact (172.20 private, 172.32 public). just pre-commit passes.

Re-implements the security fix from the stale PR #377 on top of current `main`. The `just dev` recipe discovered the first non-loopback IPv4 on an en*/eth*/br*/wlan* interface and bound dx serve (port 4301) to it, with no public/private distinction. On this host br0 carries a public address, so the dev frontend was published on the internet. A sibling stack exposed the same way had its Postgres compromised by the PG_MEM botnet. Discovery now keeps only RFC1918 (private) addresses (`10/8`, `172.16/12`, `192.168/16`) and falls back to `127.0.0.1` with a warning when no private candidate exists, so dx serve can never be published on a public interface. Retains the wider `en*/eth*/br*/wlan*` interface match that main's current recipe added. The dev-sso path already forced `HOST_IP=127.0.0.1` and is unchanged. PR #377 fixed the same hole but was authored against an older revision of the recipe (before main widened the interface match and added the empty-candidates error path), so it no longer applies cleanly (`mergeable: false`). Close #377 in favor of this. Verified the discovery logic against three cases: mixed public+private picks the private address and skips public br0; public-only falls back to loopback; the 172.16-31 boundary is exact (172.20 private, 172.32 public). `just pre-commit` passes.

David added 1 commit

2026-06-28 23:13:55 +02:00

fix(dev): bind dx serve to a private LAN IP only

Check / fmt + clippy + tests (pull_request) Successful in 9m8s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

32a1021c93

The `just dev` recipe discovered the first non-loopback IPv4 on an en*/eth*/br*/wlan* interface and bound dx serve (port 4301) to it, with no public/private distinction. On this host br0 carries a public address, so the dev frontend was published on the internet. A sibling stack exposed the same way had its Postgres compromised by the PG_MEM botnet.

Discovery now keeps only RFC1918 (private) addresses and falls back to 127.0.0.1 with a warning when the only candidate is public, so dx serve can never be published on a public interface. Retains the wider en*/eth*/br*/wlan* interface match from the current recipe. The dev-sso path already forced HOST_IP=127.0.0.1 and is unchanged.

Supersedes the stale PR #377, which fixed the same hole against an older revision of the recipe and no longer applies cleanly.