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
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/kcp-dev/kcp < 0.31.4; >= 0.32.0, < 0.32.2
Fixed in
0.32.20.31.4· Vendor fix available
Issue
The kcp front-proxy fails to strip client-supplied identity headers before forwarding requests to shards. Any authenticated tenant can inject their own X-Remote-Group and X-Remote-Extra- headers, which the shard trusts as a verified identity assertion — allowing a low-privilege user to escalate to cluster administrator (system:masters) and read, write, or delete resources in any workspace on the shard. This is a complete multi-tenant isolation and authorization bypass. Impact In a sharded kcp deployment, external clients reach shards through the front-proxy, which authenticates the client and then forwards the resulting identity to the shard using Kubernetes request-header authentication (X-Remote-User / X-Remote-Group / X-Remote-Extra-). The shard trusts these headers because they arrive over the front-proxy's mutually-authenticated connection. Because the front-proxy appended its identity headers instead of replacing them — and never removed any copies the client sent — an…
Recommended action: Upgrade to 0.32.2 or 0.31.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/kcp-dev/kcp >= 0.30.0, < 0.30.3; < 0.29.3
Fixed in
0.30.30.29.3· Vendor fix available
Issue
The cache server is directly exposed by the root shard and has no authentication or authorization in place. This allows anyone who can access the root shard to read and write to the cache server. Details The cache server is routed in the pre-mux chain in the shard code. The preHandlerChainMux is handled before any authn/authz in the cache server: https://github.com/kcp-dev/kcp/blob/aaf93d59cbcd0cefb70d94bd8959ce390547c4a2/pkg/server/config.go#L514-L518 This results in the cache server being proxied before any authn/authz in the handler chain takes place. Attack Vectors 1. Unauthenticated Read Access (Primary) An attacker can read all replicated resources from the cache without any credentials. This exposes: | Category | Resources | Severity | Reason | |---|---|---|---| | RBAC | clusterroles, clusterrolebindings (filtered by annotation) | High | Only subset with internal.kcp.io/replicate annotation: access rules, APIExport bind/content rules, WorkspaceType use rules. Reveals…
Recommended action: Upgrade to 0.30.3 or 0.29.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Because UPDATE validation is not being applied, it is possible for an actor with access to an instance of the initializingworkspaces virtual workspace to run arbitrary patches on the status field of LogicalCluster objects while the workspace is initializing. This allows to add or remove any initializers as well as changing the phase of a LogicalCluster (to "Ready" for example). As this effectively allows to skip certain initializers or the entire initialization phase, potential integrations with external systems such as billing or security could be affected. Their initializers could be skipped by a WorkspaceType that adds another initializer and grants permissions to the virtual workspace to a rogue or compromised entity. Who is impacted? Impacts other owners of WorkspaceTypes with initializers that are inherited by other WorkspaceTypes. Impacts developers using the virtual/framework package to create their own virtualworkspaces if they are using UpdateFuncs in their custom…
Recommended action: Upgrade to 0.28.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The APIExport Virtual Workspace can be used to manage objects in workspaces that bind that APIExport for resources defined in the APIExport or specified and accepted via permission claims. This allows an API provider (via their APIExport) scoped down access to workspaces of API consumers to provide their services properly. The identified vulnerability allows creating or deleting an object via the APIExport VirtualWorkspace in any arbitrary target workspace for pre-existing resources. By design, this should only be allowed when the workspace owner decides to give access to an API provider by creating an APIBinding. With this vulnerability, it is possible for an attacker to create and delete objects even if none of these requirements are satisfied, i.e. even if there is no APIBinding in that workspace at all or the workspace owner has created an APIBinding, but rejected a permission claim. Patches A fix for this issue has been identified and has been published with kcp 0.26.3…
Recommended action: Upgrade to 0.26.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Impersonation is a feature of the Kubernetes API, allowing to override user information. As downstream project, kcp inherits this feature. As per the linked documentation a specific level of privilege (usually assigned to cluster admins) is required for impersonation. The vulnerability in kcp affects kcp installations in which users are granted the cluster-admin ClusterRole (or comparably high permission levels that grant impersonation access; the verb in question is impersonate) within their respective workspaces. As kcp builds around self-service confined within workspaces, most installations would likely grant such workspace access to their users. Such users can impersonate special global administrative groups, which circumvent parts of the authorizer chains, e.g. maximal permission policies. Patches The problem has been patched in #3206 and is available in kcp 0.26.1 and higher. Workarounds - Not assigning the cluster-admin role (or any other role granting blanket…
Recommended action: Upgrade to 0.26.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.