mediumCVE-2026-49296

CVE-2026-49296 Apache Airflow vulnerability

Before apache-airflow 3.3.0, a user authorized to read one Dag could disclose the source of other Dags co-located in the same source file. `GET /api/v2/dagSources/{dag_id}` — and the equivalent Dag-source view in the UI — returned the entire source file without redacting Dags the caller was not authorized to read, bypassing per-DAG read authorization. Deployments that co-locate multiple Dags in a single file and rely on per-DAG access control to limit source visibility are affected; single-Dag-per-file deployments are not. Upgrade to apache-airflow 3.3.0 or later.

ProductApache Airflow
CVSS6.5
EPSS0.00601
UpdatedJuly 12, 2026

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-49296 affects Apache Airflow deployments before 3.3.0 where Dag source endpoints can disclose other DAGs co-located in the same source file to a user authorized to read only one DAG. 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-49296, the advisory identifies that release as the fixed version. Until the upgrade is complete, restrict UI/API permissions and remove sensitive data from exposed views where practical.

  1. Inventory Apache Airflow webservers, API servers, schedulers, workers, containers, Helm charts, constraints files, and provider package deployments.
  2. Identify apache-airflow versions before 3.3.0 and schedule an upgrade to apache-airflow 3.3.0 or later for CVE-2026-49296.
  3. Upgrade Airflow through the supported deployment method, rebuild images, migrate the metadata database if required, and restart webserver, API, scheduler, triggerer, and worker components.
  4. Tighten Airflow UI/API permissions for DAG source, Config, Variables, task-instance, and dependency views while remediation is pending.
  5. Review DAG files, Variables, Connections, trigger kwargs, secrets-backend configuration, and per-DAG access controls for sensitive data that should not be exposed.
  6. 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.
  7. 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 /api/v2/dagSources/{dag_id} and the UI source view return only DAG source content authorized for the caller.
  • 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-49296?

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.