Apache Airflow scheduler arbitrary code execution via awaiting_input deserialization

Apache Airflow 3.3.0 moved human-in-the-loop tasks from the triggerer to a new awaiting_input task state swept by the scheduler. That sweep deserializes the task instance's next_kwargs without an allow-list, so a Dag author, who controls that value through the task execution API, can cause an arbitrary module import and object instantiation inside the scheduler process, or terminate the scheduler job. No non-default configuration is required: the sweep runs unconditionally every 15 seconds, and the default allowed_deserialization_classes setting does not cover this code path. Versions before 3.3.0 are not affected, because human-in-the-loop tasks deferred onto the triggerer instead. This is a different code path from CVE-2026-58076, which covers the same unguarded exception-node deserialization reached elsewhere, and deployments that applied that fix must upgrade for this issue as well. Users are advised to upgrade to apache-airflow 3.3.1 or later.

• apache-airflow-core in Apache Airflow: affected at version 3.3.0 and versions less than 3.3.1 under the supplied semver boundary.
• Versions before 3.3.0 are identified as unaffected by this path because human-in-the-loop tasks were deferred to the triggerer.
• The current source identifies 3.3.1 as the fix. However, a later Apache follow-up states that the 3.3.1 remediation still deserializes the payload before checking its type in a related path; therefore, 3.3.1 should not be treated as the final operational target for deployments that need the broader deserialization risk removed. That follow-up specifies 3.4.0 or later for the remaining issue.
• The status of parallel branches not covered by these statements is not established.

Apache Airflow 3.3.0 moved human-in-the-loop tasks into an awaiting_input state processed by the scheduler. During that sweep, the scheduler deserializes the task instance's next_kwargs without an allow-list; a Dag author controls this value through the task execution API. Controlled data can therefore cause arbitrary module import and object instantiation inside the scheduler process, or terminate the scheduler job. The path runs unconditionally every 15 seconds, and the default allowed_deserialization_classes setting does not protect it. This is CWE-502: Deserialization of Untrusted Data, because untrusted data is processed before sufficiently restrictive validation is applied. The specific module, class, or object chain used in a real attack is not established by the supplied evidence.

The attack characteristics in the record describe network reachability, low complexity, no authentication requirement, and no user interaction. The practical condition is still that the actor must control next_kwargs as a Dag author through the task execution API. The record marks no public exploit as identified, and the returned enrichment records exploitation as none at its decision point. Those statuses do not prove that exploitation has never occurred or will not occur later.

A successful attack can cause the scheduler process to import modules and instantiate objects based on data controlled by a Dag author. The result may include behavior executed with scheduler-process permissions or termination of the scheduler job, affecting scheduling availability. Confidentiality and integrity consequences depend on the scheduler service account, the secrets available to the process, and its network access to other systems. The record does not establish a specific privilege-escalation path, a particular data-access path, or a named victim or breach.

The flaw can make the scheduler execute behavior determined by data controlled by a Dag author, within the permissions of the scheduler process. Terminating the scheduler job can disrupt scheduling and delay workflows that depend on it. If the scheduler can access secrets, internal services, or other resources, arbitrary object construction may create risk to those resources, although the exact permissions differ by deployment. The record does not establish a specific data disclosure, data modification, or breach.

1. Upgrade Apache Airflow to 3.4.0 or later where possible if the goal is to address this issue together with the remaining deserialization path described in the later Apache follow-up. This is the preferred operational target based on the newer guidance.
2. If the deployment must remain on the 3.3 branch, upgrade at least to 3.3.1 to apply the fix identified for this record, then assess the follow-up guidance separately before considering remediation complete.
3. Do not rely on the default allowed_deserialization_classes setting as a mitigation for this path. The available evidence does not provide a vendor-validated configuration workaround.
4. Until upgrading, restrict Dag creation and modification rights and access to the task execution API to the minimum required. This is risk reduction, not a substitute for upgrading.
5. After upgrading, verify every scheduler deployment, test a human-in-the-loop task, and ensure deployments that already applied the earlier exception-node deserialization fix are still upgraded for this separate path.

1. Inventory Apache Airflow deployments and identify installations running apache-airflow-core version 3.3.0.
2. Identify scheduler processes handling human-in-the-loop tasks and the awaiting_input state, then review who can create or modify Dags and invoke the task execution API.
3. Review scheduler logs, service restarts, and timeout-sweep health for processing errors or unexpected termination when tasks with stored next_kwargs are resumed.
4. Investigate awaiting_input tasks that remain parked, fail in batches, or are not resumed after a scheduler sweep. Treat these as investigation signals, not vendor-confirmed IOCs.
5. Monitor for unexpected module imports or object construction in the scheduler process as a precaution, but do not treat the absence of such logs as proof of safety.
6. Verify the deployed version after upgrading and test a human-in-the-loop task in a controlled environment. The supplied evidence does not provide a specific IOC list.