Neo4j GraphQL Library EUVD-2026-97486

Requires (1) an authenticated user - the CVSS vector specifies PR:L, so the attacker must hold a valid JWT accepted by the API; and (2) the target application must define an @authorization filter that uses the 'none' quantifier on a relationship or connection field (e.g. @authorization(filter: [{ where: { node: { creator: { none: { id: { eq: "$jwt.sub" } } } } } }])). Applications that never use the 'none' quantifier in authorization filters are NOT exploitable. No user interaction is needed and the attack works against default library behavior in affected versions (7.0.0 through 7.6.3). The key limiting factor is this configuration dependency on the 'none' quantifier, which narrows real-world exposure despite the network, low-complexity profile.

This is a genuine authorization-bypass priority rather than a merely inflated CVSS number. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) describes a network-reachable, low-complexity flaw requiring only low privileges (any authenticated API user), and the dual VC:H/VI:H impact is consistent with the description - protected records can be both read and mutated (created/deleted). The root cause is unambiguous and confirmed by the patch diff: the 'none' quantifier was translated to Cypher without the required Cypher.not() negation, so it silently behaved like 'some', inverting every rule that used it. No EPSS score, CISA KEV listing, or public POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the risk signal here comes from exploitation ease and logic certainty, not from observed attacks. One caveat to flag: exploitation is conditional on an application actually using the 'none' quantifier inside an @authorization filter on a relationship or connection - deployments that never use 'none' are not exploitable, so real-world blast radius depends on configuration and is narrower than the raw 8.6 suggests.

An application uses @neo4j/graphql with an @authorization filter such as 'none of the related users matches $jwt.sub' to hide records from denied users. Because 'none' is inverted to 'some', an authenticated attacker simply issues a normal GraphQL query (or mutation) and receives exactly the records the rule was meant to deny - and can likewise create or delete them. No special tooling is needed and complexity is low; no public exploit code was provided in the input.