CVE-2026-55866: SpiceDB: Checks involving relations with caveats can result in unconditional permission when conditional permission is expected
(updated )
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)
References
Code Behaviors & Features
Detect and mitigate CVE-2026-55866 with GitLab Dependency Scanning
Secure your software supply chain by verifying that all open source dependencies used in your projects contain no disclosed vulnerabilities. Dependency Scanning using SBOM also detects vulnerabilities from proprietary advisories that this site does not include. Learn more about Dependency Scanning using SBOM →