CVE-2026-48892 Apache Airflow vulnerability
The Config API in Apache Airflow surfaced per-key secrets-backend overrides (environment variables like `AIRFLOW__SECRETS__BACKEND_KWARG__SECRET_ID` and `AIRFLOW__WORKERS__SECRETS_BACKEND_KWARG__SECRET_ID`) as synthetic config options whose option names were not in `sensitive_config_values`, so the masker did not redact them. An authenticated UI/API user with Config read permission could retrieve plaintext secrets-backend credentials (Vault `role_id` / `secret_id`, etc.) from the Config API output. Affects deployments that configure secrets backends via per-key environment overrides. Users are advised to upgrade to `apache-airflow` 3.3.0 or later.
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-48892 affects Apache Airflow deployments before 3.3.0 where the Config API can surface per-key secrets-backend environment overrides without redaction to users with Config read permission. 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-48892, 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-48892.
- 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 Config API output redacts secrets-backend overrides and other sensitive config option values.
- 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-48892?
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.