Vulnerabilities

Apache published CVE-2026-68982 on November 9, 2026, a missing-authentication flaw in Apache Airflow's CeleryExecutor. Airflow is an open-source platform for scheduling and running data pipelines, and CeleryExecutor is the mode that hands each pipeline task to a pool of worker processes through a message broker, usually Redis or RabbitMQ. A broker is the queue those messages pass through. One class of job on that queue ran without checking the authentication token that is supposed to prove the message came from Airflow, so anyone able to write to the broker can plant a forged job and have it run code on every worker. No Airflow login is involved. In security terms this is unauthenticated remote code execution (RCE: running your own commands on someone else's machine), and the machines in question are the ones that run your pipelines.

The flaw affects every Airflow release before 3.4.0 that uses CeleryExecutor. It was fixed in 3.4.0, released November 6, 2026. It is not in the US Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities catalogue (CISA KEV), and there are no public reports of it being used yet. That is the good news. The condition it needs, a reachable broker, is common, and worker machines tend to hold the credentials and data that make a pipeline worth attacking.

How the flaw works

Airflow's scheduler decides what should run and puts a message for each unit of work onto the broker. Workers subscribe to the broker, pull the next message and run it. To stop a worker from running anything that happens to land on the queue, Airflow attaches a short-lived workload token to each message, and the worker is meant to validate that token before acting.

One type of workload skipped the check. The ExecuteCallback workload backs deadline-alert callbacks, the code Airflow runs when a task or a run misses a deadline you set. The worker executed that callback without validating the token first, so a message that claimed to be a callback was trusted on arrival. Craft such a message, write it to the broker, and the worker runs whatever code the callback points at, as the worker process, on every CeleryExecutor worker that reads the queue. The weakness is catalogued as CWE-306, missing authentication for a critical function.

The fix changes where the trust sits. In 3.4.0 the worker no longer runs a callback straight off the queue. It calls back to Airflow's Execution API (Application Programming Interface, the internal service workers talk to) to claim the callback, and the API redeems a single-use token before the work is allowed to run. A forged message has no valid token to redeem, so it goes nowhere.

One detail decides whether the fix takes effect: you have to upgrade both the Execution API server and every CeleryExecutor worker. The redemption step only works if both ends speak it. Upgrade the workers but leave an old API server, or the reverse, and the check does not happen.

Why the broker is the real attack surface

Apache rated the issue "Important" and did not publish an official CVSS score (Common Vulnerability Scoring System, the 0 to 10 scale used to rank severity). Reflectiz, whose researcher reported the flaw, scored it 9.8 out of 10 with the vector AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H, which reads as network reachable, low effort, no privileges and no user interaction, with full impact on confidentiality, integrity and availability. Treat the 9.8 as Reflectiz's assessment, not Apache's. Credit for finding the flaw goes to Or Sahar of Reflectiz.

Whether this is a 9.8 in your environment depends on who can write to your broker, and the whole attack rests on that one question. A Redis broker listening on its default port 6379, or a RabbitMQ broker on 5672, with no authentication and reachable across a wider network, turns this into unauthenticated code execution on your pipeline workers. A broker bound to localhost, requiring a password, and sitting behind a firewall is a far smaller problem, because the attacker first has to reach it.

That gap is worth dwelling on, because brokers are often the least-guarded part of a data platform. They were added to make Celery work, not as something people log into, so they quietly end up on a flat internal network with no password. The worker machines they feed are the opposite: they run pipeline code, so they commonly hold cloud access keys, database connection strings and the data moving through the pipeline. Code execution there is usually a short step from the cloud account behind it.

What to do

Upgrade to Airflow 3.4.0, and upgrade both the Execution API server and every CeleryExecutor worker. A partial upgrade leaves the hole open. This is the only step that closes the flaw.

Until you can upgrade, lock down the broker, which also shuts a longer list of broker-reachable attacks:

• Require authentication on the broker. Set a password on Redis with requirepass and turn off its default open access, or create a real user and password on RabbitMQ and remove the built-in guest account.
• Bind the broker to localhost or a private subnet, never to 0.0.0.0, and firewall Redis 6379 and RabbitMQ 5672 so only the scheduler and workers can reach them.
• Never expose the broker to the internet. From outside your network, check that the port does not answer.

Then audit who and what can already write to the broker: the hosts and service accounts with a network route and credentials to it. Anything on that list can, for now, run this attack.

If the broker has been exposed, treat the workers as potentially touched. Rotate the credentials stored on them: cloud keys, Airflow connections and variables, and any database passwords in the worker environment. Review what those worker accounts could reach while the exposure lasted.

The wider point

A patch and a scoring argument aside, this is a reminder that a data pipeline's security often comes down to one piece nobody treats as a front door. The broker sits between trusted components, so it inherits their trust without any of their controls. The same logic covers the metadata database and the internal APIs behind an orchestrator. When you map the attack surface of a pipeline, put the broker on it.

If you want help finding exposed brokers and hardening the platforms your pipelines run on, our platform and cloud engineering and cloud and Kubernetes security work covers this. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Rapid7, MITRE CVE record, Apache oss-security announcement, Reflectiz research.