According to the Apache Airflow supported versions page, Airflow 2 is marked EOL, with limited maintenance having started on October 22, 2025 and end of life on April 22, 2026. EOL versions get no fixes or support. If you still run 2.x, plan a move to Airflow 3 and treat the gap as open risk.
What the support table says
The project publishes a table of versions. For the 2.x line, the latest patch listed is 2.11.2, the first release was December 17, 2020, limited maintenance began October 22, 2025, and EOL is April 22, 2026. Airflow 3 is listed in the Maintenance state.
The page defines the phases plainly. Limited support versions get "security and critical bug fixes only". EOL versions get no fixes or support. The project recommends running the latest release.
What EOL means for your risk
Once a version is EOL, a newly found vulnerability in Airflow core will not be fixed for that line. Your scanner may still report it, or it may report nothing, because an advisory for an unsupported version is not guaranteed to be published. No advisory is not the same as safe.
Provider packages are a separate matter. They are released and versioned separately from Airflow core, so a provider can still get updates. But the same page notes that provider upgrades are not guaranteed to work with every core version, so an old core can hold providers back.
Also check the layers under Airflow. The support page says Python and Kubernetes versions are dropped from Airflow when they reach their own end of life, so an old Airflow often pins you to an old Python.
A migration plan in five steps
- Inventory. List every Airflow deployment, its version, its Python version and its providers. Include dev and staging.
- Rank by exposure. Deployments reachable by many users, or holding production credentials, go first.
- Read the release notes for the version you are moving to. Plan for breaking changes in DAG code and configuration.
- Build the new environment from the project's constraint file for the exact version and your Python version, then run your DAGs there before cutting over.
- Set an owner and a date. A "someday" upgrade is how a deployment becomes the one nobody remembers.
If you cannot move yet
Some teams cannot migrate this quarter. Reduce exposure while you wait:
- Keep the web interface off the public internet.
- Limit who can author DAGs, because DAG authors run code.
- Keep providers current where they still receive fixes.
- Write the exception down with an owner and an end date.
Keeping track of the dates
The risk of EOL surprises is mostly bookkeeping. Record the version and the end date of each runtime in your inventory, and review it on a schedule. Dates on project pages can change, so confirm them on the source page before you put them in a risk register.
Safeguard's asset discovery and SBOM scanning can list which services run which framework versions, and its policies can flag components past their support date. The free scan at https://gold.safeguard.sh/scan is a quick starting point.
Quick check
Do EOL Airflow versions get security fixes?
No. The support page says EOL versions get no fixes or support. Only limited support versions get security and critical fixes.
Does my scanner showing no Airflow findings mean 2.x is safe?
Not necessarily. An unsupported version may have problems that never get an advisory or a fix, so rely on the support status too.
Sources
Last reviewed: 19 October 2026.
