# 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

> CVE-2026-61682 (GitHub advisory GHSA-c8w2-fgvx-vhv4) is a critical-severity vulnerability with a CVSS 3.1 base score of 9.9, classed as Authentication Bypass by Spoofing (CWE-290), in github.com/kcp-dev/kcp (Go). Affected versions: < 0.31.4; >= 0.32.0, < 0.32.2. It is fixed in 0.31.4 or 0.32.2, depending on the release line.

Canonical page: https://cveminer.com/vulnerabilities/CVE-2026-61682

| Field | Value |
| --- | --- |
| CVE | CVE-2026-61682 |
| GHSA | GHSA-c8w2-fgvx-vhv4 |
| Severity | Critical |
| CVSS 3.1 | 9.9 `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H` (GitHub Advisory Database) |
| CWE | CWE-290 Authentication Bypass by Spoofing; CWE-302 Authentication Bypass by Assumed-Immutable Data; CWE-348 Use of Less Trusted Source |
| EPSS | 0.28% (higher than 20% of CVEs) |
| CISA KEV | Not listed |
| Published | 18 Sept 2026 |
| Modified | 18 Sept 2026 |

## Description

The 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.

#### Impact 

In 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.

Because 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:

- assert `X-Remote-Group: system:masters` and act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard;
- forge `authorization.kcp.io/warrant` to assume an arbitrary user/group identity via kcp's delegated-identity mechanism;
- forge `authentication.kcp.io/scopes` to escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace;
- satisfy per-workspace required-group gating by injecting the required group.

The 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.


### Patches
Fixed 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.

Operators should upgrade to a patched release. No configuration changes are required after upgrading.

### Workarounds

There 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.

Credit to [5ud0er](https://github.com/5ud0er) / Tarmo Technologies.

## Affected packages

| Package | Ecosystem | PURL | Vulnerable versions | Fixed in |
| --- | --- | --- | --- | --- |
| github.com/kcp-dev/kcp | Go | `pkg:golang/github.com/kcp-dev/kcp` | < 0.31.4; >= 0.32.0, < 0.32.2 | 0.31.4, 0.32.2 |

## Fix commits

- Patch: https://github.com/kcp-dev/kcp/commit/7437cdcfec8f927d1a9bf1b2dd1e075d038e27ca
- Patch: https://github.com/kcp-dev/kcp/commit/f913ee890fb2fd9fa78e50c43474b078bfb6aeff

## Questions

**What is the GHSA ID for CVE-2026-61682?**

GitHub tracks CVE-2026-61682 as GHSA-c8w2-fgvx-vhv4.

**What is the CVSS score of CVE-2026-61682?**

CVE-2026-61682 has a CVSS 3.1 base score of 9.9 (Critical), vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

**Which versions are affected by CVE-2026-61682?**

github.com/kcp-dev/kcp (Go): < 0.31.4; >= 0.32.0, < 0.32.2.

**How do I fix CVE-2026-61682?**

Upgrade to 0.31.4 or 0.32.2, depending on the release line. The fix is in commits 7437cdc and f913ee8.

**What is the Package URL (PURL) for CVE-2026-61682?**

The affected package's PURL is pkg:golang/github.com/kcp-dev/kcp.

**Is CVE-2026-61682 exploited in the wild?**

CISA's Known Exploited Vulnerabilities catalog doesn't list CVE-2026-61682. That means no confirmed exploitation has been catalogued, not that it is safe to leave unpatched. EPSS estimates a 0.28% chance of exploitation in the next 30 days, higher than 20% of CVEs.

## References

- https://github.com/kcp-dev/kcp/commit/7437cdcfec8f927d1a9bf1b2dd1e075d038e27ca (fix)
- https://github.com/kcp-dev/kcp/commit/f913ee890fb2fd9fa78e50c43474b078bfb6aeff (fix)
- https://github.com/kcp-dev/kcp/security/advisories/GHSA-c8w2-fgvx-vhv4 (advisory)
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/61xxx/CVE-2026-61682.json (advisory)
- https://nvd.nist.gov/vuln/detail/CVE-2026-61682 (advisory)
- https://github.com/advisories/GHSA-c8w2-fgvx-vhv4 (advisory)
- https://github.com/kcp-dev/kcp (package)
- https://github.com/kcp-dev/kcp/releases/tag/v0.31.4
- https://github.com/kcp-dev/kcp/releases/tag/v0.32.2

---

Source: CVEminer (https://cveminer.com/vulnerabilities/CVE-2026-61682), compiled from OSV (GitHub advisory), GitHub Advisory Database, OSV (CVE record), CVE.org, CISA KEV catalog. OSV and GitHub Advisory Database content is licensed CC BY 4.0.
