PT-2026-51121 · Go · Github.Com/Authzed/Spicedb

Published

2026-06-19

·

Updated

2026-06-19

·

CVE-2026-55866

CVSS v3.1

3.7

Low

VectorAV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

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
 }
  1. A subject reaches the permission via the caveated edge:
 document:firstdoc#reader@user:caveatedreader[some caveat]
 document:firstdoc#writer@user:caveatedreader
  1. Your workload issues LookupResources with a context request parameter, concurrently with CheckPermission/CheckBulkPermissions for the same subject/resource, and
  2. 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)

Fix

Incorrect Authorization

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-863

Related Identifiers

CVE-2026-55866
GHSA-4VRG-R928-H5VV

Affected Products

Github.Com/Authzed/Spicedb