CVE-2026-55866
LowCVSS 3.7Summary
SpiceDB from 1.34.0 until 1.54.0 can return PERMISSIONSHIP_HAS_PERMISSION instead of PERMISSIONSHIP_CONDITIONAL_PERMISSION or PERMISSIONSHIP_NO_PERMISSION because checkRequestToKey() and checkRequestToKeyWithCanonical() in internal/dispatch/keys/computed.go omit CheckHints when constructing dispatch Check cache keys. A result computed for one hint set can poison the cache entry used by a semantically different authorization check.
Risk Assessment
Permissions may be granted without satisfying the caveat, violating the application's security model. Exploitation requires a specific combination of permissions, concurrent operations, and an enabled result cache.
Recommendation
Update SpiceDB to version 1.54.0. Until then, consider disabling the dispatch result cache or avoiding concurrent LookupResources and CheckPermission for the same resources.
Other vulnerabilities in SpiceDB
See all- CVE-2026-46668Low
In SpiceDB from version 1.15.0 to before 1.52.0, caveat structures with nested lists can result in improper cache reuse. This issue has been patched in version 1.52.0.
- CVE-2023-35930Low
SpiceDB, a Google Zanzibar-inspired database system, has an issue with negative authorization decisions using the `LookupResources` request in version 1.22.0. Users may incorrectly gain access to resources that should be blocked.
Original NVD description (English source)
SpiceDB is an open source database system for creating and managing security-critical application permissions. From 1.34.0 until 1.54.0, SpiceDB can return PERMISSIONSHIP_HAS_PERMISSION instead of PERMISSIONSHIP_CONDITIONAL_PERMISSION or PERMISSIONSHIP_NO_PERMISSION because checkRequestToKey() and checkRequestToKeyWithCanonical() in internal/dispatch/keys/computed.go omit CheckHints when constructing dispatch Check cache keys. The incorrect result requires a permission combining relations with intersection or exclusion, a subject reachable through caveated and non-caveated branches, LookupResources with a context parameter running concurrently with CheckPermission or CheckBulkPermissions for the same resource and subject, and an enabled dispatch result cache. Under these conditions, a result computed for one hint set can poison the cache entry used by a semantically different authorization check, allowing permission without satisfying the caveat. This issue is fixed in version 1.54.0.

