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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go zotregistry.dev/zot < 1.4.4-0.20250522160828-8a99a3ed231f
Fixed in
1.4.4-0.20250522160828-8a99a3ed231f· Vendor fix available
Issue
When using Keycloak as an oidc provider, the clientsecret gets printed into the container stdout logs for an example at container startup. Details Container Image (15.04.2025): ghcr.io/project-zot/zot-linux-amd64:latest Here is an example how the configuration can look which causes the above stated problem: http: address: "0.0.0.0" port: 5000 externalUrl: "https://zot.example.com" auth: { failDelay: 1, openid: { providers: { oidc: { name: "Keycloak", clientid: "zot-client-id", clientsecret: fsdfkmmiwljasdklfsjaskldjfkljewijrf234i52k3j45l, keypath: "", issuer: "https://keycloak.example.com/realms/example", scopes: ["openid"] } } } } PoC Set up a blank new zot k8s deployment with the code snippet above. Impact exposure of secrets, on configuring a oidc provider
Recommended action: Upgrade to 1.4.4-0.20250522160828-8a99a3ed231f (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The group data stored for users in the boltdb database (meta.db) is an append-list so group revocations/removals are ignored in the API. Details SetUserGroups is alled on login, but instead of replacing the group memberships, they are appended. This may be due to some conflict with the group definitions in the config file, but that wasn't obvious to me if it were the case. PoC Login with group claims, logout, remove the user from a group from at IdP and log in again, the API still grants access and the new list of groups is appended creating meaningless duplicate entries and no longer mathing the expected groups from the IdP. The behavior can be verified by seeing the API or UI still presenting images it should not or by viewing the data directly: bbolt get meta.db UserData <user, eg: Note this example also has duplicates due to group hierarchy changes that were left in the database. Impact Any Zot configuration that relies on group-based authorization will not respect group…
Recommended action: Upgrade to 2.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cache driver GetBlob() allows read access to any blob without access control check Details If a Zot accessControl policy allows users read access to some repositories but restricts read access to other repositories and dedupe is enabled (it is enabled by default), then an attacker who knows the name of an image and the digest of a blob (that they do not have read access to), they may maliciously read it via a second repository they do have read access to. This allows an attacker to read an image that the accessControl policy denies. This attack is possible because ImageStore.CheckBlob() calls checkCacheBlob() to find the blob a global cache by searching for the digest. If it is found, it is copied to the user requested repository with copyBlob(). This cache behavior is intentionally used in RouteHandler.CreateBlobUpload() to implement cross repository blob mount (POST /v2/<name/blobs/uploads/?mount=<digest&from=<repository name) in Zot. This is still missing an access control…
Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.