GHSA-vvf7-6rmr-m29q
CRITICALGHSA-vvf7-6rmr-m29q is a critical-severity (CVSS 9.8) vulnerability in github.com/dgraph-io/dgraph/v25. O3 Security confirms whether GHSA-vvf7-6rmr-m29q is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Dgraph: Unauthenticated Admin Token Disclosure Leading to Authentication Bypass via /debug/vars
Real-World Exposure
github.com/dgraph-io/dgraph/v25🐹github.com/dgraph-io/dgraph/v24🐹github.com/dgraph-io/dgraphReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Dgraph v25.3.2 still exposes the process command line through the unauthenticated /debug/vars endpoint on Alpha. Because the admin token is commonly supplied via the --security "token=..." startup flag, an unauthenticated attacker can retrieve that token and replay it in the X-Dgraph-AuthToken header to access admin-only endpoints.
This is a variant of the previously fixed /debug/pprof/cmdline issue, but the current fix is incomplete because it blocks only /debug/pprof/cmdline and still serves http.DefaultServeMux, which includes expvar's /debug/vars handler.
Details
Alpha still exposes Go's default HTTP mux:
x/metrics.go- imports
expvar - initializes
Conf = expvar.NewMap("dgraph_config")
- imports
- Go's
expvarpackage automatically registers/debug/vars expvarpublishes:cmdline = os.Argsmemstats = runtime.Memstats
Alpha's HTTP handler explicitly blocks only the old CVE path:
dgraph/cmd/alpha/run.go- checks
if r.URL.Path == "/debug/pprof/cmdline"and returns404 - otherwise falls through to
http.DefaultServeMux.ServeHTTP(w, r)
- checks
Admin endpoints still trust the leaked token:
dgraph/cmd/alpha/admin.go- reads
X-Dgraph-AuthToken - compares it to
worker.Config.AuthToken
- reads
PoC
- Send an unauthenticated request to Alpha:
GET /debug/vars HTTP/1.1
Host: target:8080
-
Parse the JSON response and read the
cmdlinefield. -
Extract the admin token from the startup arguments, for example:
--security token=debug-vars-secret;
- Replay the token to an admin-only endpoint:
GET /admin/config/cache_mb HTTP/1.1
Host: target:8080
X-Dgraph-AuthToken: debug-vars-secret
- The request is accepted as an authorized admin request.
This was reproduced against dgraph/dgraph:v25.3.2 in Docker.
Observed behavior:
- unauthenticated
/debug/varsleaked the configured token - replaying the leaked token in
X-Dgraph-AuthTokensuccessfully accessed/admin/config/cache_mb - response body was:
4096
It was verified that the old CVE path appears specifically patched in the same version:
/debug/pprof/cmdlinereturned404 Not Found/debug/pprof/remained reachable
Impact
Unauthenticated attackers can obtain the Alpha admin token and gain unauthorized administrative access.
This enables privileged admin operations such as:
- reading privileged admin configuration
- mutating admin configuration
- performing operational control actions gated by
X-Dgraph-AuthToken
In deployments where the Alpha HTTP port is reachable by untrusted parties, this is a practical authentication bypass to admin functionality.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/dgraph-io/dgraph/v25 | all versions | 25.3.3 |
| 🐹Go | github.com/dgraph-io/dgraph/v24 | all versions | No fix |
| 🐹Go | github.com/dgraph-io/dgraph | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/dgraph-io/dgraph/v25. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/dgraph-io/dgraph/v25 to 25.3.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vvf7-6rmr-m29q is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-vvf7-6rmr-m29q is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-vvf7-6rmr-m29q. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vvf7-6rmr-m29q in your dependencies?
O3 detects GHSA-vvf7-6rmr-m29q across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.