Neo4j GraphQL CVE-2026-92681

Exploitable only when ALL of the following hold: the application uses @neo4j/graphql ≤7.6.3; it defines a top-level field (on the Query or Mutation type) annotated with @cypher; and it relies on a schema-level or Query/Mutation type-level @authentication directive to protect that field. The decisive limiting factor is that @authentication placed DIRECTLY on the individual @cypher field IS enforced correctly - so applications that annotate fields individually are not affected. Impact is further bounded by whatever Cypher statements are configured and by the privileges of the GraphQL service account. No user interaction or authentication is required to trigger the flaw against a qualifying configuration (PR:N/UI:N).

This is a genuine high-priority issue, not a CVSS-inflated one. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H) is internally consistent with the description: an unauthenticated network attacker can invoke a top-level @cypher field and execute arbitrary configured Cypher with the service account's privileges, yielding high confidentiality and integrity impact (VA:N - no direct availability impact claimed). The root cause (CWE-306, Missing Authentication) is confirmed by the vendor advisory GHSA-8xj4-8gg9-fx9h and the patch commit, which adds schema- and type-level @authentication enforcement to top-level @cypher resolution. No EPSS score, KEV listing, or POC is present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the risk is driven by severity and ease of exploitation rather than observed in-the-wild activity. One important caveat: real-world exploitability is conditional (see exploitation_conditions) - only applications that protect a top-level @cypher field via schema-level or type-level @authentication (rather than field-level) are vulnerable, so the theoretical 9.3 does not apply to every deployment of the library.

An application exposes a top-level @cypher Query or Mutation field and relies on a schema-level or type-level @authentication directive to restrict it to logged-in users. Because that directive is silently ignored for @cypher fields in versions ≤7.6.3, an unauthenticated attacker simply sends the GraphQL query/mutation with no token and the service executes the configured Cypher under its own account, reading or modifying graph data. No public exploit code is identified in the supplied data, but the attack requires only a crafted GraphQL request (AV:N/AC:L/PR:N/UI:N).