The vulnerability exists in how Apache Airflow's KubernetesExecutor handles JWT tokens. Specifically, it passes the token as a command-line argument to the worker pod, making it visible to anyone with read access to the pod's specification in the Kubernetes cluster. This allows an attacker to retrieve the token and gain unauthorized access to the Airflow API.
The analysis of the provided patches in airflow-core reveals the server-side part of the fix. The core issue lies in the airflow.executors.workloads.base.BaseWorkloadSchema.generate_token function, which was responsible for generating the token that was subsequently leaked. Before the patch, this function would call airflow.api_fastapi.auth.tokens.JWTGenerator.generate to create a powerful, long-lived token. The patch introduces a two-token system: a less-privileged, long-lived 'workload' token for the task queue and a short-lived 'execution' token for the actual task execution. The generate_token function was modified to generate the new 'workload' token, reducing the impact of a token leak. The ti_run function in airflow.api_fastapi.execution_api.routes.task_instances was also updated to handle the exchange of the 'workload' token for an 'execution' token. While the actual leaking of the token happens in the KubernetesExecutor (fixed in a separate patch), the identified functions in airflow-core were critical to the vulnerability as they produced the overly permissive token that was being leaked.