CVE-2026-48891 Apache Airflow vulnerability
A bug in Apache Airflow's `/ui/dependencies` scheduling graph endpoint applied the caller's readable-Dag filter to the top-level serialized Dag key but still emitted referenced Dag IDs through the `dep.source` and `dep.target` fields of trigger / sensor dependency entries. An authenticated UI user with read permission on some Dags could enumerate the identifiers of other Dags they were not authorized to read by inspecting the dependency graph for trigger / sensor references. Affects deployments that rely on per-Dag read scoping to keep Dag identifiers private across teams. This is a residual gap in the fix for CVE-2026-28563, which filtered the top-level Dag key but did not propagate the filter into the trigger / sensor dep-source / dep-target fields. Users who already upgraded for CVE-2026-28563 should additionally upgrade to `apache-airflow` 3.3.0 or later to cover the residual trigger / sensor dependency leak.
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-48891 affects Apache Airflow deployments before 3.3.0 where the /ui/dependencies scheduling graph endpoint can leak DAG identifiers through trigger and sensor dependency fields despite per-DAG read scoping. 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-48891, 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.
- 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-48891.
- Upgrade Airflow through the supported deployment method, rebuild images, migrate the metadata database if required, and restart webserver, API, scheduler, triggerer, and worker components.
- Tighten Airflow UI/API permissions for DAG source, Config, Variables, task-instance, and dependency views while remediation is pending.
- 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 dependency graph responses filter dep.source and dep.target values according to the caller’s DAG read permissions.
- 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-48891?
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.