GHSA-c8w2-fgvx-vhv4: Critical severity go/github.com/kcp-dev/kcp vulnerability
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 delegated-identity mechanism; - forge authentication.kcp.io/scopes to escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace; - satisfy per-workspace required-group gating by injecting the required group.
The result is arbitrary read/write/delete access to any tenant's resources, secrets, RBAC, APIExports/APIBindings, and LogicalClusters — a cross-workspace access break and authorizer bypass across the proxy's trust boundary.
Patches Fixed in v0.31.4, 0.32.2. The front-proxy and the shard's in-process local-proxy now unconditionally remove any inbound X-Remote- identity headers before stamping the authenticated identity, so no client-supplied value can be forwarded to a shard.
Operators should upgrade to a patched release. No configuration changes are required after upgrading.
Workarounds
There is no complete workaround other than upgrading. Deployments that terminate client connections at an external proxy capable of stripping X-Remote-User, X-Remote-Group, and all X-Remote-Extra- headers from inbound requests before they reach the kcp front-proxy can mitigate exposure in the interim.
Credit to 5ud0er / Tarmo Technologies.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/kcp-dev/kcpto a version that resolves this vulnerability.Fixed in 0.32.2 - Upgrade
Upgrade
go/github.com/kcp-dev/kcpto a version that resolves this vulnerability.Fixed in 0.31.4 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 0.31.4 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 0.32.2 - Compensating control
If you cannot upgrade immediately, ensure the external proxy that terminates client connections strips/drops inbound identity headers `X-Remote-User`, `X-Remote-Group`, and all `X-Remote-Extra-*` headers before requests reach the kcp front-proxy, so client-supplied values cannot be forwarded to shards.
Event History
Frequently Asked Questions
Which deployments are exposed to this authorization bypass?
Sharded kcp deployments where external clients reach shards through the front-proxy are exposed. The issue affects the trust boundary where shards accept Kubernetes request-header authentication assertions forwarded by the mutually authenticated front-proxy connection.
What does an attacker need to exploit the issue?
An attacker needs any authenticated tenant credential, such as an ordinary client certificate, OIDC token, or service account credential. They can then supply forged X-Remote-Group or X-Remote-Extra-* headers that are forwarded to the shard.
What access could an attacker obtain?
A low-privilege authenticated user can assert membership in system:masters and escalate to cluster administrator on the affected shard. This can allow reading, writing, or deleting resources in any workspace on that shard.
How can I tell whether a deployment is affected?
A deployment is affected if its front-proxy appends identity headers rather than replacing them and does not remove client-provided X-Remote-Group or X-Remote-Extra-* headers before forwarding requests to shards. Review front-proxy request-header handling and deployed release information; v0.31.4 is listed as a release reference for this advisory.