CVE-2026-92682 in graphql
Summary
by MITRE • 10/12/2026
In @neo4j/graphql versions from 7.0.0 up to but not including 7.6.4, the none quantifier in @authorization filters on relationships and connections is not negated when translated to Cypher, so it behaves like some. A rule such as "none of the related denied users matches the JWT subject" therefore returns exactly the records it was meant to exclude, and excludes those it was meant to return. An authenticated user whom such a rule is meant to deny can read the protected records. This is also the case for mutations, so the impact is that sensitive data could also be created and deleted by users that shouldn't have access according to the typedefs. Fixed in 7.6.4.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in Neo4j GraphQL versions ranging from 7.0.0 up to but not including 7.6.4 represents a critical logic error within the authorization engine that governs access control for graph data. This flaw specifically affects the handling of quantifiers used in @authorization filters, particularly when applied to relationships and connections between nodes. The core technical issue lies in the translation process where GraphQL directives are converted into Cypher queries, which is the native query language for Neo4j databases. During this transformation, the none quantifier, designed to enforce negative constraints by ensuring that no related entities match a specified condition, fails to apply proper logical negation. Consequently, the system incorrectly interprets these filters as some quantifiers, which require only one matching entity rather than zero matches. This fundamental misinterpretation inverts the intended security logic of the authorization rules defined in the schema definitions.
From an operational perspective, this defect leads to a severe bypass of access controls that are supposed to restrict data visibility and mutability based on user attributes or roles. When a rule is configured to deny access if any related denied users match a specific criterion, such as a JWT subject claim, the flawed logic causes the system to return records that should have been excluded while simultaneously excluding those that were meant to be accessible. This inversion means that authenticated users who are explicitly intended to be denied permission can successfully read protected data. The impact extends beyond simple information disclosure; because mutations are also affected by this same logical error, unauthorized actors can create new nodes and relationships or delete existing ones in violation of the defined type definitions. This compromises both the confidentiality and integrity aspects of the CIA triad, allowing malicious users to manipulate sensitive graph structures that should remain immutable or invisible to them.
The security implications align closely with CWE-285, Improper Authorization, as the application fails to enforce proper access controls when determining user permissions for specific resources. Furthermore, this vulnerability facilitates unauthorized data access and modification, which corresponds to ATT&CK technique T1078, Valid Accounts, where attackers leverage legitimate credentials to bypass security mechanisms due to misconfigured or flawed authorization logic. The ability to read sensitive records constitutes an information disclosure risk, while the capacity to create and delete data introduces significant integrity risks that could lead to further exploitation chains such as privilege escalation or denial of service through data corruption.
To mitigate this vulnerability, organizations running Neo4j GraphQL must immediately upgrade their dependencies to version 7.6.4 or later, where the translation logic for quantifiers has been corrected to properly negate none conditions. In environments where immediate upgrading is not feasible due to compatibility constraints, temporary mitigations should focus on reviewing authorization rules that rely heavily on relationship-based negation filters. Developers can implement additional validation layers at the application level to double-check access decisions before executing Cypher queries, although this approach increases complexity and may impact performance. It is also recommended to audit existing GraphQL schemas for any @authorization directives using none quantifiers on relationships or connections and verify that no sensitive data has been exposed or altered during the window of vulnerability exposure. Regular security assessments and penetration testing focusing on authorization bypasses are essential to ensure that such logic errors do not persist in custom implementations or extended modules built upon this library.