kcp front-proxy X-Remote-* Identity Header Injection Impersonation (CVE-2026-61682)
Detects exploitation of CVE-2026-61682, a critical (CVSS 9.9) authentication bypass in kcp (github.com/kcp-dev/kcp) front-proxy. The front-proxy fails to strip inbound X-Remote-* identity headers (X-Remote-User, X-Remote-Group, X-Remote-Extra-*) from client requests before forwarding them to backend shard API servers. Because backend shards trust these headers as authenticated identity from the front-proxy, any authenticated client can inject arbitrary groups and warrants — including system:masters — to impersonate a cluster admin in any workspace. This detection surfaces HTTP requests to the kcp front-proxy that carry client-supplied X-Remote-* headers, along with resulting privileged API actions attributable to injected group membership. Affected: kcp < 0.31.4 and >= 0.32.0, < 0.32.2. Fixed in 0.31.4 and 0.32.2.
Vulnerability Intelligence
Public PoCAffected Software
- Vendor
- go
- Product
- github.com/kcp-dev/kcp
- Versions
- < 0.31.4, >= 0.32.0, < 0.32.2
Timeline
- Disclosed
- September 18, 2026
References & Proof of Concept
- PoChttps://github.com/advisories/GHSA-c8w2-fgvx-vhv4
- https://github.com/kcp-dev/kcp/security/advisories/GHSA-c8w2-fgvx-vhv4
- https://github.com/kcp-dev/kcp/commit/7437cdcfec8f927d1a9bf1b2dd1e075d038e27ca
- https://github.com/kcp-dev/kcp/releases/tag/v0.31.4
- https://github.com/kcp-dev/kcp/releases/tag/v0.32.2
CVSS
What is CVE-2026-61682 kcp front-proxy X-Remote-* Identity Header Injection Impersonation (CVE-2026-61682)?
kcp front-proxy X-Remote-* Identity Header Injection Impersonation (CVE-2026-61682) (CVE-2026-61682) maps to the Privilege Escalation and Defense Evasion and Initial Access tactics — the adversary is trying to gain higher-level permissions in MITRE ATT&CK.
This page provides production-ready detection logic for kcp front-proxy X-Remote-* Identity Header Injection Impersonation (CVE-2026-61682), covering the data sources and telemetry it touches: kcp front-proxy access logs, Reverse proxy / WAF request logs, Kubernetes API audit logs. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
let suspectHeaders = dynamic(["x-remote-user","x-remote-group","x-remote-groups","x-remote-extra-","x-remote-uid"]);
let frontProxyLogs = W3CIISLog
| where csUriStem has_any ("/services/", "/clusters/", "/apis/", "/api/")
| extend hdrs = tolower(tostring(csHeaders))
| where hdrs has_any (suspectHeaders)
| project TimeGenerated, cIP, csUriStem, csMethod, scStatus, csUserName, hdrs, Computer;
frontProxyLogs
| where scStatus in (200, 201, 202, 204)
| extend InjectedSystemMasters = hdrs has "system:masters"
| sort by TimeGenerated desc Identifies requests to the kcp front-proxy that carry client-supplied X-Remote-* identity headers, flagging those that succeeded and especially any injecting system:masters. Front-proxy access logs must be ingested with request headers captured (reverse-proxy/WAF/IIS-style logging in front of kcp).
Data Sources
Required Tables
False Positives
- Legitimate front-proxy internal traffic where the proxy itself sets X-Remote-* headers after authentication (filter by source IP of the trusted proxy tier).
- Security scanners or penetration tests intentionally injecting identity headers during authorized assessments.
- Load balancer health checks or observability tooling that copies request headers into logs for debugging.
Sigma rule & cross-platform mapping
The detection logic for kcp front-proxy X-Remote-* Identity Header Injection Impersonation (CVE-2026-61682) (CVE-2026-61682) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: network_connection
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for CVE-2026-61682
References (5)
- https://github.com/kcp-dev/kcp/security/advisories/GHSA-c8w2-fgvx-vhv4
- https://github.com/advisories/GHSA-c8w2-fgvx-vhv4
- https://github.com/kcp-dev/kcp/commit/7437cdcfec8f927d1a9bf1b2dd1e075d038e27ca
- https://github.com/kcp-dev/kcp/releases/tag/v0.31.4
- https://github.com/kcp-dev/kcp/releases/tag/v0.32.2
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Inject X-Remote-Group system:masters against kcp front-proxy
Expected signal: Front-proxy access log entry containing X-Remote-User/X-Remote-Group headers from the test source IP with a 2xx (vulnerable) or 401/403 (patched) response.
- Test 2Inject X-Remote-Extra warrant headers to impersonate in a workspace
Expected signal: Access log line showing X-Remote-Extra-* warrant header and the target workspace path, attributable to the test client IP.
- Test 3Baseline benign request without identity headers (negative test)
Expected signal: Front-proxy access log entry for the request with no X-Remote-* headers present.
Response Playbook
Triage
- Confirm the kcp deployment version against the front-proxy/shard binaries or container image tags; if it is < 0.31.4 or in the range >= 0.32.0, < 0.32.2 it is vulnerable and any X-Remote-* injection should be treated as high-fidelity.
- Identify the source IP/client certificate/service account behind the flagged request and determine whether it belongs to the trusted proxy tier (which is allowed to set X-Remote-* headers) or to an untrusted external/authenticated client (which is not).
- Inspect the specific X-Remote-Group / X-Remote-Extra-warrants values injected; requests asserting system:masters or cluster-admin groups in a workspace where the client has no legitimate binding are confirmed exploitation.
- Correlate the flagged front-proxy request with backend shard API audit logs to see which resources were read or mutated under the injected identity.
Containment
- Upgrade kcp to 0.31.4 (0.31.x line) or 0.32.2 (0.32.x line), which make the front-proxy strip all inbound X-Remote-* headers before forwarding to shards.
- As an immediate mitigation before upgrade, configure the ingress/reverse proxy in front of kcp to unconditionally delete client-supplied X-Remote-* (X-Remote-User, X-Remote-Group(s), X-Remote-Uid, X-Remote-Extra-*) headers.
- Revoke or rotate credentials/tokens for any client observed injecting privileged identity headers, and quarantine the source host if it is internal.
Evidence Collection
- Preserve front-proxy and reverse-proxy access logs including full request headers for the affected time window.
- Export kcp backend shard API audit logs (kube-apiserver-style audit) for actions attributed to the injected user/groups, especially create/update/delete on RBAC, secrets, and workspace objects.
- Snapshot the running kcp binary/image digest and configuration to document the vulnerable version and proxy header-handling config at time of incident.
Escalation Criteria
- ! Escalate to incident response if any request injecting system:masters or cluster-admin returned a 2xx status and was followed by mutating API actions.
- ! Escalate if injected-identity actions touched secrets, ServiceAccount tokens, RBAC bindings, or workspace/tenant boundaries, indicating potential lateral movement or privilege persistence across tenants.
Investigation Guide
Forensic Artifacts
- >
Front-proxy access log lines containing client-supplied X-Remote-User/X-Remote-Group/X-Remote-Extra-* headers. - >
kcp shard API audit entries whose user.username/user.groups reflect an unexpected system:masters or cluster-admin identity from a client IP that should not hold it. - >
Reverse-proxy configuration showing whether inbound X-Remote-* headers were being stripped.
Tuning Guidance
Establish the set of legitimate proxy-tier source IPs/hostnames that are permitted to set X-Remote-* headers and exclude them from alerting; alert only on X-Remote-* headers arriving from untrusted clients. Ensure the front-proxy/reverse-proxy access log format captures request headers, otherwise these queries will not fire. Prioritize requests that (a) inject system:masters or cluster-admin groups and (b) return 2xx status. After upgrading to 0.31.4/0.32.2, expect injected headers to no longer influence authorization; continued injection attempts then indicate reconnaissance rather than successful escalation.
Hunting Queries
Baselines which source IPs are sending X-Remote-* headers to kcp; any client outside the trusted proxy tier is a candidate for exploitation of CVE-2026-61682.
W3CIISLog | where tolower(tostring(csHeaders)) has "x-remote-" | summarize count(), makeset(csUriStem) by cIP, bin(TimeGenerated, 1h) | sort by count_ desc index=proxy OR index=kcp | search _raw="*X-Remote-*" | rex "(?i)x-remote-group[s]?:\s*(?<grp>[^\r\n]+)" | stats count values(grp) as groups by src_ip uri_path | sort - count Atomic Red Team Tests
Sends an authenticated request to the kcp front-proxy with a client-supplied X-Remote-User and X-Remote-Group asserting system:masters, simulating CVE-2026-61682 exploitation in a lab.
Command
curl -sk -H 'X-Remote-User: attacker' -H 'X-Remote-Group: system:masters' -H 'X-Remote-Extra-Warrants: cluster-admin' https://kcp-frontproxy.lab.local:6443/clusters/root/apis/rbac.authorization.k8s.io/v1/clusterrolebindings Cleanup
echo 'no persistent artifacts created by request; remove any clusterrolebinding created during testing: kubectl delete clusterrolebinding test-cve-2026-61682 --ignore-not-found' Expected Telemetry
Front-proxy access log entry containing X-Remote-User/X-Remote-Group headers from the test source IP with a 2xx (vulnerable) or 401/403 (patched) response.
Expected Detection
kql/spl/elastic_eql queries flag the request due to inbound X-Remote-* headers on a kcp API path.
Simulates injection of X-Remote-Extra-* warrant headers to assert additional entitlements in a specific kcp workspace.
Command
curl -sk -H 'X-Remote-User: svc-lowpriv' -H 'X-Remote-Groups: system:authenticated' -H 'X-Remote-Extra-authorization.kcp.io/warrant: {"groups":["system:masters"]}' https://kcp-frontproxy.lab.local:6443/clusters/root:tenant-a/api/v1/secrets Cleanup
echo 'read-only request; no cleanup required' Expected Telemetry
Access log line showing X-Remote-Extra-* warrant header and the target workspace path, attributable to the test client IP.
Expected Detection
Detection matches on the x-remote-extra- header pattern and the /clusters/ workspace URI path.
Sends a normal authenticated request without any X-Remote-* headers to confirm the detection does not fire on legitimate traffic.
Command
curl -sk --cert client.crt --key client.key https://kcp-frontproxy.lab.local:6443/api/v1/namespaces Cleanup
echo 'no cleanup required' Expected Telemetry
Front-proxy access log entry for the request with no X-Remote-* headers present.
Expected Detection
No detection should fire; used to validate false-positive tuning.