Database/Control plane, storage & DevOps
Apache Airflow: executor_config deserialization imports arbitrary callables in scheduler and API server
Impact
Airflow rebuilt serialized exception nodes by importing whatever class name the blob named and instantiating it with the blob's own arguments. A Dag author can steer that through an operator's executor_config, so code of their choosing is imported and invoked inside the Scheduler during its ordinary Dag-reconstruction loop, and inside the API server on any authenticated read such as GET /api/v2/dags/{dag_id}/details. Both processes hold the metadata database credentials and the JWT signing secret, and Airflow's own security model says neither may ever run Dag-author code. On a shared GPU cluster where every ML team can commit Dags, that converts Dag-write access into control of the orchestrator that schedules work onto the accelerators. Note this is a different sink from CVE-2026-33264 - a deployment patched for that advisory is still exposed here.
Who can reach it
Any authenticated user who can author or modify a Dag - in most deployments every pipeline owner. No non-default configuration is required; the scheduler reaches the sink on its own, and the API server on a normal authenticated Dag detail read.
What to do
Upgrade to apache-airflow 3.3.1 or later, which constrains the imported class to a subclass of BaseException, then restart the scheduler and the API server. Control-plane restart only - no GPU node drain or reboot. Because the scheduler held the metadata DB credentials and the JWT signing secret, rotate both if you cannot rule out exposure, and re-check the fix even if you already patched CVE-2026-33264.
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.