https://db.gcve.eu/rss/recent/all/10 Most recent entries from all 2026-09-28T09:18:08.234404+00:00 Vulnerability-Lookup info@gcve.eu python-feedgen Contains only the most 10 recent entries. https://db.gcve.eu/vuln/fkie_cve-2026-61682 fkie_cve-2026-61682 2026-09-28T09:18:08.266205+00:00

kcp is a Kubernetes-like control plane for form-factors and use-cases beyond Kubernetes and container workloads. Prior to 0.31.4 and 0.32.2, the kcp front-proxy does not remove inbound X-Remote-User, X-Remote-Group, or X-Remote-Extra-* identity headers before forwarding requests to shards. Any authenticated tenant can inject X-Remote-Group: system:masters, authorization.kcp.io/warrant, authentication.kcp.io/scopes, or a group used for per-workspace required-group gating, and the shard trusts these values as authenticated identity assertions. This allows cross-workspace impersonation, authorization bypass, and arbitrary reading, writing, or deletion of resources, secrets, RBAC data, APIExports, APIBindings, and LogicalClusters. This issue is fixed in versions 0.31.4 and 0.32.2.

 https://db.gcve.eu/vuln/ghsa-c8w2-fgvx-vhv4 GHSA-c8w2-fgvx-vhv4 — kcp front-proxy does not strip inbound X-Remote-* identity headers, allowing any authenticated client to inject groups/… 2026-09-28T09:18:08.266437+00:00

Affected: Go: github.com/kcp-dev/kcp

# Summary

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 authenticated attacker could smuggle forged identity headers through to the shard. With this, an attacker holding any ordinary credential (client certificate, OIDC token, or service-account token) and no special privileges could:

- assert `X-Remote-Group: system:masters` and act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard; - forge `authorization.kcp.io/warrant` to assume an arbitrary user/group identity via kcp's delega…