GPU VulnDB

Database/Control plane, storage & DevOps

Apache Airflow: Callback deserialization in the scheduler timeout sweep imports Dag-author-chosen modules

CVE-2026-67587Control plane, storage & DevOpscurated

Impact

Rebuilding a Callback object re-runs its constructor, which imports the module named by the stored callback path. A Dag author controls a task instance's next_kwargs through the task execution API, so the module imported is theirs, and the import happens inside the scheduler process when its awaiting_input timeout sweep deserializes that value. Because SyncCallback is an Airflow class it satisfies the default allowed_deserialization_classes allow-list, so operators who hardened that setting are not covered. The sweep runs unconditionally on default configuration, and the scheduler is the process that decides what runs on which GPU node. This is a distinct gadget from CVE-2026-58076 and CVE-2026-67260 - fixing either of those does not close it.

Who can reach it

An authenticated Dag author who can set a task instance's next_kwargs via the task execution API. No special configuration and no operator action are needed; the scheduler's own timeout sweep triggers the deserialization.

What to do

Upgrade to apache-airflow 3.3.1 or later and restart the scheduler. Only 3.3.0 is affected - the class existed earlier but the scheduler sweep that reaches it did not - so deployments on 3.2.x and below need no action for this CVE. Tightening allowed_deserialization_classes is not a workaround. Control-plane restart, no node drain.

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.