Database/Control plane, storage & DevOps
Apache Airflow 3.3.0: Dag author reaches arbitrary imports in the scheduler via next_kwargs deserialization
Impact
Airflow 3.3.0 moved human-in-the-loop tasks into an awaiting_input state that the scheduler sweeps every 15 seconds, and that sweep deserializes the task instance's next_kwargs with no allow-list. A Dag author controls that value through the task execution API, so they can force an arbitrary module import and object instantiation inside the scheduler process, or simply terminate the scheduler job. This needs no non-default configuration — the sweep always runs, and allowed_deserialization_classes does not cover the path. On an ML platform the scheduler usually holds the broadest credentials in the pipeline stack (cluster access, object storage, registries), so a Dag author reaches well past their own pipeline; killing the scheduler stalls every training and batch-inference Dag on the fleet at once.
Who can reach it
Anyone who can author or edit a Dag, or otherwise set a task instance's next_kwargs through the task execution API. Only Airflow 3.3.0 is affected — earlier versions deferred these tasks onto the triggerer instead.
What to do
Upgrade to apache-airflow 3.3.1 or later and restart the scheduler (plus API server and workers as your deployment requires); no node reboot. Having already applied the fix for CVE-2026-58076 is not sufficient — this is a separate code path reaching the same unguarded deserialization.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.