Search
Search Results (4 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-92682 | 1 Neo4j | 1 Graphql | 2026-10-13 | N/A |
| In @neo4j/graphql versions from 7.0.0 up to but not including 7.6.4, the none quantifier in @authorization filters on relationships and connections is not negated when translated to Cypher, so it behaves like some. A rule such as "none of the related denied users matches the JWT subject" therefore returns exactly the records it was meant to exclude, and excludes those it was meant to return. An authenticated user whom such a rule is meant to deny can read the protected records. This is also the case for mutations, so the impact is that sensitive data could also be created and deleted by users that shouldn't have access according to the typedefs. Fixed in 7.6.4. | ||||
| CVE-2026-92681 | 1 Neo4j | 1 Graphql | 2026-10-13 | N/A |
| In @neo4j/graphql versions up to and including 7.6.3, @authentication directives applied at the schema level or on the Query or Mutation types are silently ignored for top-level fields annotated with @cypher. Only @authentication directives placed directly on the individual fields are enforced. An application that exposes a top-level @cypher field and relies on schema-level or type-level @authentication to protect it allows unauthenticated callers to invoke the field and run the configured Cypher statement with the privileges of the GraphQL service account, which may permit reading and modifying data. Fixed in 7.6.4. | ||||
| CVE-2026-19869 | 1 Neo4j | 1 Graphql | 2026-08-18 | N/A |
| @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. | ||||
| CVE-2026-5423 | 1 Neo4j | 1 Graphql | 2026-08-06 | N/A |
| @neo4j/graphql library versions prior to 7.5.6 fail to verify the authenticity of a client-supplied, pre-decoded JWT object passed through GraphQL subscription connectionParams. As a result, any unauthenticated remote client that can open a GraphQL-over-WebSocket connection can forge arbitrary JWT claims (e.g. sub, roles) in connectionParams.jwt and have them accepted as authenticated identity for the purposes of @authentication and @subscriptionsAuthorization directive evaluation. This allows a fully unauthenticated attacker to receive subscription events that should be restricted to specific authenticated roles/users. Upgrade the library to versions 7.5.6+ or 5.12.14+. v6 is end-of-life and will not receive a fix. | ||||
Page 1 of 1.