GPU VulnDB

Database/Control plane, storage & DevOps

Apache Airflow KubernetesExecutor: worker Execution API JWTs are exposed in the pod spec

CVSS 8.8CVE-2026-49298Control plane, storage & DevOpscurated

Impact

The KubernetesExecutor passed the JWT that worker pods use to authenticate to the Execution API as command-line arguments, so the token appears in the pod spec. Anyone with read-only Kubernetes access to the Airflow namespace - pods/get is enough - can harvest it from kubectl describe pod and then call state-mutating Execution API endpoints as if they were a running task: trigger or clear DAG runs, and read or write Variables, Connections and XComs. Connections and Variables are where a GPU fleet keeps registry, object-store and cloud credentials, so this is a credential-disclosure path as much as a tampering one. This is the airflow-core half of the issue whose providers-side fix shipped as CVE-2026-27173; the two fixes are complementary.

Who can reach it

Any principal with read access to pods in the Airflow namespace of the Kubernetes cluster, plus network reach to the Execution API. Affects deployments using the KubernetesExecutor.

What to do

Upgrade apache-airflow to 3.2.2 or later and restart the scheduler and API server; also upgrade apache-airflow-providers-cncf-kubernetes to 10.17.0 or later per the CVE-2026-27173 advisory, since neither fix closes the other's surface. Tighten pods/get in the Airflow namespace and rotate any credentials stored in Airflow Connections and Variables that non-trusted readers could have reached. Daemon restart only - no node drain.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.