GHSA-4vrg-r928-h5vvLowCVSS 3.7

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

Published
June 19, 2026
Last Modified
June 19, 2026

🔗 CVE IDs covered (1)

📋 Description

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

🎯 Affected products1

  • go/github.com/authzed/spicedb:>= 1.34.0, < 1.54.0

🔗 References (2)