### 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`)
### 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`)
Update github.com/authzed/spicedb to 1.54.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanSpiceDB: Checks involving relations with caveats can result in unconditional permission when conditional permission is expected affects github.com/authzed/spicedb (go). Severity is low. ### 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`)
AI coding agents often install or upgrade packages automatically in go. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/authzed/spicedbgo | >=1.34.0,<1.54.0 | 1.54.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/authzed/spicedb to 1.54.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanSpiceDB: Checks involving relations with caveats can result in unconditional permission when conditional permission is expected affects github.com/authzed/spicedb (go). Severity is low. ### 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`)
AI coding agents often install or upgrade packages automatically in go. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/authzed/spicedbgo | >=1.34.0,<1.54.0 | 1.54.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard