GPU VulnDB

Database/Control plane, storage & DevOps

Apache Airflow: DAG author gains code execution in the scheduler and API server via unrestricted deserialization

CVSS 9.8CVE-2026-33264Control plane, storage & DevOpscurated

Impact

A DAG author could embed a malicious trigger whose serialized form made the scheduler or API server import an arbitrary class path, executing code in those processes. That breaks the boundary Airflow relies on - DAG-author code is supposed to run only in workers, never in the control processes. On a GPU fleet where Airflow drives training and batch inference pipelines, the scheduler process typically holds the connection secrets, Kubernetes credentials and queue access for every tenant pipeline, so one pipeline author reaches jobs and data belonging to all of them. Anyone with write access to the DAG bundle (a shared git repo, an uploaded DAG folder) is effectively an operator of the control plane until this is fixed.

Who can reach it

Any principal who can get a DAG into the deployment's DAG bundle - commit access to the DAG repo or write access to the DAG directory. No Airflow UI authentication is needed beyond that write path; exploitation happens when the scheduler or API server parses the serialized DAG.

What to do

Upgrade apache-airflow to 3.3.0 or later and restart the scheduler and API server; worker restarts follow normally. As defense in depth where DAG authors are not fully trusted, narrow [core] allowed_deserialization_classes to an explicit allowlist - this can be applied by config change and restart without waiting for the version bump. No node drain or reboot is involved.

References

Related entries

All Control plane, storage & DevOps entries

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.