SpiceDB is an open source database for scalably storing and querying fine-grained authorization data. Starting in version 1.35.0 and prior to version 1.37.1, 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. The bug is patched as part of SpiceDB 1.37.1. As a workaround, disable LookupResources2 via the `--enable-experimental-lookup-resources` flag by setting it to `false`.

spicedb is an Open Source, Google Zanzibar-inspired permissions database to enable fine-grained authorization for customer applications. Multiple caveats over the same indirect subject type on the same relation can result in no permission being returned when permission is expected. 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. Permission is returned as NO_PERMISSION when PERMISSION is expected on the CheckPermission API. This issue has been addressed in release version 1.35.3. Users are advised to upgrade. Users unable to upgrade should not use caveats or avoid the use of caveats on an indirect subject type with multiple entries.

Spicedb is an Open Source, Google Zanzibar-inspired permissions database to enable fine-grained authorization for customer applications. Use of an exclusion under an arrow that has multiple resources may resolve to `NO_PERMISSION` when permission is expected. 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. Permission is returned as `NO_PERMISSION` when `PERMISSION` is expected on the `CheckPermission` API. This issue has been addressed in version 1.33.1. All users are advised to upgrade. There are no known workarounds for this issue.

SpiceDB is a graph database purpose-built for storing and evaluating access control data. 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. Any user making a negative authorization decision based on the results of a LookupSubjects request with version before v1.30.1 is affected. Version 1.30.1 contains a patch for the issue. As a workaround, avoid using LookupSubjects for negative authorization decisions and/or avoid using the broken schema.

SpiceDB is an open source, Google Zanzibar-inspired database for creating and managing security-critical application permissions. Integer overflow in chunking helper causes dispatching to miss elements or panic. 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 CheckPermission, BulkCheckPermission, and LookupSubjects API methods are affected. This vulnerability is fixed in 1.29.2.

SpiceDB is an open source, Google Zanzibar-inspired database for creating and managing security-critical application permissions. Prior to version 1.27.0-rc1, 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.

SpiceDB is an open source, Google Zanzibar-inspired, database system for creating and managing security-critical application permissions. 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 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. Users are advised to upgrade to version 1.22.2. Users unable to upgrade should avoid using `LookupResources` for negative authorization decisions.

SpiceDB is an open source, Google Zanzibar-inspired, database system for creating and managing security-critical application permissions. 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. This issue has been fixed in version 1.19.1. ### 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. ### Patches TODO ### Workarounds To workaround this issue you can do one of the following: - Configure the preshared key via an environment variable (e.g. `SPICEDB_GRPC_PRESHARED_KEY=yoursecret spicedb serve`) - Reconfigure the `--metrics-addr` flag to bind to a trusted network (e.g. `--metrics-addr=localhost:9090`) - Disable the metrics service via the flag (e.g. `--metrics-enabled=false`) - Adopt one of the recommended deployment models: [Authzed's managed services](https://authzed.com/pricing) or the [SpiceDB Operator](https://github.com/authzed/spicedb-operator) ### References - [GitHub Security Advisory issued for SpiceDB](https://github.com/authzed/spicedb/security/advisories/GHSA-cjr9-mr35-7xh6) - [Go issue #22085](https://github.com/golang/go/issues/22085) for documenting the risks of exposing pprof to the internet - [Go issue #42834](https://github.com/golang/go/issues/42834) discusses preventing pprof registration to the default serve mux - [semgrep rule go.lang.security.audit.net.pprof.pprof-debug-exposure](https://semgrep.dev/r?q=go.lang.security.audit.net.pprof) checks for a variation of this issue ### Credit We'd like to thank Amit Laish, a security researcher at GE Vernova for responsibly disclosing this vulnerability.

SpiceDB is a database system for managing security-critical application permissions. 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. In `v1.3.0`, the wildcard is ignored entirely in lookup's dispatch, resulting in the `banned` wildcard being ignored in the exclusion. Version 1.4.0 contains a patch for this issue. As a workaround, don't make use of wildcards on the right side of intersections or within exclusions.