kcp Front-Proxy Header Injection Lets Any Authenticated User Impersonate system:masters (CVE-2026-61682)

A critical vulnerability disclosed on 2026-09-18 via GitHub Security Advisory GHSA-c8w2-fgvx-vhv4 affects github.com/kcp-dev/kcp, tracked as CVE-2026-61682 with a CVSS score of 9.9 and a public proof-of-concept already available.

What Happened

According to the advisory, kcp's front-proxy — the component that authenticates external clients before forwarding requests to shards — failed to strip client-supplied X-Remote-User, X-Remote-Group, and X-Remote-Extra-* headers. Kubernetes request-header authentication trusts these headers as verified identity assertions once they arrive over the front-proxy's mutually-authenticated connection to a shard. Because the proxy appended rather than replaced these headers, any authenticated client (holding a client certificate, OIDC token, or service-account token — no elevated privilege required) could smuggle forged headers through, including asserting X-Remote-Group: system:masters, forging kcp's authorization.kcp.io/warrant delegated-identity mechanism, or forging authentication.kcp.io/scopes to escape workspace scoping.

Why It Matters

This is described as a complete multi-tenant isolation and authorization bypass. In a sharded kcp deployment, a low-privilege tenant could escalate to cluster super-user and read, write, or delete resources — secrets, RBAC, APIExports/APIBindings, LogicalClusters — in any workspace on the shard, not just their own. Any organization running kcp as a multi-tenant control-plane API layer is affected, and the blast radius spans every tenant sharing a shard.

What Defenders Should Do Now

• Upgrade immediately to the patched releases: v0.31.4 or v0.32.2, which now unconditionally strip inbound X-Remote-* headers at both the front-proxy and the shard's local-proxy before stamping identity.
• If upgrading isn't immediately possible, the advisory notes the only interim mitigation is terminating client connections at an external proxy that strips all X-Remote-User, X-Remote-Group, and X-Remote-Extra-* headers before they reach the kcp front-proxy — there is no complete workaround otherwise.
• For hunting: review shard access logs for identities carrying system:masters or unexpected group/warrant claims that don't correspond to your legitimate authentication flow, and audit for cross-workspace resource access that shouldn't be possible under normal tenant isolation.
• Given the public PoC and 9.9 CVSS, treat this as high priority for any internet-reachable or shared kcp deployment.

This is developing intel based on a same-day advisory; details on real-world exploitation may evolve. For the full technical writeup and patch information, see the original advisory at GHSA-c8w2-fgvx-vhv4.