TL;DR

kcp (Kubernetes Control Plane) has an unauthenticated cache server on the root shard. Prior to 0.30.3 and 0.29.3, anyone who can reach the root shard endpoint can read and write the cache — including build metadata, job parameters, and agent telemetry. CVSS 8.2. The fix is a one-line version bump if you’re using the official images.

The Vulnerability

CVE-2026-39429 | CVSS 8.2 | Published April 8, 2026

kcp is a Kubernetes-like control plane built on KubeBuilder, designed for form-factors and use-cases beyond standard Kubernetes and container workloads. It’s used by organizations running custom control planes on top of the Kubernetes API — edge clusters, device fleets, multi-tenant environments, and specialized infrastructure.

The vulnerability: the cache server is directly exposed by the root shard with no authentication or authorization. The sharding-cache endpoint accepts requests from any source that can reach the root shard’s network path.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

This is an authentication bypass with high confidentiality and integrity impact. An attacker can read the cache (discovering stored objects, build data, configuration) and write to it (injecting payloads, modifying cached objects).

Who’s Affected

  • kcp < 0.30.3 (all 0.30.x before .3)
  • kcp < 0.29.3 (all 0.29.x before .3)
  • Not affected: 0.30.3+ and 0.29.3+

If you’re using kcp in a container runtime, edge cluster, or device fleet management setup, check your version. This is not a Kubernetes vanilla install — it’s kcp specifically.

Why the Cache Matters

kcp’s shard architecture distributes load across multiple control-plane instances. The root shard maintains a cache of objects — build metadata, job parameters, agent telemetry, custom resource definitions — that other shards reference. This is the same pattern that makes Kubernetes control planes fast: cache the hot data, serve from memory.

The problem: when the cache has no auth, the attack surface becomes:

  1. Information disclosure — read all cached objects to discover what’s running in your cluster
  2. Data injection — write crafted objects to the cache that other shards will trust
  3. Cache poisoning — overwrite cached values with attacker-controlled data, causing downstream operations to use the wrong config or credentials

For a CI/CD pipeline running on kcp, the cache might hold Docker images to pull, Helm charts to install, or environment variables for build steps. Inject the wrong value and the next build runs your payload.

The Fix

Two fixed versions are available:

  • 0.30.3 — latest stable
  • 0.29.3 — LTS-compatible

If you’re using the official Docker images:

# Check current version
kubectl version --short
# or
docker inspect <your-kcp-image> --format '{{.Config.Labels.version}}'

Upgrade to 0.30.3 or 0.29.3. The change is in the shard configuration — the cache server now requires a bearer token before writing, and reads are restricted to authenticated clients.

Checking Your Exposure

If your kcp instance has a publicly or internally accessible root shard:

# Check if cache is exposed (should return cached data)
curl -s http://<root-shard>:<port>/sharding-cache/ | head -20

# Write a test value
curl -X POST http://<root-shard>:<port>/sharding-cache/test \
  -H "Content-Type: application/json" \
  -d '{"key":"test","value":"trinity-check"}'

# Verify it persisted
curl -s http://<root-shard>:<port>/sharding-cache/test?key=test

If you get JSON back without a token, you’re exposed.

The Broader Pattern

This isn’t the first time a control-plane cache has been left unauthenticated:

  • Harbor had unauthenticated blob cache in 2024
  • Docker Registry had unauthenticated manifest cache before 2.8
  • Jenkins had unauthenticated build cache in the agent protocol

The pattern is the same: control planes cache frequently-accessed data for performance. The cache endpoint is often forgotten in security reviews because it’s “internal” and “fast.” But internal doesn’t mean safe — an attacker who gets past the network boundary hits the cache before the auth layer.

What To Do

  1. Check your version. If below 0.29.3 or 0.30.3, you’re affected.
  2. Verify exposure. Run the curl checks above against your root shard.
  3. Upgrade. Patch to 0.30.3 or 0.29.3.
  4. Audit the cache. Check what’s stored — build artifacts, credentials, config maps. If something sensitive was cached, rotate it after patching.

References