{"id":"CVE-2026-19869","aliases":["EUVD-2026-61047","GHSA-82m8-p9px-c3x5"],"status":"published","title":"Privilege Escalation via Dropped Field-Level @authentication","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.","severity":{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00488,"percentile":0.42361,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-639"],"published":"2026-08-18T16:35:19Z","modified":"2026-10-28T02:30:48Z","products":[{"vendor":"@tinacms","product":"graphql"},{"vendor":"neo4j","product":"graphql"}],"references":[{"url":"https://github.com/neo4j/graphql/security/advisories/GHSA-82m8-p9px-c3x5","tags":["third-party-advisory","advisory"]},{"url":"https://neo4j.com/security/CVE-2026-19869","tags":["vendor-advisory","advisory"]},{"url":"https://registry.npmjs.org","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/19xxx/CVE-2026-19869.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-19869","tags":["advisory"]},{"url":"https://github.com/neo4j/graphql","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-19869","title":"Privilege Escalation via Dropped Field-Level @authentication","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.","status":"published","published":"2026-08-18T16:35:19.878Z","modified":"2026-08-19T16:02:04.528Z","cvss":[{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high","assessor":"cna"}],"cwes":["CWE-639"],"updated_at":"2026-11-02T13:47:17.512524Z"}],"euvd":[{"id":"EUVD-2026-61047","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.","status":"published","published":"2026-08-18T16:35:19Z","modified":"2026-08-19T16:02:04Z","cvss":[{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T18:01:44.550802Z"}],"nvd":[{"id":"CVE-2026-19869","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.","status":"published","published":"2026-08-18T17:16:57.227Z","modified":"2026-10-22T22:10:00.25Z","cvss":[{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"}],"cwes":["CWE-639"],"updated_at":"2026-11-02T14:12:38.976695Z"}],"osv":[{"id":"CVE-2026-19869","title":"Privilege Escalation via Dropped Field-Level @authentication","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.","status":"published","published":"2026-08-18T16:35:19.878Z","modified":"2026-10-28T02:30:48.525804548Z","cvss":[{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-639"],"updated_at":"2026-11-02T15:44:58.024074Z"}]}}