Vulnerabilities (CVE)

Filtered by vendor Authzed Subscribe
Filtered by product Spicedb
Total 4 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2023-46255 1 Authzed 1 Spicedb 2023-12-10 N/A 6.5 MEDIUM
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.
CVE-2023-35930 1 Authzed 1 Spicedb 2023-12-10 N/A 5.3 MEDIUM
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.
CVE-2023-29193 1 Authzed 1 Spicedb 2023-12-10 N/A 7.5 HIGH
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.
CVE-2022-21646 1 Authzed 1 Spicedb 2023-12-10 5.5 MEDIUM 8.1 HIGH
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.