CVE-2026-33264 Apache Airflow vulnerability
A bug in `BaseSerialization.deserialize()` allowed unrestricted `import_string()` of attacker-controlled class paths when the Scheduler / API Server loaded a serialized DAG: a DAG author could embed a malicious trigger into a DAG to gain remote code execution on the API Server / Scheduler process, crossing the Airflow security boundary that DAG-author code must never execute in those processes. Users are advised to upgrade to `apache-airflow` 3.3.0 or later. As a defense-in-depth mitigation, deployments where DAG-author trust is limited can restrict the `[core] allowed_deserialization_classes` config to a narrow allowlist.
Quick answer
Apache Airflow should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.
Who is affected
Affected versions
- apache-airflow <3.3.0
Fixed versions
- 3.3.0
How to fix it
CVE-2026-33264 affects Apache Airflow deployments before 3.3.0 where BaseSerialization.deserialize can import attacker-controlled class paths from serialized DAG content, allowing a DAG author to execute code in API Server or Scheduler processes. Prioritize shared Airflow environments, multi-team DAG repositories, public or broadly accessible UI/API endpoints, and deployments that store secrets in Airflow Variables or configuration. Upgrade apache-airflow to 3.3.0 or later; for CVE-2026-33264, the advisory identifies that release as the fixed version. As defense in depth, restrict allowed_deserialization_classes to a narrow allowlist where DAG author trust is limited.
- Inventory Apache Airflow webservers, API servers, schedulers, workers, containers, Helm charts, constraints files, and provider package deployments.
- Identify apache-airflow versions before 3.3.0 and schedule an upgrade to apache-airflow 3.3.0 or later for CVE-2026-33264.
- Upgrade Airflow through the supported deployment method, rebuild images, migrate the metadata database if required, and restart webserver, API, scheduler, triggerer, and worker components.
- Restrict [core] allowed_deserialization_classes to a narrow allowlist where DAG author trust is limited, and review DAG author permissions.
- Review DAG files, Variables, Connections, trigger kwargs, secrets-backend configuration, and per-DAG access controls for sensitive data that should not be exposed.
- Review webserver/API audit logs, scheduler logs, DAG parse logs, and access logs for suspicious API reads, unexpected DAG-source access, secret exposure, or deserialization errors.
- If secrets or code execution are suspected, rotate exposed credentials, revoke sessions and tokens, remove malicious DAG content, and preserve audit evidence before cleanup.
Scan now. Google sign-in is only needed to unlock fix guidance.
Verify the fix
- Confirm all Airflow components report apache-airflow 3.3.0 or later and that old images or virtual environments are no longer in service.
- Confirm serialized DAG deserialization is restricted to the patched allowlist behavior and unapproved class paths are rejected.
- Confirm UI/API permissions match the intended per-DAG and role-based policy, and sensitive values are masked or inaccessible to unauthorized users.
- Run DAG parse tests, scheduler smoke tests, API checks, and dependency/container scans to confirm the patched deployment is healthy and no vulnerable package remains.
- Document package versions, image digests, database migration status, permission tests, secret rotation, and log review evidence.
Related categories
Trusted references
FAQ
What is affected by CVE-2026-33264?
Apache Airflow versions listed as affected should be reviewed: apache-airflow <3.3.0.
What should I fix first?
Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.
How do I confirm the fix worked?
Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.
How are Fixnx security risk categories chosen?
Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.