Privilege Escalation via Dropped Field-Level @authentication
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 | graphql | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Neo4j | Graphql |
|
Vendor Solution
Upgrade the library to 7.6.0+ or 5.12.15+. v6 is end-of-life and will not receive a fix. v5 releases prior to 5.2.0 are not affected. For users who cannot upgrade immediately: do not combine a type-level @authentication with a field-level @authentication on the same root operation type. Because the type-level annotation is what shadows the field-level rule, removing it restores correct enforcement — instead apply a complete @authentication directive to each root field individually, including the full stricter rule on the sensitive field. Alternatively, enforce the stricter requirement inside the custom resolver's own code.
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.488% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | Privilege Escalation via Dropped Field-Level @authentication | |
| First Time appeared |
Neo4j
Neo4j graphql |
|
| Weaknesses | CWE-639 | |
| CPEs | cpe:2.3:a:neo4j:graphql:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Neo4j
Neo4j graphql |
|
| References |
| |
| Metrics |
cvssV4_0
|