diff --git a/kubernetes/apps/matter-server/deployment.yaml b/kubernetes/apps/matter-server/deployment.yaml
index 3b49b408..794559e7 100644
--- a/kubernetes/apps/matter-server/deployment.yaml
+++ b/kubernetes/apps/matter-server/deployment.yaml
@@ -50,6 +50,19 @@ spec:
           args:
             - --storage-path=/data
             - --port=5580
+            # Bind the :5580 control WebSocket to the pod's eth0 address,
+            # not 0.0.0.0. This pod is multi-homed — net1 is a macvlan on
+            # the IoT VLAN (below) — and macvlan traffic bypasses Cilium
+            # policy, so a 0.0.0.0 bind exposes the unauthenticated Matter
+            # control API to the whole IoT VLAN (verified 2026-07-10: GET
+            # http://<net1 ip>:5580/ from the VLAN returned 200). An IoT
+            # client could then drive the Matter fabric. `--listen-address`
+            # is independent of `--primary-interface`: the WebSocket is the
+            # HA control channel (reached via the ClusterIP Service, IPv4),
+            # while Matter commissioning/discovery stays on net1. POD_IP is
+            # the eth0 IPv4 (status.podIP). This is the matter-server twin
+            # of the shelly-manager fix (PR #142).
+            - --listen-address=$(POD_IP)
             # Pin Matter SDK link-local discovery to the macvlan attachment
             # on the IoT VLAN. Without this, the SDK picks the kernel's
             # default route interface (eth0, Cilium pod CIDR) for Matter
@@ -63,6 +76,11 @@ spec:
             - --vendorid=4939
             - --fabricid=2
             - --log-level=debug
+          env:
+            - name: POD_IP
+              valueFrom:
+                fieldRef:
+                  fieldPath: status.podIP
           ports:
             - name: ws
               containerPort: 5580