Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
16 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Under concurrency, CheckPermission and CheckBulkPermissions can return PERMISSIONSHIPHASPERMISSION for a (resource, permission, subject) whose correct answer is PERMISSIONSHIPCONDITIONALPERMISSION. You are impacted if all of the following hold: 1. 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: 2. A subject reaches the permission via the caveated edge: 3. Your workload issues LookupResources with a context request parameter, concurrently with CheckPermission/CheckBulkPermissions for the same subject/resource, and 4. The dispatch result cache is enabled. When all of the above are true, there is an intermittent window in which: CheckPermission(document:firstdoc, haspermission, user:caveatedreader) → HASPERMISSION (incorrect; should be CONDITIONALPERMISSION) CheckPermission(document:firstdoc, haspermission, user:caveatedreader, context =…
Recommended action: Upgrade to 1.54.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users are impacted if: - They have a caveat structure with a nested list, e.g.: - 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: 1. 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 2. 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…
Recommended action: Upgrade to 1.52.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/authzed/spicedb >= 1.49.0, <= 1.51.0
Fixed in
1.51.1· Vendor fix available
Issue
Impact When SpiceDB starts with log level info, the startup "configuration" log will include the full datastore DSN, including the plaintext password, inside DatastoreConfig.URI. Patches v1.51.1 Workarounds Change the log level to warn or error.
Recommended action: Upgrade to 1.51.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malformed or tampered-with LookupResources Cursor token can cause a panic in the SpiceDB process if it fails to parse. If an attacker were able to make requests to a SpiceDB instance, they could affect its availability. Reproduction If one was to take a cursor from a LookupResources call, decode it according to the logic that SpiceDB uses, and modify the Sections field to include an invalid relationship string, the process will panic. Impact An attacker would need both the ability to create a gRPC connection to your SpiceDB instance and a valid token, or else the ability to pass a cursor token from outside your application through to your SpiceDB instance. If an attacker had this ability, they could bring down SpiceDB instances, reducing the availability of SpiceDB and any service that depends on it. Mechanism The SpiceDB process does not validate the contents of this Sections component of the Cursor message. In affected versions, it uses a parsing function that calls…
Recommended action: Upgrade to 1.49.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If your schema includes the following characteristics: 1. You have a permission defined in terms of a union (+) 1. That union references the same relation on both sides, but one side arrows to a different permission Then you might have missing LookupResources results when checking the permission. This only affects LookupResources; other APIs calculate permissionship correctly. A small concrete example: A CheckPermission on dothething will return the correct permissionship, but a LookupResources on dothething may miss resources. A Comprehensive Example If you have a schema with a structure like this: And these relationships: And you call LookupResources with: You would expect to receive system:somesystem in the results, but you do not. Note that this only applies to LookupResources; if you CheckPermission for that resource specifically, it will return HasPermission. Patches The issue is fixed in v1.47.1. Upgrading to this version will remediate this issue. Workarounds N/A…
Recommended action: Upgrade to 1.47.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users who 1. use the exclusion operator somewhere in their authorization schema 1. have configured their SpiceDB server such that --write-relationships-max-updates-per-call is bigger than 6500 1. issue calls to WriteRelationships with a large enough number of updates that cause the payload to be bigger than what their datastore allows will 1. receive a successful response from their WriteRelationships call, when in reality that call failed, 2. receive incorrect permission check results, if those relationships had to be read to resolve the relation involving the exclusion Patches Upgrade to v.145.2. Workarounds Set --write-relationships-max-updates-per-call to 1000.
Recommended action: Upgrade to 1.45.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact On schemas involving arrows with caveats on the arrow’ed relation, when the path to resolve a CheckPermission request involves the evaluation of multiple caveated branches, requests may return a negative response when a positive response is expected. For example, given this schema: and these relationships: Permission for 'document:budget#read@user:maria with {"actual" : "admin"}' is returned as NOPERMISSION when HASPERMISSION is the correct answer. Patches Upgrade to v1.44.2. Workarounds Do not use caveats in your schema over an arrow’ed relation.
Recommended action: Upgrade to 1.44.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Clients that have enabled LookupResources2 and have caveats in the evaluation path for their requests can return a permissionship of CONDITIONAL with context marked as missing, even then the context was supplied. LookupResources2 is the new default in SpiceDB 1.37.0 and has been opt-in since SpiceDB 1.35.0 Patches The bug will be released as part of SpiceDB 1.37.1 Workarounds Disable LookupResources2 via the --enable-experimental-lookup-resources flag by setting it to false
Recommended action: Upgrade to 1.37.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Background Multiple caveats over the same indirect subject type on the same relation can result in no permission being returned when permission is expected For example, given this schema: If the resource has multiple groups, and each group is caveated, it is possible for the returned permission to be "no permission" when permission is expected. Impact Permission is returned as NOPERMISSION when PERMISSION is expected on the CheckPermission API. Workarounds Do not use caveats or do not use caveats on an indirect subject type with multiple entries
Recommended action: Upgrade to 1.35.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Background Use of an exclusion under an arrow that has multiple resources may resolve to NOPERMISSION when permission is expected. For example, given this schema: If the resource exists under multiple folders and the user has access to view more than a single folder, SpiceDB may report the user does not have access due to a failure in the exclusion dispatcher to request that all the folders in which the user is a member be returned Impact Permission is returned as NOPERMISSION when PERMISSION is expected on the CheckPermission API. Workarounds None
Recommended action: Upgrade to 1.33.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Background Use of a relation of the form: relation folder: folder | folder#parent with an arrow such as folder-view can cause LookupSubjects to only return the subjects found under subjects for either folder or folder#parent. This bug only manifests if the same subject type is used multiple types in a relation, relationships exist for both subject types and an arrow is used over the relation. Impact Any user making a negative authorization decision based on the results of a LookupSubjects request with version before v1.30.1 is affected. Workarounds Avoid using LookupSubjects for negative authorization decisions and/or avoid using the broken schema.
Recommended action: Upgrade to 1.30.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Any SpiceDB cluster with any schema where a resource being checked has more than 65535 relationships for the same resource and subject type is affected by this problem. The issue may also lead to a panic rendering the server unavailable The following API methods are affected: - CheckPermission - BulkCheckPermission - LookupSubjects Impact Permission checks that are expected to be allowed are instead denied, and lookup subjects will return fewer subjects than expected. Workarounds There is no workaround other than making sure that the SpiceDB cluster does not have very wide relations, with the maximum value being the maximum value of an 16-bit unsigned integer Remediations - AuthZed Dedicated customers: No action. AuthZed has upgraded all deployments. - AuthZed Serverless customers: No Action. AuthZed has upgraded all deployments. - AuthZed Enterprise customers: Upgrade to v1.29.2-hotfix-enterprise.v1.hotfix.v1 - Open Source users: Upgrade to v1.29.2
Recommended action: Upgrade to 1.29.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SpiceDB is an open source, Google Zanzibar-inspired database for creating and managing security-critical application permissions. When the provided datastore URI is malformed (e.g. by having a password which contains :) the full URI (including the provided password) is printed, so that the password is shown in the logs. Version 1.27.0-rc1 patches this issue. Example output:
Recommended action: Upgrade to 1.27.0-rc1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/authzed/spicedb >= 1.22.0, <= 1.22.0
Fixed in
1.22.2· Vendor fix available
Issue
Impact Any user making a negative authorization decision based on the results of a LookupResources request with 1.22.0 is affected. For example, using LookupResources to find a list of resources to allow access to be okay: some subjects that should have access to a resource may not. But if using LookupResources to find a list of banned resources instead, then some users that shouldn't have access may. Generally, LookupResources is not and should not be used to gate access in this way - that's what the Check API is for. Additionally, version 1.22.0 has included a warning about this bug since its initial release. Workarounds Avoid using LookupResources for negative authorization decisions if using 1.22.0. Patches The only affected release is v1.22.0, and it is patched in v1.22.2 (there is no v1.22.1 release, though there is a git tag). References - https://github.com/authzed/spicedb/pull/1397 For more information If you have any questions or comments about this advisory: Open an issue…
Recommended action: Upgrade to 1.22.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Background The spicedb serve command contains a flag named --grpc-preshared-key which is used to protect the gRPC API from being accessed by unauthorized requests. The values of this flag are to be considered sensitive, secret data. The /debug/pprof/cmdline endpoint served by the metrics service (defaulting running on port 9090) reveals the command-line flags provided for debugging purposes. If a password is set via the --grpc-preshared-key then the key is revealed by this endpoint along with any other flags provided to the SpiceDB binary. Impact All deployments abiding by the recommended best practices for production usage are NOT affected: - Authzed's SpiceDB Serverless - Authzed's SpiceDB Dedicated - SpiceDB Operator Users configuring SpiceDB via environment variables are NOT affected. Users MAY be affected if they expose their metrics port to an untrusted network and are configuring --grpc-preshared-key via command-line flag. Workarounds To workaround this issue you can do one of…
Recommended action: Upgrade to 1.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Any user making use of a wildcard relationship under the right hand branch of an exclusion or within an intersection operation will see Lookup/LookupResources return a resource as "accessible" if it is not accessible by virtue of the inclusion of the wildcard in the intersection or the right side of the exclusion. For example, given schema: If user: is placed into the banned relation for a particular resource, view should return false for all resources. in v1.3.0, the wildcard is ignored entirely in lookup's dispatch, resulting in the banned wildcard being ignored in the exclusion. Workarounds Don't make use of wildcards on the right side of intersections or within exclusions. References https://github.com/authzed/spicedb/issues/358 For more information If you have any questions or comments about this advisory: Open an issue in SpiceDB Ask a question in the SpiceDB Discord
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.