Dgraph Zero Admin HTTP API Exposes Unauthenticated Destructive Controls (CVE-2026-102748)

What happened

A GitHub Security Advisory (GHSA-qj98-gp63-54xj) discloses that Dgraph's Zero component exposes administrative HTTP endpoints on port 6080 without authentication by default (disable-admin-http=false). Affected routes include /state, /assign, /removeNode, and /moveTablet. The researcher's published proof-of-concept, run against Dgraph v25.3.8, demonstrates that an unauthenticated caller can read cluster topology via /state, allocate IDs via /assign, and — most seriously — trigger /removeNode?id=1&group=0, which calls into Server.RemoveNode and ProposePeerRemoval. In the reproduced case this broke the Zero control plane and caused the co-located Alpha node to repeatedly fail reconnecting to localhost:5080, producing a denial of service. The advisory tracks this as CVE-2026-102748, with exploit status reported as PoC-public and no CVSS score listed at time of writing.

Why it matters

Dgraph is a distributed graph database, and Zero is its control-plane coordinator responsible for cluster membership, tablet assignment, and timestamp allocation. Any deployment that leaves port 6080 reachable — whether on an internal network, a misconfigured cloud security group, or a container exposed by default — hands an unauthenticated party both read access to cluster metadata and a destructive membership-management primitive. For single-node or small-cluster deployments, the practical effect demonstrated here is a full control-plane outage that cascades to dependent Alpha nodes. Multi-node clusters could plausibly see similar disruption to specific groups, though the advisory's reproduction is on a standalone deployment.

What defenders should watch for now

• Inventory exposure: identify any Dgraph Zero instances reachable on 6080 from untrusted networks, including cloud security groups, Kubernetes services, and container port mappings.
• Network-layer containment: restrict 6080 to trusted hosts/control-plane traffic only via firewall rules or network policies; do not rely on the application layer for authentication until a fix is confirmed.
• Hunting angle: review access/proxy logs and any available Zero/Alpha logs for unauthenticated requests to /state, /assign, /removeNode, or /moveTablet, and for Alpha-side connection errors to its local Zero port (e.g. repeated connect: connection refused entries) that could indicate an in-progress or attempted disruption.
• Check for the disable-admin-http setting and any documented authentication/allow-list options for Zero's HTTP interface once vendor guidance is available, and apply them.
• Treat this as an availability risk first: prioritize isolating the control-plane port over deep forensic response unless active exploitation is observed.

Developing intel

This is a same-day advisory with a public PoC and an assigned CVE (CVE-2026-102748), but no CVSS score has been published and no confirmed in-the-wild exploitation or ransomware use has been reported. Details may evolve as the vendor responds. See the original advisory for authoritative updates: GHSA-qj98-gp63-54xj.