A flaw in Apache Airflow's KubernetesExecutor caused JWT authentication tokens to be injected into worker container command line arguments, making them visible in the pod specification. An attacker who can read pod details (for example using a Kubernetes `pods/get` permission) can extract the token from `kubectl describe pod` output and then use that token to authenticate against Airflow's Execution API. With the token the attacker can invoke state‑mutating endpoints, such as triggering DAG runs, clearing runs, or reading and writing Variables, Connections, and XComs, effectively masquerading as a running task without needing to run code inside the pod. The vulnerability is a clear example of authentication bypass via credential exposure (CWE‑538).

The issue affects installations that use the KubernetesExecutor in Apache Airflow. Any Airflow deployment running versions prior to 3.2.2 is vulnerable. Users who have already applied the provider‑side fix by upgrading `apache-airflow-providers-cncf-kubernetes` to 10.17.0 or newer must still upgrade the core `apache-airflow` package to 3.2.2 or later to fully mitigate the issue. The fix is specific to the core Airflow library and does not eliminate risks if the provider package remains outdated.

The vulnerability is not listed in the CISA KEV catalog and no EPSS score is available, indicating limited real‑world exploitation data at this time. However, the attack vector requires read‑only access to the Airflow namespace in Kubernetes, which is a realistic privilege for many internal users. The ability to obtain a valid JWT from pod command lines allows the attacker to perform a wide range of privileged API actions, giving them effective control over DAG execution and sensitive data. Because the exposed token can be captured without additional authentication and is not encrypted in transit, the risk of exploitation is significant for any environment where Kubernetes read permissions are granted to users outside of the Airflow administrative role.