CyberRota Analysis
AI-GeneratedThe vulnerability affects the @neo4j/graphql library versions 5.2.0 and later, where field-level @authentication rules on root custom-resolver fields are not enforced when a type-level @authentication rule is also present. This oversight allows clients with less restrictive tokens to access sensitive fields that should require stricter authentication, potentially leading to unauthorized data access. Organizations using this library, especially those handling sensitive data or requiring strict access controls, should prioritize applying the latest patches to mitigate this risk.
Public Exploit Signal
A public exploit, PoC, GitHub repository or Metasploit reference was detected for this CVE.
Note: these links are listed for security research and verification purposes only.
Original NVD Description
@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: { roles_INCLUDES: "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.