@neo4j/graphql: authorization relationship and connection filters invert the "none" quantifier
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Neo4j | @neo4j/graphql | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Neo4j | Graphql |
|
Vendor Solution
Upgrade @neo4j/graphql to version 7.6.4 or later.
Vendor Workaround
Avoid the none quantifier in @authorization relationship and connection filters until you can upgrade, and verify any replacement rule with tests that cover both denied and allowed users.
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.313% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Neo4j
Neo4j graphql |
|
| Vendors & Products |
Neo4j
Neo4j graphql |
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | @neo4j/graphql: authorization relationship and connection filters invert the "none" quantifier | |
| Weaknesses | CWE-863 | |
| References |
| |
| Metrics |
cvssV4_0
|