CVE-2026-19869: Privilege Escalation via Dropped Field-Level @authentication
@neo4j/graphql from 5.2.0 until the patched versions fails to enforce field-level @authentication rules on root custom-resolver fields when a type-level @authentication rule is also present on the same operation type. When both a type-level @authentication (on Query/Mutation) and a field-level @authentication (on a root custom-resolver field within that type) are declared, only the type-level rule is evaluated and the field-level rule is silently discarded. As a result a stricter per-field requirement — such as an admin-role JWT claim (jwt: { rolesINCLUDES: "admin" }) — is never checked, and any client that satisfies the coarser type-level requirement can invoke the more-restricted field. No token forgery is involved: a legitimately issued, correctly signed non-admin token (e.g. roles: ["user"]) is sufficient.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
@neo4j/graphqlto a version that resolves this vulnerability.Fixed in 7.5.7+ - Upgrade
Upgrade
@neo4j/graphqlto a version that resolves this vulnerability.Fixed in 5.12.15+ - Configuration
If you cannot upgrade, do not declare both a type-level @authentication (on Query/Mutation) and a field-level @authentication on a root custom-resolver field for the same operation type.
@neo4j/graphql GraphQL @authentication directives on root operation type = Do not combine type-level and field-level @authentication for the same root operation type - Configuration
To restore correct enforcement, remove the type-level @authentication and apply a full @authentication directive to each root field individually, including the complete stricter rule on the sensitive field (e.g., jwt claim requirements such as roles_INCLUDES: "admin").
GraphQL schema (@neo4j/graphql) Root custom-resolver field @authentication = Apply a complete @authentication directive to each root field individually
Event History
Frequently Asked Questions
Which applications are affected?
Applications using @neo4j/graphql versions starting at 5.2.0 are exposed if they define both a type-level @authentication rule on Query or Mutation and a field-level @authentication rule on a root custom-resolver field in that same operation type. The practical impact is greatest where the field-level rule is intended to restrict sensitive resolver operations more tightly than the type-level rule.
What access does an attacker need to exploit this?
An attacker needs a legitimately issued, correctly signed token that satisfies the broader type-level authentication rule. They do not need to forge a token or possess the stricter claim required by the field-level rule, such as an admin role.
How can I determine whether a sensitive resolver may already be accessible?
The stricter field-level rule is silently discarded in the affected configuration, so a client meeting the type-level requirement can invoke the restricted root custom-resolver field. For example, a token with roles: ["user"] may be able to call a field intended to require roles: ["admin"].