Is there a patch available for CVE-2026-46668?

Yes, a patch is available for CVE-2026-46668. Update the affected software to the latest version immediately.

SpiceDB CVE-2026-46668

Q: What is the CVSS score of CVE-2026-46668?

CVE-2026-46668 has a CVSS 4.0 base score of 2.3 (Low). CVSS vector: CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-36122 LOW

Improper Authorization (CWE-285)

2026-05-21 https://github.com/authzed/spicedb

GHSA-mqcf-gqvg-rmhm

Authentication Bypass

2.3

CVSS 4.0 · Vendor: https://github.com/authzed/spicedb

Severity by source

Vendor (https://github.com/authzed/spicedb) PRIMARY

2.3 LOW

CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from Vendor (https://github.com/authzed/spicedb) · only source for this CVE.

CVSS VectorVendor: https://github.com/authzed/spicedb

CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

CVSS changed

Jun 10, 2026 - 22:22 NVD

2.3 (LOW)

Source Code Evidence Fetched

May 21, 2026 - 21:02 vuln.today

Analysis Generated

May 21, 2026 - 21:02 vuln.today

DescriptionCVE.org

Impact

Users are impacted if:

They have a caveat structure with a nested list, e.g.:

zed

  caveat shape(x list<any>) {
    x == [["a"], "b"]
  }

Their system exercises that caveat with either CheckBulkPermission or else LookupResources running with the --experimental-lookup-resources-version flag set to lr3, implying they are using the experimental version 3 of LookupResources
An attacker can cause the system to craft a request to SpiceDB where either:

It's a CheckBulk request where there are two check items that are identical except for their combined caveat context, and one of the caveat contexts evaluates positively and the other evaluates negatively
It's a LookupResources request where two resources have the same evaluation contents except for their caveat context, and one would evaluate positively and the other would evaluate negatively

If all of the above are true, it would be possible for SpiceDB to erroneously return that a user has access to a resource that they do not have access to.

Patches

This problem was addressed in https://github.com/authzed/spicedb/pull/3065 and released in version v1.52.0.

Workarounds

If using v3 of LookupResources, turn the flag off.

If possible, refactor the caveat declaration structure so that it does not operate on a list of lists, but rather any other composite structure.

AnalysisAI

Improper cache key generation in SpiceDB's dispatch layer allows authorization bypass when caveat structures use nested lists. Affected versions (v1.15.0 through v1.51.x) generate colliding cache keys due to non-deterministic serialization of nested list structures in caveat contexts, causing the system to erroneously serve a cached positive authorization result in place of a correct negative one. No public exploit code has been identified at time of analysis, and this vulnerability is not currently listed in the CISA KEV catalog, but exploitation is structurally straightforward for any party with the ability to send crafted CheckBulkPermission or LookupResources requests to a misconfigured deployment.

Technical ContextAI

SpiceDB is an open-source authorization database implementing Google Zanzibar-style relationship-based access control, written in Go (pkg:go/github.com/authzed/spicedb). Its dispatch layer caches intermediate permission evaluation results using computed hash keys derived from request parameters, including caveat context. The root cause (CWE-285: Improper Authorization) lies in the serialization logic for caveat context structs: when a caveat operates on a list<any> containing nested lists (e.g., x == [['a'], 'b']), the old hashableContext implementation used non-deterministic serialization that produced identical hash keys for structurally different caveat contexts. The fix, applied in PR #3065, replaces the ad-hoc hashableContext approach with caveats.StableContextStringForHashing backed by deterministic protobuf serialization, ensuring unique cache keys across distinct contexts. The affected code paths are lookupResourcesRequest2ToKey and lookupResourcesRequest3ToKey in internal/dispatch/keys/computed.go.

RemediationAI

Upgrade SpiceDB to version v1.52.0 or later; this is the vendor-released patch confirmed in GHSA-mqcf-gqvg-rmhm and implemented via https://github.com/authzed/spicedb/pull/3065. If an immediate upgrade is not possible, two workarounds are available: first, if using the experimental LookupResources v3 path, remove or disable the --experimental-lookup-resources-version=lr3 flag to fall back to the stable LookupResources implementation, which eliminates one of the two affected code paths; second, refactor any caveat declarations that use list<any> with nested list values - replacing nested list structures with any other composite type (maps, structs, flat lists) avoids triggering the colliding serialization. Note that the workarounds do not patch the underlying cache key bug; upgrading remains the definitive fix. The advisory is available at https://github.com/authzed/spicedb/security/advisories/GHSA-mqcf-gqvg-rmhm.