CVE-2026-39429: Github.com/kcp dev/kcp Kcp's Cache Server Is Accessible Vulnerability

HIGH
Advisory Identifier: GHSA-3j3q-wp9x-585p
CVSS 8.2
CWE-302 CWE-306 CWE-862
Published
Advisory Summary

CVE-2026-39429 is a HIGH (CVSS 8.2) kcp's cache server is accessible vulnerability (CWE-302: Authentication Bypass by Assumed-Immutable Data) affecting Github.com/kcp dev/kcp libraries in the Go ecosystem. The issue involves kcp's cache server is accessible without authentication or authorization checks. Remediation is available by upgrading affected packages to version 0.30.3, 0.29.3.

CVE-2026-39429 at a Glance

CVE Identifier CVE-2026-39429
GHSA Identifier GHSA-3j3q-wp9x-585p
Severity HIGH
CVSS v3.1 Base Score 8.2
CWE Classification CWE-302: Authentication Bypass by Assumed-Immutable Data
Affected Product Github.com/kcp dev/kcp
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 8.2

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-39429

To remediate this vulnerability, upgrade all affected Github.com/kcp dev/kcp dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/kcp-dev/kcp fixed: 0.30.3
Upgrade github.com/kcp-dev/kcp to 0.30.3
github.com/kcp-dev/kcp fixed: 0.29.3
Upgrade github.com/kcp-dev/kcp to 0.29.3
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/kcp-dev/kcp

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-39429, inspect your project dependencies for Github.com/kcp dev/kcp:

inspect dependencies for github.com/kcp-dev/kcp

Analyze the terminal output to locate any version of Github.com/kcp dev/kcp in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.30.3), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-302: Authentication Bypass by Assumed-Immutable Data, where the authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker. In Github.com/kcp dev/kcp, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary The cache server is directly exposed by the root shard and has no authentication or authorization in place. This allows anyone who can access the root shard to read and write to the cache server. ### Details The cache server is routed in the pre-mux chain in the shard code. The preHandlerChainMux is handled before any authn/authz in the cache server: https://github.com/kcp-dev/kcp/blob/aaf93d59cbcd0cefb70d94bd8959ce390547c4a2/pkg/server/config.go#L514-L518 This results in the cache server being proxied before any authn/authz in the handler chain takes place. ### Attack Vectors #### 1. Unauthenticated Read Access (Primary) An attacker can read all replicated resources from the cache without any credentials. This exposes: | Category | Resources | Severity | Reason | |---|---|---|---| | RBAC | clusterroles, clusterrolebindings (filtered by annotation) | High | Only subset with `internal.kcp.io/replicate` annotation: access rules, APIExport bind/content rules, WorkspaceType use rules. Reveals permission structure for API access and tenancy. Roles/RoleBindings NOT replicated. | | Infrastructure | logicalclusters, shards | High | Reveals full cluster topology and shard configuration | | API surface | apiexports, apiexportendpointslices, apiresourceschemas | High | Reveals all exported APIs and their network endpoints | | Admission control | mutatingwebhookconfigurations, validatingwebhookconfigurations, validatingadmissionpolicies | High | Reveals admission policies, aids bypass | | Tenancy | workspacetypes | Medium | Reveals workspace structure | | Cache metadata | cachedobjects, cachedresources, cachedresourceendpointslices | Medium | Exposes cache state and resource endpoints | #### 2. Write Access with Race Condition (Secondary) The cache server allows full CRUD operations. While injected objects are cleaned up by the replication controller, a race condition exists that could allow temporary privilege escalation. #### The race window: 1. Attacker POSTs a malicious ClusterRole + ClusterRoleBinding to the cache server 2. Cache etcd watch fires and notifies two consumers in parallel: 2.1. The authorization informer (CacheKubeSharedInformerFactory) updates its in-memory store — the GlobalAuthorizer and WorkspaceContentAuthorizer now see the injected RBAC rules 2.2. The replication controller's informer enqueues a reconcile to its workqueue 3. Replication controller worker dequeues, calls getLocalCopy() → not found, deletes the object Between steps 2 and 3, any API request hitting the GlobalAuthorizer ([global_authorizer.go:89-101](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/authorization/global_authorizer.go#L89-L101)) would evaluate RBAC against a store that includes the attacker's injected rules. The authorization informer and the replication controller share the same CacheKubeSharedInformerFactory ([config.go:361](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/server/config.go#L361)), so the object is visible to authorization as soon as the informer cache updates — before the replication controller can process and delete it. **Practical exploitability is low** — the window is sub-second, requiring the attacker to fire the privileged API request with precise timing. However, it could be automated in a tight loop. The workqueue rate limiter could also widen the window under load. **Self-healing mechanism:** The replication controller acts as a self-healing mechanism. Objects injected into the cache are deleted almost instantly because: Creating an object in cache triggers the cache informer Replication controller reconciles, calls getLocalCopy() → not found Controller calls deleteObject() on the cache copy ([replication_reconcile.go:157-168](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/reconciler/cache/replication/replication_reconcile.go#L157-L168)) ### Replicatable Start a kcp root shard and query the cache server, e.g. with: ```sh curl --insecure 'https://root.vespucci.genericcontrolplane.io:6443/services/cache/shards/root/clusters/root/apis/apis.kcp.io/v1alpha1' ``` ### Workarounds Network-level access control: Restrict access to /services/cache/* paths at the load balancer, reverse proxy, or firewall level. External cache server: Deploy the cache server separately with its own kubeconfig (--cache-server-kubeconfig) and restrict network access to it. ### Impact Who is affected: Any kcp deployment where the root shard is network-reachable by untrusted clients. This applies when: - **Helm chart deployments:** Affected if the shard's Service or Ingress exposes port 6443 externally. - **Operator deployments:** Affected if the Shard resource has spec.externalURL set (or spec.baseURL — externalURL defaults to baseURL if unset). When a shard has an external URL, clients route to it directly, exposing the /services/cache/* path. - **Any deployment method:** If the root shard's --shard-external-url is set and reachable from untrusted networks, the cache server is exposed. **Not affected:** Deployments where the root shard is behind a front-proxy and is not directly reachable. The front-proxy does not forward /services/cache/* requests. **Write persistence:** The replication controller watches the cache informer and acts as a self-healing mechanism. Objects injected into the cache are deleted almost instantly (sub-second) because: - Creating an object in cache triggers the cache informer - Replication controller reconciles, calls getLocalCopy() → not found - Controller calls deleteObject() on the cache copy ([replication_reconcile.go:157-168](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/reconciler/cache/replication/replication_reconcile.go#L157-L168))

CVE-2026-39429 Affected Github.com/kcp dev/kcp Versions

2 component(s)
Fixed Versions:
0.30.30.29.3
Product / Package Ecosystem Affected Versions Fixed Version
github.com/kcp-dev/kcp
Go
≥ 0.30.0
< 0.30.3
0.30.3
github.com/kcp-dev/kcp
Go
< 0.29.3
0.29.3

References

Frequently Asked Questions

What is CVE-2026-39429?
CVE-2026-39429 is a security vulnerability in Github.com/kcp dev/kcp involving kcp's cache server is accessible without authentication or authorization checks under CWE-302: Authentication Bypass by Assumed-Immutable Data.
Which Github.com/kcp dev/kcp versions are affected?
Affected versions include releases prior to 0.30.3, 0.29.3 across affected packages: github.com/kcp-dev/kcp.
What version fixes CVE-2026-39429?
Upgrading to 0.30.3, 0.29.3 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/kcp-dev/kcp affected?
Yes, github.com/kcp-dev/kcp is affected in releases prior to 0.30.3, 0.29.3. Upgrade your dependency to 0.30.3, 0.29.3 or later.
What is the CVSS score of CVE-2026-39429?
CVE-2026-39429 has a CVSS v3.1 base score of 8.2 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N.
What CWE is associated with CVE-2026-39429?
CVE-2026-39429 is classified under CWE-302: Authentication Bypass by Assumed-Immutable Data (The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.).
How can I check Go dependencies for CVE-2026-39429?
Run the dependency tree command: 'inspect dependencies for github.com/kcp-dev/kcp'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-3j3q-wp9x-585p",
  "modified" : "2026-04-09T14:28:52Z",
  "published" : "2026-04-08T15:04:22Z",
  "aliases" : [ "CVE-2026-39429" ],
  "summary" : "kcp's cache server is accessible without authentication or authorization checks",
  "details" : "### Summary\n\nThe cache server is directly exposed by the root shard and has no authentication or authorization in place.\nThis allows anyone who can access the root shard to read and write to the cache server.\n\n### Details\n\nThe cache server is routed in the pre-mux chain in the shard code. \nThe preHandlerChainMux is handled before any authn/authz in the cache server: \nhttps://github.com/kcp-dev/kcp/blob/aaf93d59cbcd0cefb70d94bd8959ce390547c4a2/pkg/server/config.go#L514-L518\n\nThis results in the cache server being proxied before any authn/authz in the handler chain takes place.\n\n### Attack Vectors\n\n#### 1. Unauthenticated Read Access (Primary)\nAn attacker can read all replicated resources from the cache without any credentials. This exposes:\n\n| Category | Resources | Severity | Reason |\n|---|---|---|---|\n| RBAC | clusterroles, clusterrolebindings (filtered by annotation) | High | Only subset with `internal.kcp.io/replicate` annotation: access rules, APIExport bind/content rules, WorkspaceType use rules. Reveals permission structure for API access and tenancy. Roles/RoleBindings NOT replicated. |\n| Infrastructure | logicalclusters, shards | High | Reveals full cluster topology and shard configuration |\n| API surface | apiexports, apiexportendpointslices, apiresourceschemas | High | Reveals all exported APIs and their network endpoints |\n| Admission control | mutatingwebhookconfigurations, validatingwebhookconfigurations, validatingadmissionpolicies | High | Reveals admission policies, aids bypass |\n| Tenancy | workspacetypes | Medium | Reveals workspace structure |\n| Cache metadata | cachedobjects, cachedresources, cachedresourceendpointslices | Medium | Exposes cache state and resource endpoints |\n\n#### 2. Write Access with Race Condition (Secondary)\nThe cache server allows full CRUD operations. While injected objects are cleaned up by the replication controller, a race condition exists that could allow temporary privilege escalation.\n\n#### The race window:\n\n1. Attacker POSTs a malicious ClusterRole + ClusterRoleBinding to the cache server\n2. Cache etcd watch fires and notifies two consumers in parallel:\n2.1. The authorization informer (CacheKubeSharedInformerFactory) updates its in-memory store — the GlobalAuthorizer and WorkspaceContentAuthorizer now see the injected RBAC rules\n2.2. The replication controller's informer enqueues a reconcile to its workqueue\n3. Replication controller worker dequeues, calls getLocalCopy() → not found, deletes the object\n\nBetween steps 2 and 3, any API request hitting the GlobalAuthorizer ([global_authorizer.go:89-101](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/authorization/global_authorizer.go#L89-L101)) would evaluate RBAC against a store that includes the attacker's injected rules. The authorization informer and the replication controller share the same CacheKubeSharedInformerFactory ([config.go:361](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/server/config.go#L361)), so the object is visible to authorization as soon as the informer cache updates — before the replication controller can process and delete it.\n\n**Practical exploitability is low** — the window is sub-second, requiring the attacker to fire the privileged API request with precise timing. However, it could be automated in a tight loop. The workqueue rate limiter could also widen the window under load.\n\n**Self-healing mechanism:** The replication controller acts as a self-healing mechanism. Objects injected into the cache are deleted almost instantly because:\n\nCreating an object in cache triggers the cache informer\nReplication controller reconciles, calls getLocalCopy() → not found\nController calls deleteObject() on the cache copy ([replication_reconcile.go:157-168](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/reconciler/cache/replication/replication_reconcile.go#L157-L168))\n\n### Replicatable \n\nStart a kcp root shard and query the cache server, e.g. with:\n\n```sh\ncurl --insecure 'https://root.vespucci.genericcontrolplane.io:6443/services/cache/shards/root/clusters/root/apis/apis.kcp.io/v1alpha1'\n```\n\n### Workarounds\n\nNetwork-level access control: Restrict access to /services/cache/* paths at the load balancer, reverse proxy, or firewall level.\nExternal cache server: Deploy the cache server separately with its own kubeconfig (--cache-server-kubeconfig) and restrict network access to it.\n\n### Impact\n\nWho is affected: Any kcp deployment where the root shard is network-reachable by untrusted clients. This applies when:\n\n- **Helm chart deployments:** Affected if the shard's Service or Ingress exposes port 6443 externally.\n- **Operator deployments:** Affected if the Shard resource has spec.externalURL set (or spec.baseURL — externalURL defaults to baseURL if unset). When a shard has an external URL, clients route to it directly, exposing the /services/cache/* path.\n- **Any deployment method:** If the root shard's --shard-external-url is set and reachable from untrusted networks, the cache server is exposed.\n\n**Not affected:** Deployments where the root shard is behind a front-proxy and is not directly reachable. The front-proxy does not forward /services/cache/* requests.\n\n**Write persistence:** The replication controller watches the cache informer and acts as a self-healing mechanism. Objects injected into the cache are deleted almost instantly (sub-second) because:\n\n- Creating an object in cache triggers the cache informer\n- Replication controller reconciles, calls getLocalCopy() → not found\n- Controller calls deleteObject() on the cache copy ([replication_reconcile.go:157-168](https://github.com/kcp-dev/kcp/blob/aaf93d59c/pkg/reconciler/cache/replication/replication_reconcile.go#L157-L168))",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/kcp-dev/kcp"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.30.0"
      }, {
        "fixed" : "0.30.3"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/kcp-dev/kcp"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.29.3"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/kcp-dev/kcp/security/advisories/GHSA-3j3q-wp9x-585p"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-39429"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/kcp-dev/kcp"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kcp-dev/kcp/releases/tag/v0.29.3"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kcp-dev/kcp/releases/tag/v0.30.3"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-302", "CWE-306", "CWE-862" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-08T15:04:22Z",
    "nvd_published_at" : "2026-04-08T21:16:59Z"
  }
}