Airflow Kubernetes Provider CVE-2026-27173

Requires Apache Airflow deployed with the KubernetesExecutor (CNCF Kubernetes provider < 10.17.0) and an attacker holding read-only RBAC (get/list/watch) on Pods in the namespace where worker pods are scheduled; the exploitable material is the 'workload'-scoped JWT the scheduler embeds in the worker pod's workload JSON payload. Limiting factors that reduce realistic risk: the attacker must already be authenticated to the Kubernetes API with pod-read permission (PR:L, not anonymous), only KubernetesExecutor deployments embed the token this way, and the harvested token is time-bounded - the workload token expires after [scheduler] task_queued_timeout (default 600 seconds) and execution tokens after ~10 minutes - so the reuse window is finite though renewable while a task is active.

Signals conflict in severity. The vendor CVSS is 8.7 (High) driven by C:H/I:H and a scope change, but every exploitation-likelihood signal is low: EPSS is 0.01% (2nd percentile), there is no KEV listing, no known POC, and CISA SSVC reports Exploitation=none, Automatable=no, Technical Impact=partial. Exploitation is not remote-unauthenticated - it requires an actor who already holds read-only Kubernetes Pod RBAC in the namespace where Airflow worker pods run, making this a lateral-movement/insider escalation rather than an internet-facing threat. One data conflict to verify: the vendor vector uses AV:L, yet reading Kubernetes Pod objects is normally performed over the network-reachable Kubernetes API server, which argues for AV:N and a slightly higher base score; treat the local vs. network distinction as deployment-dependent. Net priority: patch on a normal cadence, prioritized higher only where untrusted or broad namespace read access exists.

A data engineer or compromised service account granted only read-only Kubernetes Pod permissions runs 'kubectl get pod <worker> -o yaml' and extracts the embedded workload-scoped JWT from the pod's workload payload. They replay that bearer token against the Airflow Execution API /run endpoint to obtain a fresh execution-scoped token, then invoke Task SDK operations to read task context and modify Airflow database state as if they were the running task. No public exploit code is known, but the technique requires only standard Kubernetes tooling.