CVE-2026-55866: SpiceDB: Checks involving relations with caveats can result in unconditional permission when conditional permission is expected ### Impact Under concurrency…

SpiceDB: Checks involving relations with caveats can result in unconditional permission when conditional permission is expected

### 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:

1. 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:

```zed
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
}
```

2. A subject reaches the permission via the caveated edge:

```
document:firstdoc#reader@user:caveatedreader[some_caveat]
document:firstdoc#writer@user:caveatedreader
```
3. Your workload issues `LookupResources` with a `context` request parameter, concurrently with `CheckPermission/CheckBulkPermissions` for the same subject/resource, and
4. 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`)

Affected