The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsUpgrade Chainguard
spicedb
to version 1.33.0-r0 or higher.
Note: Versions mentioned in the description apply only to the upstream spicedb
package and not the spicedb
package as distributed by Chainguard
.
See How to fix?
for Chainguard
relevant fixed versions and status.
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.
All deployments abiding by the recommended best practices for production usage are NOT affected:
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.
TODO
To workaround this issue you can do one of the following:
SPICEDB_GRPC_PRESHARED_KEY=yoursecret spicedb serve
)--metrics-addr
flag to bind to a trusted network (e.g. --metrics-addr=localhost:9090
)--metrics-enabled=false
)We'd like to thank Amit Laish, a security researcher at GE Vernova for responsibly disclosing this vulnerability.