CVE-2026-61682 is a critical kcp front-proxy authorization-bypass vulnerability that can allow an authenticated low-privilege tenant to supply forged identity headers that are trusted farther inside a vulnerable sharded deployment. The issue carries a CVSS score of 9.9, but it is important to describe the attack correctly: this is not an unauthenticated remote-code-execution flaw. The attacker needs valid access, while the security failure occurs because affected front-proxy versions do not reliably remove client-supplied identity headers before forwarding requests toward kcp shards.
The practical question for administrators is therefore not simply whether kcp appears in an inventory. Operators need to check the exact installed release, confirm whether the front-proxy and shard request-header trust path is in use, and then compare the deployment with the fixed versions.
CVE-2026-61682 affected and fixed kcp versions
The reviewed advisory data identifies two vulnerable release ranges. kcp versions earlier than 0.31.4 are affected, while the 0.32 branch is affected from 0.32.0 up to, but not including, 0.32.2. The fixed releases are 0.31.4 and 0.32.2.
| kcp release range | Current remediation state |
|---|---|
| Earlier than 0.31.4 | Upgrade to 0.31.4 or a later supported release |
| 0.31.4 | Fixed for this vulnerability |
| 0.32.0 to earlier than 0.32.2 | Upgrade to 0.32.2 or a later supported release |
| 0.32.2 | Fixed for this vulnerability |
The fixed-version chronology also matters. The patched 0.31.4 and 0.32.2 releases were already available before the September public CVE publication. Administrators should therefore avoid interpreting September 18 as the date the patches themselves first became available.
How the kcp authorization bypass works
kcp uses request-header identity information between trusted proxy and server components. The vulnerability arises when client-controlled identity headers such as X-Remote-User, X-Remote-Group and X-Remote-Extra-* are not removed before the request enters the trusted front-proxy-to-shard path.
An authenticated tenant can therefore attempt to submit its own identity assertions. One especially serious case is supplying a privileged group such as system:masters. When a vulnerable shard accepts that forwarded identity, the request can be authorized with privileges the original tenant did not legitimately possess. The consequence can extend beyond one workspace because the trust boundary is part of a multi-tenant control-plane path.
This distinction is important for risk assessment. Authentication does not make the vulnerability low impact: the attacker may begin with ordinary tenant access and then abuse the trusted header mechanism to cross authorization boundaries. At the same time, the issue should not be described as remotely exploitable by any unauthenticated Internet user.
How to check whether your deployment is exposed
Determine the exact release running on the affected control-plane components. Do not rely only on a broad 0.31.x or 0.32.x label.
Identify whether authenticated tenant requests pass through the kcp front-proxy and into shards using the trusted request-header identity path described by the advisory.
Deployments below 0.31.4 or in the 0.32.0–0.32.1 range need remediation for this issue.
Check whether any external proxy reliably removes all client-supplied X-Remote identity headers before requests reach the kcp front-proxy.
What administrators should do
The complete remediation is to move the affected installation onto a fixed kcp release. For the reviewed branches, that means 0.31.4 or 0.32.2, or a later supported release that contains the correction.
If an immediate upgrade is operationally impossible, the advisory-derived mitigation is to place a trusted external proxy in front of the kcp front-proxy and ensure it strips client-supplied X-Remote-User, X-Remote-Group and all X-Remote-Extra-* headers before forwarding the request. That control should be treated as an interim risk-reduction measure rather than a substitute for installing a fixed release. Operators also need to verify that no alternate network path lets tenant traffic bypass the stripping control.
Is CVE-2026-61682 actively exploited?
TPS did not independently verify evidence that CVE-2026-61682 is being actively exploited in the wild during the completed review. Some third-party vulnerability pages use stronger exploitation language, but the evidence reviewed for this article was not sufficient to present active exploitation as confirmed.
That uncertainty should not delay remediation. The vulnerability is already sufficiently serious on the confirmed technical facts: low-privilege authenticated access can potentially become a cross-workspace authorization bypass with highly privileged group membership on affected deployments.
What could change next
The current answer should be revisited if the kcp maintainers revise the advisory, change the affected release ranges, publish new mitigation guidance, or if credible exploitation evidence, a public exploit, downstream product advisories or a CISA Known Exploited Vulnerabilities listing appears. Those developments would increase urgency but would normally belong on this same URL while the core reader job remains determining exposure and remediation.