github.com/dgraph-io/dgraph/v25: 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

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

curl -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" />

Destructive unauthenticated removeNode

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.

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.