CVE-2026-82337 in Airflow
Summary
by MITRE • 11/09/2026
Apache Airflow rebuilt deadline alert fields through generic deserialization, which imports and instantiates the class named in the serialized Dag, in the scheduler and API server. A Dag author could cause classes within Airflow's deserialization allow list to be constructed in those processes with arguments they control. Deployments whose Dags use deadline alerts are affected.
This is an incomplete fix of CVE-2026-45360, which only hardened the `reference` field; deployments that applied that fix remain affected through the `callback` and `interval` fields.
Users of apache-airflow are recommended to upgrade to 3.4.0 or later.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/09/2026
The vulnerability described involves a critical insecure deserialization flaw within Apache Airflow, specifically affecting components responsible for handling deadline alerts in both the scheduler and API server processes. This issue stems from the framework's reliance on generic Python object serialization mechanisms to reconstruct stateful objects such as DagRunDeadlineAlert instances. When processing serialized data derived from Directed Acyclic Graph definitions, the system imports and instantiates classes based solely on class names present within the payload without sufficiently validating that the provided arguments are safe or restricted to expected types. This architectural decision allows a malicious actor who controls the content of a DAG definition to influence which internal Airflow classes are instantiated during deserialization.
This flaw represents an incomplete remediation of CVE-2026-45360, where previous security updates only hardened validation for the reference field while leaving other fields vulnerable. Specifically, the callback and interval fields within deadline alert configurations remain susceptible to exploitation because they still undergo generic deserialization processes that do not adequately restrict class instantiation or argument types. Consequently, deployments that implemented fixes for the earlier vulnerability continue to be at risk if their DAGs utilize deadline alerts with these specific fields populated by untrusted sources. The persistence of this issue highlights a common pitfall in security patching where partial mitigations fail to address all vectors within a broader architectural pattern.
From an operational perspective, the ability to control class instantiation and arguments during deserialization creates significant risks including remote code execution, denial of service through resource exhaustion, or privilege escalation depending on the context in which the scheduler or API server operates. An attacker with write access to DAG files can craft payloads that trigger arbitrary object construction within the Airflow process environment. This could lead to unauthorized data manipulation, exposure of sensitive configuration details stored in memory, or complete compromise of the underlying infrastructure hosting the orchestration service. The impact is particularly severe because it targets core scheduling and API components that typically run with elevated privileges relative to user-level applications.
Industry standards classify this type of vulnerability under CWE-502 Deserialization of Untrusted Data, which encompasses scenarios where objects are created from unverified input without proper validation or integrity checks. In the context of attack frameworks such as MITRE ATT&CK, this aligns with techniques involving T1648 Supply Chain Compromise if the DAG files themselves were tampered with during distribution, and potentially T1059 Command and Scripting Interpreter if the deserialization leads to arbitrary code execution within a Python environment. The exploitation path relies heavily on the attacker's ability to modify or inject malicious DAG definitions into the system, emphasizing the importance of strict access controls over source control repositories hosting these files.
To mitigate this vulnerability, organizations must upgrade Apache Airflow to version 3.4.0 or later where comprehensive fixes have been applied across all affected fields including callback and interval parameters. Until upgrading is feasible, administrators should enforce rigorous code review processes for any DAG definitions involving deadline alerts to ensure no malicious payloads are introduced into the repository. Additionally implementing strict file integrity monitoring on DAG directories can help detect unauthorized modifications before they reach the scheduler or API server. Restricting execution permissions of Airflow components and applying principle of least privilege principles further reduces the potential blast radius should an exploitation attempt succeed. Regular auditing of deserialization practices across all custom operators and hooks is also recommended to prevent similar issues in other parts of the ecosystem.