{"items":[{"id":"NVI-00015381","kind":"vulnerability","title":"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","revision":1,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected."],"lifecycle":"active","identifiers":["GHSA-c8w2-fgvx-vhv4","CVE-2026-61682"],"plain_summary":"GitHub lists this reviewed advisory for github.com/kcp-dev/kcp, github.com/kcp-dev/kcp. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-629196d43e9b8787d96a12ee4a539e95"],"action_type":"investigate","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null}],"schema_version":"1.1.0","source_metrics":[{"kind":"CVSS","as_of":"2026-09-18T17:15:53.000Z","value":"9.9 critical","meaning":"GitHub source severity; exploitability and local consequence require separate evidence.","source_id":"sr-629196d43e9b8787d96a12ee4a539e95"}],"why_it_matters":"Published affected context helps an owner decide what evidence to gather. This report has not examined your application.","related_sources":[{"id":"sr-629196d43e9b8787d96a12ee4a539e95","url":"https://github.com/advisories/GHSA-c8w2-fgvx-vhv4","basis":"vendor_advisory","notes":"GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.","title":"GHSA-c8w2-fgvx-vhv4","publisher":"GitHub Advisory Database","observed_at":"2026-11-01T14:29:49.409Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-629196d43e9b8787d96a12ee4a539e95"],"technology":"github.com/kcp-dev/kcp","known_exclusions":[],"conditions_summary":"# Summary\n\nThe 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.\n\n## Impact \n\nIn 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.\n\nBecause 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 serv","public_affected_ranges":["< 0.31.4"]},{"certainty":"source_listed","source_ids":["sr-629196d43e9b8787d96a12ee4a539e95"],"technology":"github.com/kcp-dev/kcp","known_exclusions":[],"conditions_summary":"# Summary\n\nThe 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.\n\n## Impact \n\nIn 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.\n\nBecause 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 serv","public_affected_ranges":[">= 0.32.0, < 0.32.2"]}],"null_published_at":"2026-11-03T10:03:31.361Z","source_updated_at":"2026-09-18T17:15:53.000Z","source_disclosed_at":"2026-09-18T17:15:49.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"First indexed by Null; source disclosure date is shown separately.","null_first_observed_at":"2026-11-01T14:29:49.409Z"}],"next_cursor":null,"snapshot_revision":"42594"}