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
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/projectcapsule/capsule-proxy <= 0.4.5
Fixed in
0.4.6· Vendor fix available
Issue
The privilege escalation is based on a missing check if the user is authenticated based on the TokenReview result. All the clusters running with the anonymous-auth Kubernetes API Server setting disable (set to false) are affected since it would be possible to bypass the token review mechanism, interacting with the upper Kubernetes API Server. PoC Start a KinD cluster with the anonymous-auth value to false. If it is true, it uses anonymous permissions which are very limited by default Install capsule and capsule-proxy Then query the proxy Impact The whole cluster is exposed to unauthorised users. This privilege escalation cannot be exploited if you're relying only on client certificates (SSL/TLS).
Recommended action: Upgrade to 0.4.6 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/projectcapsule/capsule-proxy <= 0.4.4
Fixed in
0.4.5· Vendor fix available
Issue
A bug in the RoleBinding reflector used by capsule-proxy gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name. Details - Tenant solar, owned by a ServiceAccount named tenant-owner in the Namespace solar - Tenant wind, owned by a ServiceAccount named tenant-owner in the Namespace wind Please, notice the same ServiceAccount name, although in different namespaces. The Tenant owner solar would be able to list the namespaces of the Tenant wind and vice-versa, although this is not correct. The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions: 1. capsule-proxy runs with the --disable-caching=false (default value: false) 2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces. The CVE doesn't allow any privilege escalation on the outer tenant Namespace-scoped resources, since…
Recommended action: Upgrade to 0.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.