Kcp — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/kcp/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 08 Apr 2026 15:04:22 +0000Unauthenticated Access to kcp Cache Serverhttps://feed.craftedsignal.io/briefs/2026-04-kcp-cache-unauth/Wed, 08 Apr 2026 15:04:22 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-04-kcp-cache-unauth/The kcp cache server is exposed without authentication, allowing unauthorized read access to sensitive data and a race condition for write access that could lead to temporary privilege escalation.The kcp (Kubernetes Cluster Platform) cache server, responsible for replicating resources, is directly exposed by the root shard without any authentication or authorization checks. This vulnerability allows anyone with network access to the root shard to read replicated resources and potentially write to the cache server, creating a race condition. The lack of authentication in the preHandlerChainMux, specifically identified in pkg/server/config.go at line 514-518, causes the cache server to be proxied before authentication or authorization can take place. This impacts kcp versions prior to v0.29.3 and between v0.30.0 and v0.30.3. This vulnerability allows unauthorized access to sensitive information, including RBAC rules, cluster topology, API surfaces, admission control policies, and tenancy configurations.

Attack Chain

  1. Attacker gains network access to the kcp root shard, typically through exposed ports or external URLs.
  2. Attacker crafts an HTTP request targeting the /services/cache/* endpoint without any authentication headers.
  3. The request bypasses authentication and authorization checks due to the flawed preHandlerChainMux configuration.
  4. The attacker reads replicated resources from the cache, such as clusterroles, clusterrolebindings, logicalclusters, apiexports, and validatingwebhookconfigurations.
  5. (Optional) The attacker attempts to inject a malicious ClusterRole and ClusterRoleBinding via a POST request to the cache server.
  6. The cache etcd watch fires, notifying the authorization informer and replication controller in parallel.
  7. The authorization informer updates its in-memory store, briefly granting the attacker the injected RBAC rules.
  8. The replication controller eventually reconciles and deletes the injected object, but a small window of opportunity exists for privilege escalation.

Impact

Successful exploitation of this vulnerability allows unauthorized access to critical cluster information, potentially exposing RBAC configurations, API endpoints, and internal infrastructure details. An attacker can read replicated resources, including cluster roles, cluster role bindings, logical clusters, shards, API exports, API resource schemas, mutating webhook configurations, validating webhook configurations, validating admission policies, and workspace types. While injected objects are quickly cleaned up, a brief race condition allows for temporary privilege escalation. This affects kcp deployments where the root shard is network-reachable by untrusted clients, including Helm chart deployments, Operator deployments with external URLs set, and deployments with a reachable –shard-external-url.

Recommendation

  • Implement network-level access control to restrict access to the /services/cache/* paths at the load balancer, reverse proxy, or firewall level as described in the Workarounds section of the advisory.
  • Deploy the cache server separately with its own kubeconfig (--cache-server-kubeconfig) and restrict network access to it, mitigating direct exposure to the root shard as per the Workarounds section.
  • Upgrade to kcp version v0.29.3 or v0.30.3 or later to patch the vulnerability as per CVE-2026-39429.
]]>highadvisorykcpkubernetescacheauthenticationauthorizationprivilege-escalation