Neo4j GraphQL EUVD-2026-61047

Exploitation requires all four of the following conditions to be simultaneously true: (1) the application runs @neo4j/graphql in a version from 5.2.0 to 5.12.14, 6.0.0 to 6.6.4, or 7.0.0 to 7.5.x; (2) the GraphQL schema defines a type-level @authentication directive on a Query or Mutation type AND at least one field-level @authentication directive on a root custom-resolver field within that same type; (3) the field-level directive enforces a stricter requirement than the type-level directive (e.g., an additional JWT role claim); and (4) the attacker possesses a legitimately issued, correctly signed JWT that satisfies the type-level (coarser) requirement. Applications using only type-level @authentication with no field-level overrides are NOT vulnerable. Applications using only field-level @authentication with no type-level rule are NOT vulnerable. Unauthenticated attackers cannot exploit this - a valid JWT satisfying the type-level check is a hard prerequisite.

The CVSS 4.0 score of 7.6 (High) with vector AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N is a fair representation of actual risk. The two key risk-limiting signals are AT:P (attack requirements present - the vulnerable directive co-occurrence pattern must be in use) and PR:L (a valid, legitimately issued JWT is required). Applications that use type-level @authentication exclusively, or field-level @authentication exclusively, are not affected; only those that combine both scopes on the same type with a stricter field-level rule are vulnerable. No EPSS data was provided in the input, so exploitation probability cannot be quantified numerically. No CISA KEV listing exists and no public exploit code has been identified, indicating no confirmed widespread exploitation. Where the configuration pattern is present, the impact is high on both confidentiality and integrity - authenticated regular users can read sensitive data or invoke privileged write operations with no additional effort. This is a real, actionable priority for Neo4j GraphQL deployments using the affected directive pattern, not a theoretical high-CVSS-low-real-risk issue.

An attacker holds a legitimately issued, correctly signed JWT with roles: ["user"], issued by the application's own identity provider. They identify a GraphQL Mutation type protected by a type-level @authentication rule (which their user token satisfies) that also contains an adminDeleteUser mutation field protected by a field-level @authentication rule requiring roles_INCLUDES: "admin". They send a standard GraphQL mutation request with their user token; the library evaluates the type-level rule (passes), discards the field-level admin check, and executes the privileged mutation. No token forgery, no brute force, and no public exploit code is required.