CVE-2026-61682: kcp front-proxy does not strip inbound X-Remote-* identity headers, allowing any authenticated client to inject groups/warrants and impersonate system:masters in any workspace
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
kcp front-proxyto a version that resolves this vulnerability.Fixed in 0.31.4 - Upgrade
Upgrade
kcp front-proxyto a version that resolves this vulnerability.Fixed in 0.32.2
Event History
Frequently Asked Questions
Which deployments are affected?
kcp deployments using the front-proxy before version 0.31.4 or 0.32.2 are affected. The issue applies where authenticated tenants can send requests through that proxy to shards.
What does an attacker need to exploit this issue?
An attacker needs to be an authenticated tenant. They can submit identity-related X-Remote-* headers, including a system:masters group assertion, which the shard trusts after the front-proxy forwards them.
Are default authorization boundaries sufficient to prevent exploitation?
No. An authenticated client can inject trusted group, warrant, scope, or workspace required-group values, enabling authorization bypass and cross-workspace impersonation.
What should be done if immediate patching is not possible?
The provided information identifies the affected behavior but does not provide a supported workaround. Prioritize upgrading to 0.31.4 or 0.32.2 and restrict access by untrusted authenticated tenants until the front-proxy can be updated.
How can administrators assess possible impact?
Review requests passing through the front-proxy for inbound X-Remote-User, X-Remote-Group, and X-Remote-Extra-* headers, especially assertions of system:masters, authorization.kcp.io/warrant, authentication.kcp.io/scopes, or workspace required groups. Investigate potentially unauthorized cross-workspace access or changes to resources, secrets, RBAC data, APIExports, APIBindings, and LogicalClusters.