Most recent entries from all

EUVD-2026-368090

fkie_cve-2026-55866

SpiceDB is an open source database system for creating and managing security-critical application permissions. From 1.34.0 until 1.54.0, SpiceDB can return PERMISSIONSHIP_HAS_PERMISSION instead of PERMISSIONSHIP_CONDITIONAL_PERMISSION or PERMISSIONSHIP_NO_PERMISSION because checkRequestToKey() and checkRequestToKeyWithCanonical() in internal/dispatch/keys/computed.go omit CheckHints when constructing dispatch Check cache keys. The incorrect result requires a permission combining relations with intersection or exclusion, a subject reachable through caveated and non-caveated branches, LookupResources with a context parameter running concurrently with CheckPermission or CheckBulkPermissions for the same resource and subject, and an enabled dispatch result cache. Under these conditions, a result computed for one hint set can poison the cache entry used by a semantically different authorization check, allowing permission without satisfying the caveat. This issue is fixed in version 1.54.0.

GHSA-4vrg-r928-h5vv — SpiceDB: Checks involving relations with caveats can result in unconditional permission when conditional permission is…

Affected: Go: github.com/authzed/spicedb

### 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; shoul…