authzed/spicedb · Security
SpiceDB: Checks involving relations with caveats can result in unconditional permission when conditional permission is expected
- GHSA ID
- GHSA-4vrg-r928-h5vv
- CVE ID
- CVE-2026-55866
- Severity
- low
- Published
- Updated
- CVSS
- 3.7 · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
- CVSS v3
- 3.7 · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Description
Impact
Under concurrency, CheckPermission and CheckBulkPermissions can return PERMISSIONSHIP_HAS_PERMISSION for a (resource, permission, subject) whose correct answer is PERMISSIONSHIP_CONDITIONAL_PERMISSION.
You are impacted if all of the following hold:
- Your schema has a permission combining relations with an intersection or exclusion, where a subject reaches it through a caveated branch and a non-caveated branch. For example:
definition user {}
caveat some_caveat(somecondition int) { somecondition == 42 }
definition document {
relation reader: user | user with some_caveat
relation writer: user
relation banned: user
permission has_permission = (reader & writer) - banned
}
- A subject reaches the permission via the caveated edge:
document:firstdoc#reader@user:caveatedreader[some_caveat]
document:firstdoc#writer@user:caveatedreader
- Your workload issues
LookupResourceswith acontextrequest parameter, concurrently withCheckPermission/CheckBulkPermissionsfor the same subject/resource, and - The dispatch result cache is enabled.
When all of the above are true, there is an intermittent window in which:
CheckPermission(document:firstdoc, has_permission, user:caveatedreader) → HAS_PERMISSION (incorrect; should be CONDITIONAL_PERMISSION)
CheckPermission(document:firstdoc, has_permission, user:caveatedreader, context = {"somecondition": 41}) → HAS_PERMISSION (incorrect; should be NO_PERMISSION)
Patches
v1.54.0
Workarounds
Disable the dispatch result cache (ClusterDispatchCacheConfig and DispatchCacheConfig)
CWEs
- CWE-863 · Incorrect Authorization