CVE-2026-26055: Yoke ATC Auth Bypass Vulnerability

CVE-2026-26055 Overview

CVE-2026-26055 is an authentication bypass vulnerability affecting the Air Traffic Controller (ATC) component of Yoke, a Helm-inspired infrastructure-as-code (IaC) package deployer. The ATC webhook endpoints lack proper authentication mechanisms, allowing any pod within the cluster network to directly send AdmissionReview requests to the webhook, bypassing Kubernetes API Server authentication. This enables attackers to trigger WASM module execution in the ATC controller context without proper authorization.

Critical Impact

Unauthorized pods can bypass Kubernetes API Server authentication and trigger arbitrary WASM module execution in the ATC controller context, potentially compromising the integrity of infrastructure deployments.

Affected Products

• Yoke version 0.19.0 and earlier
• Air Traffic Controller (ATC) component
• Yoke deployments with ATC webhook endpoints exposed within cluster networks

Discovery Timeline

• February 12, 2026 - CVE-2026-26055 published to NVD
• February 12, 2026 - Last updated in NVD database

Technical Details for CVE-2026-26055

Vulnerability Analysis

This vulnerability is classified under CWE-306 (Missing Authentication for Critical Function). The Air Traffic Controller component in Yoke serves as a Kubernetes admission webhook that processes AdmissionReview requests. Normally, these requests should originate exclusively from the Kubernetes API Server, which handles authentication and authorization before forwarding requests.

The root issue is that the ATC webhook endpoints accept and process AdmissionReview requests from any source within the cluster network without verifying that the request originated from the Kubernetes API Server. This architectural flaw means that any pod with network access to the ATC service can craft and submit AdmissionReview requests directly, completely bypassing the intended authentication flow.

Root Cause

The vulnerability stems from missing authentication mechanisms on the ATC webhook endpoints. The implementation assumes that only the Kubernetes API Server will send requests to these endpoints, without implementing any verification of the request source. This violates the principle of defense in depth, as the webhook should independently verify that incoming requests are legitimate regardless of network-level controls.

Attack Vector

An attacker who has compromised any pod within the cluster network, or who can deploy a malicious pod, can exploit this vulnerability through the following attack flow:

1. The attacker identifies the ATC webhook service endpoint within the cluster
2. The attacker crafts a malicious AdmissionReview request with arbitrary admission data
3. The request is sent directly to the ATC webhook, bypassing the Kubernetes API Server
4. The ATC controller processes the request and executes the associated WASM module
5. The attacker achieves unauthorized code execution in the ATC controller context

This is a network-based attack vector that requires no user interaction and can be executed with low complexity. The impact is primarily to the integrity of the system, as attackers can trigger unauthorized WASM module execution.

Detection Methods for CVE-2026-26055

Indicators of Compromise

• Unexpected AdmissionReview requests originating from pods other than the Kubernetes API Server
• Unusual WASM module execution patterns in ATC controller logs
• Network connections to the ATC webhook service from non-kube-apiserver sources

Detection Strategies

• Monitor network traffic to ATC webhook endpoints and alert on connections from sources other than the Kubernetes API Server
• Implement audit logging for all AdmissionReview requests processed by the ATC controller
• Deploy network policies that restrict access to the ATC webhook service and alert on policy violations
• Review ATC controller logs for unusual request patterns or unexpected WASM module executions

Monitoring Recommendations

• Enable detailed request logging on the ATC webhook service to capture source IP addresses and request metadata
• Set up alerting for any AdmissionReview requests that don't match expected Kubernetes API Server characteristics
• Monitor for new or unexpected pods attempting to communicate with the ATC service

How to Mitigate CVE-2026-26055

Immediate Actions Required

• Review cluster network policies and restrict network access to the ATC webhook endpoints to only the Kubernetes API Server
• Audit existing deployments for signs of exploitation
• Consider temporarily disabling the ATC component if not critical to operations until a patch is applied
• Implement Kubernetes NetworkPolicies to limit pod-to-pod communication with the ATC service

Patch Information

For the latest patch information and security updates, refer to the GitHub Security Advisory (GHSA-965m-v4cc-6334). Organizations should upgrade Yoke to a version newer than 0.19.0 once a patched version becomes available.

Workarounds

• Implement Kubernetes NetworkPolicies to restrict which pods can communicate with the ATC webhook service
• Configure network segmentation to isolate the ATC webhook endpoints from general cluster traffic
• Consider implementing a service mesh with mutual TLS (mTLS) to authenticate traffic to the ATC webhook
• Deploy an authentication proxy in front of the ATC webhook to verify request sources

# Example NetworkPolicy to restrict access to ATC webhook
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: atc-webhook-restrict
  namespace: yoke-system
spec:
  podSelector:
    matchLabels:
      app: atc-webhook
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              component: kube-apiserver
      ports:
        - protocol: TCP
          port: 443