GHSA-c8w2-fgvx-vhv4 is a critical-severity (CVSS 9.9) CWE-290 vulnerability in github.com/kcp-dev/kcp. A fix is available for github.com/kcp-dev/kcp — see the affected versions and patch details below.
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
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-c8w2-fgvx-vhv4 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/kcp-dev/kcp🐹github.com/kcp-dev/kcpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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:mastersand act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard; - forge
authorization.kcp.io/warrantto assume an arbitrary user/group identity via kcp's delegated-identity mechanism; - forge
authentication.kcp.io/scopesto 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 / Tarmo Technologies.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/kcp-dev/kcp | all versions | 0.31.4go get github.com/kcp-dev/kcp@v0.31.4 |
| 🐹Go | github.com/kcp-dev/kcp | ≥ 0.32.0&&< 0.32.2 | 0.32.2go get github.com/kcp-dev/kcp@v0.32.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/kcp-dev/kcp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/kcp-dev/kcp to 0.31.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c8w2-fgvx-vhv4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-c8w2-fgvx-vhv4 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-c8w2-fgvx-vhv4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-c8w2-fgvx-vhv4 in your dependencies?
O3 Security finds GHSA-c8w2-fgvx-vhv4 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.