{"id":"CVE-2026-61682","aliases":["EUVD-2026-83043","GHSA-c8w2-fgvx-vhv4","GO-2026-6517"],"status":"published","title":"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","description":"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.","severity":{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00384,"percentile":0.32867,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-290","CWE-302","CWE-348"],"published":"2026-09-18T16:11:46Z","modified":"2026-10-28T02:30:57Z","fixes":[{"ecosystem":"Go","package":"github.com/kcp-dev/kcp","fixed_in":["0.31.4","0.32.2"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/kcp-dev/kcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.31.4"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/kcp-dev/kcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.32.0"},{"fixed":"0.32.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/kcp-dev/kcp","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.31.4"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/kcp-dev/kcp","ranges":[{"type":"SEMVER","events":[{"introduced":"0.32.0"},{"fixed":"0.32.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/kcp-dev/kcp","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.31.4"},{"introduced":"0.32.0"},{"fixed":"0.32.2"}]}]}],"products":[{"vendor":"kcp-dev","product":"kcp"}],"references":[{"url":"https://github.com/kcp-dev/kcp/security/advisories/GHSA-c8w2-fgvx-vhv4","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/kcp-dev/kcp/commit/7437cdcfec8f927d1a9bf1b2dd1e075d038e27ca","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/kcp-dev/kcp/commit/f913ee890fb2fd9fa78e50c43474b078bfb6aeff","tags":["x_refsource_MISC","fix"]},{"url":"https://github.com/kcp-dev/kcp/releases/tag/v0.31.4","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/kcp-dev/kcp/releases/tag/v0.32.2","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-c8w2-fgvx-vhv4"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/61xxx/CVE-2026-61682.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-61682","tags":["advisory"]},{"url":"https://github.com/kcp-dev/kcp","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-61682","title":"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","description":"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.","status":"published","published":"2026-09-18T16:11:46.443Z","modified":"2026-09-21T20:50:17.494Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical","assessor":"cna"}],"cwes":["CWE-290","CWE-302","CWE-348"],"updated_at":"2026-11-02T14:19:53.115938Z"}],"euvd":[{"id":"EUVD-2026-83043","description":"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.","status":"published","published":"2026-09-18T16:11:46Z","modified":"2026-09-21T20:50:17Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T17:28:04.224689Z"}],"ghsa":[{"id":"GHSA-c8w2-fgvx-vhv4","title":"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","description":"# Summary\n\nThe 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.\n\n## Impact \n\nIn 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.\n\nBecause 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:\n\n- assert `X-Remote-Group: system:masters` and act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard;\n- forge `authorization.kcp.io/warrant` to assume an arbitrary user/group identity via kcp's delegated-identity mechanism;\n- forge `authentication.kcp.io/scopes` to escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace;\n- satisfy per-workspace required-group gating by injecting the required group.\n\nThe 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.\n\n\n# Patches\nFixed 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.\n\nOperators should upgrade to a patched release. No configuration changes are required after upgrading.\n\n# Workarounds\n\nThere 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.\n\nCredit to [5ud0er](https://github.com/5ud0er) / Tarmo Technologies.","status":"published","published":"2026-09-18T17:15:49Z","modified":"2026-09-18T17:15:53Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-290","CWE-302","CWE-348"],"updated_at":"2026-11-02T14:41:19.455935Z"}],"nvd":[{"id":"CVE-2026-61682","description":"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.","status":"published","published":"2026-09-18T16:17:07.523Z","modified":"2026-09-24T21:25:27.05Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical","assessor":"secondary"}],"cwes":["CWE-290","CWE-302","CWE-348"],"updated_at":"2026-11-02T14:12:49.70655Z"}],"osv":[{"id":"CVE-2026-61682","title":"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","description":"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.","status":"published","published":"2026-09-18T16:11:46.443Z","modified":"2026-10-28T02:30:57.205245604Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-290","CWE-302","CWE-348"],"updated_at":"2026-11-02T15:45:12.933503Z"},{"id":"GHSA-c8w2-fgvx-vhv4","title":"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","description":"# Summary\n\nThe 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.\n\n## Impact \n\nIn 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.\n\nBecause 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:\n\n- assert `X-Remote-Group: system:masters` and act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard;\n- forge `authorization.kcp.io/warrant` to assume an arbitrary user/group identity via kcp's delegated-identity mechanism;\n- forge `authentication.kcp.io/scopes` to escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace;\n- satisfy per-workspace required-group gating by injecting the required group.\n\nThe 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.\n\n\n# Patches\nFixed 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.\n\nOperators should upgrade to a patched release. No configuration changes are required after upgrading.\n\n# Workarounds\n\nThere 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.\n\nCredit to [5ud0er](https://github.com/5ud0er) / Tarmo Technologies.","status":"published","published":"2026-09-18T17:15:49Z","modified":"2026-09-28T17:11:09.141356782Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-290","CWE-302","CWE-348"],"updated_at":"2026-11-02T15:46:44.927642Z"},{"id":"GO-2026-6517","title":"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 in github.com/kcp-dev/kcp","description":"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 in github.com/kcp-dev/kcp","status":"published","published":"2026-09-28T16:43:40Z","modified":"2026-09-28T17:00:16.350676379Z","updated_at":"2026-11-02T15:47:03.11707Z"}]}}