CVE-2026-58076 is a high severity unsafe deserialization flaw in Apache Airflow. A Dag author can make the Scheduler and API server import and call an arbitrary callable through the executor_config exception branch. Upgrade to apache-airflow 3.3.1 or later, even if you already patched CVE-2026-33264.
What's affected
- Product: Apache Airflow, serialization layer.
- Fixed: apache-airflow 3.3.1 or later, which restricts the imported class to a subclass of BaseException, per the record.
- Affected range: the record does not list the first affected version. Check the Apache Airflow security advisories for the exact range.
- Already upgraded for CVE-2026-33264? That fix covered only the trigger branch of the same deserializer. The record says those deployments are still affected through the exception branch and must upgrade again.
- No non-default configuration is required.
How to check if you're exposed
Check the installed version.
pip show apache-airflow
airflow version
Compare it with 3.3.1. Do this on every component, not only the web service: the Scheduler and the API server are the components that deserialize Dags, so both need the fix.
Then review who can write Dags. The attack needs a Dag author, so list the people and automation that can commit to your Dag repository or upload Dag files.
What to do now
- Upgrade every Airflow component to apache-airflow 3.3.1 or later.
- If you upgraded earlier for CVE-2026-33264, upgrade again. That fix did not cover this branch.
- Tighten who can add or change Dag files, and review recent changes for unexpected executor_config values.
- Rotate the metadata database credentials and the JWT signing secret if you have reason to think an untrusted Dag author had access.
- Keep the Scheduler and API server on least privilege network access, because both hold those secrets.
- Run the free in-browser dependency scan on your lockfile or manifest to see every affected package in one pass.
Why it matters
The weakness is CWE-502 (Deserialization of Untrusted Data). The serialization layer rebuilt exception nodes by calling import_string() on a class name from the stored blob and instantiating it with arguments from the same blob, with no limit on what could be imported. An operator's executor_config reaches that branch.
What makes it serious is where the code runs. The record says it runs in the Scheduler as part of its normal loop, and in the API server on any authenticated read of the Dag. Airflow's own security model says neither should run Dag author code, and both hold database credentials and the signing secret. The pull request fixes it by resolving exception classes against classes already in memory instead of importing the stored name. The record scores it 8.8 (High) and does not mark it as exploited in the wild.
Try it yourself
Many Airflow flaws only matter if the vulnerable path is reachable in your deployment. This demo shows how reachability analysis separates reachable findings from the rest.
Click through it at your own pace, or open it full screen.
Quick check
I fixed CVE-2026-33264. Am I covered?
Not according to the record. CVE-2026-33264 covered the trigger branch. This CVE is a different sink in the same deserializer, so upgrade to 3.3.1 or later.
Sources
Last reviewed: 18 October 2026.
