Neo4J Graphql
Monthly
Schema-level and Query/Mutation type-level @authentication directives are silently ignored for top-level @cypher fields in @neo4j/graphql versions up to and including 7.6.3, letting unauthenticated remote callers invoke those fields and run the embedded Cypher statements with the GraphQL service account's privileges, which may permit reading and modifying data. Only @authentication placed directly on the individual @cypher field is enforced, so applications relying on schema- or type-level protection are exposed while those annotating each field individually are not. No public exploit code has been identified at time of analysis, and the vendor has released 7.6.4 as the fix.
Authorization bypass in @neo4j/graphql 7.0.0 through 7.6.3 lets an authenticated user read, create, and delete records that @authorization filter rules were written to deny, because the library translates the 'none' quantifier on relationship and connection filters into Cypher without the required negation so the predicate is evaluated as though it were 'some'. The flaw only manifests in applications whose typedefs actually use the 'none' quantifier inside an @authorization filter on a relationship or connection field (for example creator: { none: { id: { eq: "$jwt.sub" } } }), so applications that never use that construct are not affected; the CVSS vector specifies PR:L, meaning the attacker must hold a valid JWT accepted by the API. No confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; a vendor patch and the upstream fix commit are available.
Schema-level and Query/Mutation type-level @authentication directives are silently ignored for top-level @cypher fields in @neo4j/graphql versions up to and including 7.6.3, letting unauthenticated remote callers invoke those fields and run the embedded Cypher statements with the GraphQL service account's privileges, which may permit reading and modifying data. Only @authentication placed directly on the individual @cypher field is enforced, so applications relying on schema- or type-level protection are exposed while those annotating each field individually are not. No public exploit code has been identified at time of analysis, and the vendor has released 7.6.4 as the fix.
Authorization bypass in @neo4j/graphql 7.0.0 through 7.6.3 lets an authenticated user read, create, and delete records that @authorization filter rules were written to deny, because the library translates the 'none' quantifier on relationship and connection filters into Cypher without the required negation so the predicate is evaluated as though it were 'some'. The flaw only manifests in applications whose typedefs actually use the 'none' quantifier inside an @authorization filter on a relationship or connection field (for example creator: { none: { id: { eq: "$jwt.sub" } } }), so applications that never use that construct are not affected; the CVSS vector specifies PR:L, meaning the attacker must hold a valid JWT accepted by the API. No confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; a vendor patch and the upstream fix commit are available.