Skip to content

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

Low severity GitHub Reviewed Published Jun 19, 2026 in authzed/spicedb • Updated Jun 19, 2026

Package

gomod github.com/authzed/spicedb (Go)

Affected versions

>= 1.34.0, < 1.54.0

Patched versions

1.54.0

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)

References

@miparnisari miparnisari published to authzed/spicedb Jun 19, 2026
Published to the GitHub Advisory Database Jun 19, 2026
Reviewed Jun 19, 2026
Last updated Jun 19, 2026

Severity

Low

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

EPSS score

Weaknesses

Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. Learn more on MITRE.

CVE ID

CVE-2026-55866

GHSA ID

GHSA-4vrg-r928-h5vv

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.