On this page (7 sections)
Dgraph, an open source distributed GraphQL database, has a critical flaw in its Zero component. In versions up to 25.3.8, the administrative HTTP routes on port 6080 require no authentication, so anyone who can reach that port can read cluster details and disrupt the control plane. The issue is tracked as CVE-2026-102748 and fixed in 25.4.0.
If you run Dgraph yourself, whether in a container, a VM or Kubernetes, you should check which version you have and who can reach port 6080. Coverage so far comes from a single primary source, the GitHub advisory, so treat details beyond it as unconfirmed.
What happened
Dgraph clusters have two kinds of nodes. Alpha nodes serve data, and Zero nodes coordinate the cluster: membership, topology and ID allocation. According to the advisory, Zero registers its administrative HTTP routes directly, with no authentication or IP allow-list wrapper, and the admin interface is enabled by default (the setting disable-admin-http defaults to false).
The exposed routes named in the advisory are /state, /assign, /removeNode and /moveTablet. The NVD-derived description says a remote attacker who can reach the Zero HTTP port can read topology, allocate identifiers, use the moveTablet route or remove cluster membership. That disrupts Zero and can destabilize the Alpha nodes that depend on it.
Technical details
This is a missing-authentication problem rather than a memory bug or a logic trick. The administrative handlers are reachable by design, but nothing checks who is calling. The /removeNode route takes caller-supplied id and group values and passes them to the internal RemoveNode function. For group 0, that function proceeds to propose removal of a peer from the Zero group.
The advisory's author reproduced the impact on a single-node standalone deployment. After one unauthenticated removal request, the Zero HTTP port stopped answering health checks, and Alpha logs repeatedly reported connection refused errors when trying to reach Zero on port 5080. Alpha itself was still locally reachable, but it had lost its control plane. The advisory calls this a practical denial of service against the control plane.
The CVSS v4 vector in the advisory lists network attack vector, low complexity, no privileges and no user interaction. Impact is high for integrity and availability on the vulnerable system, with no confidentiality impact scored, even though the /state route does reveal topology and tablet information.
Who is affected
Exposure depends on network reachability, not just on the version. You are realistically at risk if all of these are true:
- You run Dgraph v25 at version 25.3.8 or earlier.
- The Zero admin HTTP interface is enabled, which is the default.
- Port 6080 on a Zero node is reachable from networks you do not control, for example through a public IP, a permissive cloud security group, an open Kubernetes service or a published container port.
A cluster where 6080 is only reachable from trusted internal hosts is still running vulnerable software, but the attacker would first need a foothold on that network. Do not treat that as a reason to skip the upgrade, since the CVSS rating assumes network access to the port.
How to check your exposure
First, find out which version each node runs. This prints the Dgraph version from the binary on the host or inside the container; look for a version of 25.3.8 or lower.
dgraph versionNext, check whether port 6080 is listening and on which address. This read-only command lists listening TCP sockets on a Linux host; a listener bound to 0.0.0.0 or a public address deserves attention.
ss -tlnp | grep 6080Then test from outside. From a machine on an untrusted network, such as a laptop off your VPN, check whether a TCP connection to port 6080 on your Zero host succeeds. If it does, the admin surface is reachable from there. Also review cloud security groups, firewall rules, Kubernetes services and container port mappings for anything that publishes 6080.
What to do now
0 of 7 done
If you cannot upgrade immediately, the research does not describe an official workaround, so network restriction is the practical stopgap. The advisory notes a disable-admin-http setting that defaults to false. Whether turning it on is a supported mitigation for your setup is not confirmed in the sources, so check the Dgraph documentation and test before relying on it.
Detection and monitoring
Because this is a missing-authentication flaw, there may be no obvious exploit signature. Useful signals to watch for include:
- Repeated connection refused errors in Alpha logs pointing at port 5080 on the Zero host, which is what the advisory observed after the destructive call.
- Zero's health endpoint on port 6080 failing or resetting connections unexpectedly.
- Unexplained changes to cluster membership or topology.
- Access logs from load balancers, reverse proxies or firewalls showing requests to /state, /assign, /removeNode or /moveTablet from unfamiliar addresses.
Set alerts on these, and keep admin ports off the public internet as a standing rule. If you run public-facing services alongside your database, an outside-in check of what ports and services are visible can catch accidental exposure; Webforta Monitor can watch uptime and certificate or DNS changes, and the security guides cover general exposure hygiene. These do not detect this specific flaw.
Timeline
| Date | Event |
|---|---|
| Aug 2, 2026 | Advisory published in the dgraph-io/dgraph repository |
| Oct 14, 2026 | Published by the National Vulnerability Database |
| Oct 15, 2026 | Published and reviewed in the GitHub Advisory Database; last updated |
The research does not give a release date for 25.4.0 or any evidence of attacks in the wild, so neither is stated here.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.