SpiceDB CVE-2026-55866
LOW
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 GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Lifecycle Timeline
2DescriptionGitHub Advisory
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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | All four of the following conditions must simultaneously hold: (1) The SpiceDB schema must define a permission using intersection (&) or exclusion (-) that combines a caveated relation branch with a non-caveated branch - for example, permission has_permission = (reader & writer) - banned, where the reader relation permits both plain users and users with a caveat. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The vendor-assigned CVSS 3.1 base score of 3.7 (Low) reflects high attack complexity (AC:H) from the four concurrent conditions required and a network-accessible vector (AV:N) with no privilege requirement (PR:N). … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A subject who holds a caveated relationship to a resource (e.g., user:caveatedreader with reader access gated on somecondition == 42) triggers concurrent API calls: a LookupResources request with a context parameter alongside a CheckPermission call for the same document and subject. During the race window, the dispatch cache stores an unconditional HAS_PERMISSION result sourced from the LookupResources code path; the concurrent CheckPermission reads that stale entry and returns HAS_PERMISSION even when the caller supplies context where somecondition = 41, which should yield NO_PERMISSION. … |
| Remediation | 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). … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today