Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-09-14T18:17:56.150Z",
  "pubdate": "2026-09-14T18:17:56.150Z",
  "executiveSummary": "A critical cache poisoning vulnerability exists in SpiceDB versions 1.34.0 through 1.54.0, where incorrect cache key generation leads to unauthorized permission grants.\nThe vulnerability allows the system to erroneously return a 'PERMISSIONSHIP_HAS_PERMISSION' response instead of the correct 'PERMISSIONSHIP_CONDITIONAL_PERMISSION' or 'PERMISSIONSHIP_NO_PERMISSION' states.\nThis occurs because the dispatch cache keys generated by checkRequestToKey() and checkRequestToKeyWithCanonical() fail to incorporate CheckHints, causing different authorization states to collide within the cache.\nAn attacker can exploit this condition to gain unauthorized access to resources if they can trigger a race condition between concurrent LookupResources and CheckPermission operations, specifically involving complex intersection or exclusion relations.\nThe impact is significant, as it permits unauthorized access to security-critical resources by bypassing required caveats.\nExploitation requires specific environmental conditions, including a multi-tenant or complex permission schema utilizing caveated and non-caveated relations alongside an active dispatch cache.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper construction of dispatch cache keys within internal/dispatch/keys/computed.go. Specifically, the functions checkRequestToKey() and checkRequestToKeyWithCanonical() omit the CheckHints associated with authorization requests when generating lookup keys for the dispatch result cache.\nIn SpiceDB, CheckHints are essential for distinguishing between permission checks that rely on different evaluation contexts, particularly those involving caveats. By omitting these hints, the cache key becomes insufficiently unique for requests that are semantically distinct but structurally similar.\nThe exploit flow requires a complex set of preconditions. First, the permission model must utilize intersection or exclusion relations. Second, there must be a subject reachable via both caveated and non-caveated branches. Third, the attacker must initiate a LookupResources call with a context parameter while simultaneously executing a CheckPermission or CheckBulkPermissions request for the same resource and subject.\nWhen the dispatch result cache is enabled, the concurrent execution allows the result of a cache-filling operation initiated by one request to be stored under an ambiguous key. A subsequent request, which should have been restricted by a caveat, hits the poisoned cache entry and retrieves the 'PERMISSIONSHIP_HAS_PERMISSION' result intended for an un-caveated path. This effectively short-circuits the authorization logic, allowing the system to grant access without satisfying the underlying caveat constraints.\nThis vulnerability effectively violates the integrity of the authorization engine, as the cache acts as a single source of truth for the dispatch layer. Because the dispatch layer is central to SpiceDB's permission evaluation process, a collision in the cache bypasses the security policy for that specific resource-subject pairing until the cache entry is evicted or invalidated.\nAffected versions are 1.34.0 up to, but not including, 1.54.0. The vulnerability does not require prior authentication to the underlying database, but the attacker must be able to trigger permission checks that interact with the vulnerable code paths in a multi-tenant or shared cache environment."
}