CVE-2026-61682 IBM QRadar · QRadar

Detect kcp front-proxy X-Remote-* Identity Header Injection Impersonation (CVE-2026-61682) in IBM QRadar

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.

MITRE ATT&CK

Tactic
Privilege Escalation Defense Evasion Initial Access

QRadar Detection Query

IBM QRadar (QRadar)
sql 
SELECT sourceip, url, "httpResponseCode", "httpHeaders", QIDNAME(qid) AS event, starttime
FROM events
WHERE LOWER("httpHeaders") ILIKE '%x-remote-%'
  AND (url ILIKE '/services/%' OR url ILIKE '/clusters/%' OR url ILIKE '/apis/%' OR url ILIKE '/api/%')
  AND "httpResponseCode" BETWEEN 200 AND 299
  AND (LOGSOURCENAME(logsourceid) ILIKE '%kcp%' OR LOGSOURCENAME(logsourceid) ILIKE '%proxy%')
ORDER BY starttime DESC
LAST 24 HOURS
critical severity medium confidence

Returns proxy/kcp front-proxy HTTP events carrying inbound X-Remote-* headers on successful requests to kcp API paths. Requires an HTTP log source that captures request headers into a custom property.

Data Sources

kcp front-proxy access logsReverse proxy / WAF request logs

Required Tables

events

False Positives & Tuning

  • The trusted proxy tier setting X-Remote-* headers as designed after authentication.
  • Authorized penetration testing against the kcp control plane.
  • Debug or verbose HTTP logging that records forwarded identity headers.

Other platforms for CVE-2026-61682

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

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

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

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

Last updated: 2026-09-20 Research depth: standard
References (5)

Response Playbook

Triage

  1. 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.
  2. 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).
  3. 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.
  4. 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

  1. 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.
  2. 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.
  3. Revoke or rotate credentials/tokens for any client observed injecting privileged identity headers, and quarantine the source host if it is internal.

Evidence Collection

  1. Preserve front-proxy and reverse-proxy access logs including full request headers for the affected time window.
  2. 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.
  3. 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

Related Techniques

[object Object][object Object][object Object]

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.

Hunting — KQL
kql 
W3CIISLog | where tolower(tostring(csHeaders)) has "x-remote-" | summarize count(), makeset(csUriStem) by cIP, bin(TimeGenerated, 1h) | sort by count_ desc
Hunting — SPL
spl 
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

Test 1 Inject X-Remote-Group system:masters against kcp front-proxy
linux

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

bash 
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

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

Test 2 Inject X-Remote-Extra warrant headers to impersonate in a workspace
linux

Simulates injection of X-Remote-Extra-* warrant headers to assert additional entitlements in a specific kcp workspace.

Command

bash 
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

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

Test 3 Baseline benign request without identity headers (negative test)
linux

Sends a normal authenticated request without any X-Remote-* headers to confirm the detection does not fire on legitimate traffic.

Command

bash 
curl -sk --cert client.crt --key client.key https://kcp-frontproxy.lab.local:6443/api/v1/namespaces

Cleanup

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

Related Detections

Tactic Hubs

TA0004Privilege EscalationTA0005Defense EvasionTA0001Initial Access

Related Techniques

T1078Valid AccountsT1068Exploitation for Privilege EscalationT1550.001Application Access Token

Same Tactic: Privilege Escalation

Popular Detections