A newly disclosed vulnerability in Apache Airflow, tracked as CVE-2026-68982, permits unauthenticated attackers with write access to the Celery message broker to execute arbitrary code on worker nodes. The flaw impacts Airflow deployments using the CeleryExecutor in versions prior to 3.4.0.
How the vulnerability works
The issue stems from the way Airflow handles “ExecuteCallback” messages sent via the broker. Unlike other paths—such as the REST API, web UI, and ExecuteTask messages—all of which validate credentials or use signed tokens, the ExecuteCallback channel lacks any form of verification. The broker receives these callback messages, deserializes their JSON content based solely on declared structure, and then dynamically imports modules and invokes functions defined by the attacker. Callables such as os.system can be called with attacker-controlled arguments to achieve full remote code execution.
This behavior was observed in Airflow versions 3.2.1 and 3.3.0—where execute_callback handling occurs directly—while version 3.3.0 introduced a forked subprocess for the callback, it still retains the core problem leading up to version 3.4.0.
Scope, impact, and proof
Although the ExecuteCallback pathway was originally built for features like Deadline Alerts (an experimental feature for alerting when Directed Acyclic Graphs miss deadlines), the callback handler is active in every worker using CeleryExecutor regardless of whether Deadline Alerts are used. The exposure is therefore broader than just experimental features.
A security researcher confirmed full exploitation in lab settings using Docker Compose with a Redis broker and PostgreSQL backend. The proof of concept demonstrated remote code execution, extraction of hostnames, and leaking all AIRFLOW__* environment variables— including sensitive data like the Fernet key. The attack left no traces in DAG runs or task logs visible from Airflow’s UI, making detection difficult if relying purely on typical workflows.
Severity, affected versions, and remediation steps
Reflectiz assessed the flaw with a CVSS v3.1 score of 9.8—signifying a very high severity with network-attack vector, no privileges required, and full impact on confidentiality, integrity, and availability. The official rating from Apache was labeled “Important,” while acknowledging the missing authentication (CWE-306) critical function. A key fact: no patch existed before 3.4.0.
On November 6, 2026, Airflow version 3.4.0 was released to fix the vulnerability. The remedy adds the requirement for workers to redeem a single-use token with the Execution API before running callback tasks. Deployments still running earlier versions are urged to upgrade both the Execution API server and all CeleryExecutor workers immediately.
Until upgrades are completed, mitigation measures include enabling authentication on the broker (e.g. setting Redis AUTH or RabbitMQ credentials), blocking broker ports (6379 for Redis, 5672 for RabbitMQ) from exposure to external networks, and closely auditing broker traffic and worker logs for unexpected execute_workload messages.
The flaw echoes a past vulnerability from CVE-2020-11981, when broker access also led to remote code execution in older Airflow versions.
Why it matters: Airflow is a popular orchestration tool powering data pipelines in many enterprises; many deployments use CeleryExecutor and message brokers like Redis or RabbitMQ. This vulnerability exposes those environments to very serious risk when broker access is not tightly locked down or when outdated Airflow versions are used.
Storming through default defenses without needing credentials or UI interaction, this flaw elevates the risk profile of many existing workflows. Organizations should treat broker security as a first-class concern—configuring strong authentication, isolating network access, and ensuring all components are kept up to date.
