critical · 9.9CVE-2026-61682Sep 18, 2026

CVE-2026-61682: kcp Front-Proxy Identity Header Injection Authentication Bypass

Shubham Kandhare
Security Engagement Manager, SecureLayer7

Any authenticated kcp tenant can inject X-Remote-Group and related identity headers through the front-proxy to impersonate system:masters and gain full admin access over any workspace on the shard.

Packagegithub.com/kcp-dev/kcp
Ecosystemgo
Affected< 0.31.4
Fixed in0.31.4

The problem

In a sharded kcp deployment, clients talk to shards through the front-proxy. The shard trusts X-Remote-User, X-Remote-Group, and X-Remote-Extra-* headers arriving on the proxy's mutually-authenticated connection as verified identity.

Before v0.31.4, the front-proxy appended its own identity headers without first removing client-supplied copies. Any authenticated user (client cert, OIDC, or service account) could therefore smuggle arbitrary group memberships to the shard, bypassing the entire kcp authorizer chain across every workspace.

Proof of concept

A working proof-of-concept for CVE-2026-61682 in github.com/kcp-dev/kcp, with the exact payload below.

http
GET /clusters/root:target-workspace/apis/rbac.authorization.k8s.io/v1/clusterroles HTTP/1.1
Host: kcp-front-proxy.example.com
Authorization: Bearer <any-valid-low-priv-token>
X-Remote-Group: system:masters
X-Remote-Extra-authorization.kcp.io%2fwarrant: {"user":"admin","groups":["system:masters"]}
X-Remote-Extra-authentication.kcp.io%2fscopes: cluster:root:target-workspace

The root cause is CWE-290/CWE-302: the front-proxy called SetAuthHeaders (appending the authenticated identity) without first calling ClearAuthHeaders to delete client-supplied copies. Because the shard trusts all X-Remote-* headers verbatim on the proxy's mTLS connection, the injected headers arrived with full authority.

The patch (commit 7437cdcfec8f927d1a9bf1b2dd1e075d038e27ca) introduced the pkg/proxy/authheaders package with two functions: ClearAuthHeaders, which unconditionally deletes every inbound X-Remote-User, X-Remote-Group, and X-Remote-Extra-* header before forwarding, and SetAuthHeaders, which now always calls ClearAuthHeaders first before stamping the real authenticated identity.

No client-supplied value can survive to the shard after the fix.

The fix

Upgrade to kcp v0.31.4 or v0.32.2 (or later). No configuration changes are needed after upgrading. As an interim-only mitigation, an external proxy placed in front of the kcp front-proxy that strips X-Remote-User, X-Remote-Group, and all X-Remote-Extra-* headers from inbound requests reduces exposure, but upgrading is the only complete fix.

Reported by 5ud0er / Tarmo Technologies.

References: [1][2][3][4][5]

Related research