Apache Airflow 3.4.0 Security Update (CVE-2026-68982): How ExecuteCallback Bypasses Worker Auth and What to Patch

A conceptual illustration showing Airflow 3.4.0's Execution API single-use token verification gate sealing the previously unauthenticated ExecuteCallback workload path alongside ExecuteTask on CeleryExecutor workers. This is not an actual console screenshot.

On November 9, 2026, the Apache Airflow Security Team disclosed CVE-2026-68982 (CWE-306)—a critical missing-authentication vulnerability in CeleryExecutor that allows anyone with write access to the Celery broker (Redis or RabbitMQ) to execute arbitrary Python functions across every worker node without Airflow credentials—alongside five companion deserialization and secret-caching vulnerabilities. Fixed in Apache Airflow 3.4.0 (released November 6, 2026 via apache/airflow#71192), the flaw affects every prior Airflow release running CeleryExecutor, including 3.2.1, 3.3.0, 3.3.1, and 3.3.2. CVE-2026-68982 Official Record, NVD Detail, Reflectiz Technical Write-Up, Rapid7 Vulnerability DB

The core operational takeaway: your cluster is exposed even if you have zero DAGs loaded and do not use Deadline Alerts, and an attack leaves zero trace in the Airflow Web UI or REST API. Because the ExecuteCallback handler registers automatically on every CeleryExecutor worker as soon as the Celery provider loads, a forged broker message imports and invokes any Python callable directly on the worker without creating a DagRun or TaskInstance. Closing the vulnerability requires upgrading both the Execution API server and all CeleryExecutor workers to Airflow 3.4.0 or later, while locking down broker authentication and network exposure.

This guide analyzes the asymmetric token check between ExecuteTask and ExecuteCallback, the five companion Airflow 3.4.0 CVEs, and broker/worker remediation steps based on the NVD CVE-2026-68982 record, researcher Or Sahar's Reflectiz disclosure, and the November 9 Airflow security advisories. It does not inject exploit payloads into live clusters; the local Python checks below model pre-3.4.0 versus 3.4.0 worker token redemption logic.

1. Three Doors, One Unlocked: Why `ExecuteCallback` Bypassed Token Verification

In Airflow 3.x, a CeleryExecutor worker can be instructed to execute code through three paths. While the Web UI/REST API and ExecuteTask messages enforce authentication, the ExecuteCallback branch on the exact same execute_workload Celery task never verified its workload token before importing and calling the target Python path:

Dimension	Path 1: Web UI & REST API	Path 2: Broker `ExecuteTask` Workload	Path 3: Broker `ExecuteCallback` Workload (Pre-3.4.0 Vulnerable)
Entry Point	HTTP endpoints (`/api/v2/...`)	Celery `execute_workload` task (`type: "ExecuteTask"`)	Celery `execute_workload` task (`type: "ExecuteCallback"`)
Token / Credential Check	Enforced. Rejects unauthenticated requests with `401`/`403`	Enforced. `supervise_task()` validates the signed JWT workload token against the Execution API before running	Missing (CWE-306). The payload carries a `token` field, but neither `execute_callback_workload()` (3.2.1) nor `supervise_callback()` / `CallbackSubprocess` (3.3.0) validates it
Execution Mechanism	Schedules a DAG run via the scheduler	Executes a task defined inside an authorized DAG bundle	Splits `callback.data.path`, calls `import_module()` and `getattr()`, and immediately invokes the callable with attacker-supplied `kwargs` (e.g., `os.system`)
Preconditions & UI Audit Trail	Requires valid user credentials and an existing DAG; logged in UI/API	Requires a valid `DagRun` and signed token; logged in UI/API	Requires 0 DAGs and 0 Deadline Alerts configured. Creates no `DagRun` or `TaskInstance`, leaving zero audit trail in the Airflow UI or REST API

Even though Deadline Alerts are documented as experimental, the ExecuteCallback dispatch code loads on every CeleryExecutor worker whenever the Celery provider is active. Furthermore, while Airflow 3.3.0 moved callback execution into a forked CallbackSubprocess that constructs an httpx.Client holding the token, it still executed the imported callable unconditionally before making any network validation call.

How Airflow 3.4.0 fixes the flaw (apache/airflow#71192): Before executing any callback, the worker now claims the callback through the Execution API and redeems a single-use token, matching the security boundary of ExecuteTask.

2. Five Companion Deserialization and Cache CVEs Fixed in Airflow 3.4.0

Alongside CVE-2026-68982, Apache published five additional security advisories on November 9, 2026 that affect the scheduler, Execution API, and Task SDK prior to Airflow 3.4.0:

CVE ID	Affected Component & Severity	Root Cause & Security Boundary Crossed	Fix in Airflow 3.4.0
CVE-2026-68982	`CeleryExecutor` Worker (Important / Reflectiz CVSS 9.8)	`ExecuteCallback` workloads run from the Celery broker without validating the workload authentication token	Worker claims the callback via the Execution API and validates a single-use token before execution
CVE-2026-82337	Scheduler & API Server (High — incomplete fix for CVE-2026-45360)	Generic deserialization of `DeadlineAlert` `callback` and `interval` fields lets a DAG author instantiate allowlisted classes inside the scheduler and API server	Enforces the plugin-registration gate across all `DeadlineAlert` fields
CVE-2026-86829	Scheduler Dependency Evaluator (High)	Scheduler fully deserializes task-written `XCom` values when evaluating task dependencies, letting a DAG author execute code in the scheduler context	Restricts scheduler dependency evaluation to primitive `XCom` values
CVE-2026-111421	Execution API `set_xcom` (High)	`set_xcom` skips the reserved-key check, allowing task-controlled XCom payloads to instantiate internal `airflow.*` classes on the API server	Enforces reserved-key validation on `set_xcom`
CVE-2026-96285	Scheduler `next_kwargs` (Moderate/High)	Resume data in `next_kwargs` is deserialized before verifying that the outer structure is a `dict`, allowing constructor invocation	Validates structure ordering before deserializing `next_kwargs`
CVE-2026-76185	Task SDK `SecretCache` (Moderate/High)	Non-injective team cache key causes cross-team secret disclosure when both `multi_team` and `use_cache` are enabled	Fixes cache key construction in 3.4.0 (disable `use_cache` on multi-team deployments until upgraded)

3. Auditing Broker Exposure, Upgrading to 3.4.0, and Checking Worker Logs

In Reflectiz's July 2026 Shodan study of internet-reachable Airflow/Celery clusters, 198 of 211 Redis brokers responded without authentication—and Airflow's own Docker Compose quick-start template ships Redis without a password by default.

Use the commands below to check your Airflow version, test whether your broker accepts unauthenticated connections, and inspect Celery worker logs (since the Airflow UI and metadata DB record nothing when CVE-2026-68982 is exploited):

4. Simulating the `ExecuteCallback` Token Bypass and 3.4.0 Redemption Fix in Python

The dependency-free Python script below models why a pre-3.4.0 worker rejects an unauthenticated ExecuteTask message yet executes an unauthenticated ExecuteCallback message on the same queue, and how Airflow 3.4.0's single-use token redemption blocks both forgery and replay.

Scope Verified Locally

Executing the model in a local Python environment verified three boundary cases:

Empty token on pre-3.4.0 worker: ExecuteTask is rejected (401_invalid_task_token), whereas ExecuteCallback with "token": "" executes os.system with ui_audit_trail: False.

Empty token on patched 3.4.0 worker: patched_3_4_worker_dispatch() rejects the forged ExecuteCallback with 401_unauthenticated_workload before any module import occurs.

Single-use token replay prevention: A valid token (valid_jwt_02) succeeds on the first ExecuteCallback redemption and is rejected on any subsequent replay attempt.

5. Production Remediation Checklist

Upgrade both the Execution API server and every Celery worker to 3.4.0+: Upgrading only one side leaves either unpatched workers executing forged callbacks or mismatched token redemption calls.

Enforce broker authentication and private networking immediately: Require Redis AUTH (or RabbitMQ credentials) and block ports 6379 and 5672 from untrusted networks.

Rotate Fernet keys and worker credentials if the broker was exposed: Because an attacker exploiting CVE-2026-68982 can dump all AIRFLOW__* environment variables (including the Fernet key and cloud provider secrets) without leaving a DagRun in the UI, rotate secrets after patching any cluster whose broker was reachable without authentication.