CVE-2026-44840 is a high-severity (CVSS 7.5) CWE-943 vulnerability in github.com/dgraph-io/dgraph/v25. A fix is available for github.com/dgraph-io/dgraph/v25 — see the affected versions and patch details below.
Dgraph Vulnerable to DQL Injection via checkUserPassword GraphQL Query
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-44840.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-44840 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 383,485 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/dgraph-io/dgraph/v25Real-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
The checkUserPassword GraphQL query in Dgraph is vulnerable to DQL (Dgraph Query Language) injection. User-supplied password values are interpolated directly into a DQL checkpwd() query via fmt.Sprintf without any escaping or parameterization. An attacker can inject a password containing a double-quote character to break out of the DQL string literal and append arbitrary DQL query blocks.
Details
Vulnerable Code Path
The vulnerability exists in the GraphQL-to-DQL query rewriting layer:
-
query_rewriter.go(~line 364) — Thecheckpwd()DQL function is constructed usingfmt.Sprintf:fmt.Sprintf(`checkpwd(User.password, "%s")`, password)The raw password string from the GraphQL query input is embedded directly into the DQL query without escaping double quotes or other special characters.
-
graphquery.go— The constructed query attribute is serialized into the final DQL string viab.WriteString(query.Attr), passing the unsanitized content directly to the Dgraph query engine.
Attack Mechanism
A password value containing a double-quote (") terminates the string literal in the checkpwd() function. Any content after the escaped quote is parsed as additional DQL, allowing the attacker to inject arbitrary query blocks.
Distinction from CVE-2026-41328 and CVE-2026-41327
CVE-2026-41328 and CVE-2026-41327 address DQL injection in edgraph/server.go, where GraphQL mutation inputs (upsert/delete) are embedded unsafely into DQL mutations. Those fixes sanitize the mutation path.
This vulnerability is in a completely different code path — the GraphQL query rewriter (query_rewriter.go → graphquery.go). The checkUserPassword GraphQL query triggers a DQL query via checkpwd(), and this query construction was not covered by the patches for CVE-2026-41328/CVE-2026-41327.
PoC
curl -s -X POST http://TARGET:8080/graphql \
-H "Content-Type: application/json" \
-d '{ "query": "query { checkUserPassword(name: \"admin\", password: \"x\\\") { uid } injected(func: has(User.name)) { User.name User.email } dummy(func: eq(x, \\\"x\") { msg } }") { msg } }" }'
What to observe:
- The
touched_uidsfield in theextensionssection of the response will be elevated (indicating the injected blocks executed) - Dgraph server logs (
dgraph alphaoutput) will show the injected query blocks being parsed and executed - The response itself may be filtered by the GraphQL layer, but server-side execution is confirmed
Impact
- Data enumeration: Injected query blocks execute server-side and can probe for the existence of predicates, types, and nodes via
touched_uidsmetrics and server logs. - Schema discovery: An attacker can enumerate all predicates and types in the database by injecting
schema {}blocks orhas()queries. - Resource exhaustion: Expensive injected queries (recursive traversals, large aggregations) execute at the DQL layer, consuming server resources regardless of whether results are returned to the attacker.
- Potential data disclosure: Depending on Dgraph configuration (e.g., debug mode, custom extensions), injected query results may leak into the response.
CVSS 3.1: 7.5 High — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
- Network-accessible via any GraphQL endpoint
- No authentication required (
checkUserPasswordis an unauthenticated query) - Low attack complexity (single crafted HTTP request)
- High confidentiality impact (server-side query execution confirmed, data enumeration possible)
Affected Versions
All versions of Dgraph that include GraphQL support with the @secret directive are affected:
- <= v25.3.3
- Any version where
query_rewriter.goconstructscheckpwd()via string interpolation
Suggested Fix
Escape or parameterize the password value before embedding it in the DQL query. At minimum, double-quote characters in the password must be escaped:
// Before (vulnerable):
fmt.Sprintf(`checkpwd(User.password, "%s")`, password)
// After (escaped):
escaped := strings.ReplaceAll(password, `\`, `\\`)
escaped = strings.ReplaceAll(escaped, `"`, `\"`)
fmt.Sprintf(`checkpwd(User.password, "%s")`, escaped)
Ideally, Dgraph should implement parameterized query support for the checkpwd() function to avoid string interpolation entirely, consistent with best practices for injection prevention.
Credit
Kai Aizen ([email protected])
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/dgraph-io/dgraph/v25 | all versions | 25.3.4go get github.com/dgraph-io/dgraph/v25@v25.3.4 |
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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/dgraph-io/dgraph/v25 to 25.3.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-44840 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Frequently Asked Questions
Is CVE-2026-44840 in your dependencies?
Find it across Go, including transitive dependencies.