By crafting requests with custom X-Remote-Group or X-Remote-Extra-* headers, an attacker can assert elevated privileges, specifically system:masters, or forge warrants and scopes to break workspace isolation. This allows any authenticated user to gain cluster-administrator access, enabling read, write, and delete operations across all tenants and workspaces managed by the affected shard. The vulnerability was identified and disclosed in September 2026 and affects specific versions of the kcp binary.

Attack Chain

1. Attacker obtains valid low-privilege authentication credentials (e.g., client certificate, OIDC token, or service account token) valid for the kcp environment.
2. Attacker crafts an HTTP request targeting a resource managed by a kcp shard.
3. Attacker injects malicious X-Remote-Group: system:masters and X-Remote-Extra-* headers into the request.
4. Attacker sends the crafted request to the kcp front-proxy.
5. Front-proxy authenticates the attacker but fails to strip the pre-existing, malicious identity headers.
6. Front-proxy forwards the request along with the original injected headers to the target shard.
7. The shard processes the identity headers as trusted assertions from the front-proxy.
8. Attacker gains unauthorized administrative access to the targeted workspace or the entire shard, allowing data exfiltration or destructive actions.

Impact

Successful exploitation results in a total breakdown of multi-tenant security boundaries within a kcp cluster. An attacker can access, modify, or delete any resource, including secrets, APIExports, and LogicalClusters, across all workspaces on the compromised shard. The potential impact is widespread data breach and full cluster takeover, affecting any organization utilizing sharded kcp deployments for multi-tenant service hosting.

Recommendation

Prioritize the immediate upgrade of all kcp front-proxy and shard components to version 0.31.4 or 0.32.2. No configuration changes are required following the patch. In environments where immediate patching is not feasible, implement a strict front-end proxy layer (e.g., Nginx, Envoy, or HAProxy) positioned before the kcp front-proxy that explicitly strips all X-Remote- prefixed headers from inbound client requests. Monitor webserver logs for requests containing headers such as X-Remote-Group or X-Remote-Extra originating from client IP addresses to identify potential exploitation attempts.