EUVD-2026-77689
GHSA-4vrg-r928-h5vv
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Network API access without required privileges; AC:H captures the four simultaneous conditions and timing-dependent race; integrity limited to incorrect authorization responses with no confidentiality or availability impact.
Primary rating from Vendor (https://github.com/authzed/spicedb).
CVSS VectorVendor: https://github.com/authzed/spicedb
Lifecycle Timeline
2DescriptionCVE.org
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:
- 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
}- A subject reaches the permission via the caveated edge:
document:firstdoc#reader@user:caveatedreader[some_caveat]
document:firstdoc#writer@user:caveatedreader- Your workload issues
LookupResourceswith acontextrequest parameter, concurrently withCheckPermission/CheckBulkPermissionsfor the same subject/resource, and - 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)
AnalysisAI
Authorization bypass in SpiceDB (versions 1.34.0-1.53.x) causes the permission check engine to return unconditional HAS_PERMISSION when the correct response should be CONDITIONAL_PERMISSION, due to a race condition in the dispatch result cache under concurrent API load. Deployments whose schemas combine intersection or exclusion of caveated and non-caveated relation branches are affected when LookupResources (with a context parameter) and CheckPermission or CheckBulkPermissions are issued concurrently for the same subject and resource while the dispatch cache is active. No public exploit has been identified at time of analysis, and all four triggering conditions must simultaneously hold, making this a low-probability but high-consequence authorization integrity issue for systems relying on SpiceDB as an enforcement boundary.
Technical ContextAI
SpiceDB is an open-source, Zanzibar-inspired authorization system written in Go (package github.com/authzed/spicedb). It evaluates permissions through a schema language (Zed) that supports caveated relationships - conditional edges requiring runtime context to resolve. Internally, SpiceDB uses a dispatch result cache (configurable via ClusterDispatchCacheConfig and DispatchCacheConfig) to memoize sub-query results and accelerate concurrent permission checks. CWE-863 (Incorrect Authorization) applies: the root cause is that a LookupResources call carrying a context parameter can write a cache entry that strips or ignores caveat metadata, and a concurrent CheckPermission call for the same (resource, permission, subject) tuple reads that stale unconditional entry, promoting CONDITIONAL_PERMISSION to HAS_PERMISSION. The race window is intermittent and timing-dependent, contingent on goroutine scheduling over the shared cache. Affected Go package: pkg:go/github.com_authzed_spicedb, versions >= 1.34.0 and < 1.54.0.
RemediationAI
Upgrade SpiceDB to v1.54.0 or later, which resolves the race condition in the dispatch result cache; this is the primary and recommended fix per vendor advisory GHSA-4vrg-r928-h5vv (https://github.com/authzed/spicedb/security/advisories/GHSA-4vrg-r928-h5vv). If an immediate upgrade is not possible, disable the dispatch result cache by zeroing out or removing the ClusterDispatchCacheConfig and DispatchCacheConfig settings - this eliminates the race condition entirely by preventing cache reuse across concurrent calls. The trade-off is significant: disabling the cache forces every permission check to be fully recomputed, increasing latency and backend load proportionally to request volume; high-throughput deployments may see substantial performance degradation. This workaround should be treated as a temporary measure only, with upgrade to v1.54.0 as the definitive resolution.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today