CVE-2026-82355
MediumCVSS 4.2Summary
In Apache Airflow 3.3.0 and 3.3.1, there is an authentication precedence issue: when a request carries both a session cookie and an explicit Bearer token, Airflow resolves the caller from the cookie and ignores the token. This causes the request to execute as the cookie's principal rather than the token identity, leading to misattributed audit records.
Risk Assessment
Potential impersonation of another user if an attacker can place a cookie in the victim's browser, leading to unauthorized actions and incorrect audit logging.
Recommendation
Upgrade Apache Airflow to version 3.3.2 or later, which fixes the issue.
Other vulnerabilities in Apache Airflow
See all- CVE-2026-75158Medium
The /assets/events API in Apache Airflow returns asset events for all DAGs without filtering according to the caller's permissions. Any authenticated user with asset-read access can enumerate events, including source DAG IDs, task IDs, run IDs, and timestamps, for DAGs they are not authorized to see. Even the total_entries and pagination disclose the existence of hidden DAGs.
- CVE-2025-68438High
In Apache Airflow versions before 3.1.6, when rendered template fields in a Dag exceed [core] max_templated_field_length, sensitive values could be exposed in cleartext in the Rendered Templates UI. This occurred because serialization of those fields used a secrets masker instance that did not include user-registered mask_secret() patterns, so secrets were not reliably masked before truncation and display. Users are recommended to upgrade to 3.1.6 or later, which fixes this issue.
- CVE-2026-86473Critical
In Apache Airflow, the Core API logout endpoint revokes only a session token presented as the _token cookie. When a client logs out by presenting its credential as an Authorization bearer header instead, the endpoint returns its normal logout response but revokes nothing, so the token remains valid until it expires (default lifetime 24 hours, configurable).
- CVE-2026-33264Critical
A bug in `BaseSerialization.deserialize()` allowed unrestricted `import_string()` of attacker-controlled class paths when the Scheduler / API Server loaded a serialized DAG. A DAG author could embed a malicious trigger into a DAG to gain remote code execution on the API Server / Scheduler process, crossing the Airflow security boundary.
- CVE-2026-42252Critical
Apache Airflow documentation contained a `BashOperator` code example without proper quoting, allowing shell metacharacter injection via the `conf` field in the DAG trigger API. An authenticated user with `Dag.can_trigger` permission could execute arbitrary commands on the worker.
- CVE-2020-13927CriticalActively exploited
The previous default setting for Airflow's Experimental API was to allow all API requests without authentication, but this poses security risks to users who miss this fact. From Airflow 1.10.11 the default has been changed to deny all requests by default and is documented at https://airflow.apache.org/docs/1.10.11/security.html#api-authentication. Note this change fixes it for new installs but existing users need to change their config to default `[api]auth_backend = airflow.api.auth.backend.deny_all` as mentioned in the Updating Guide: https://github.com/apache/airflow/blob/1.10.11/UPDATING.md#experimental-api-will-deny-all-request-by-default
- CVE-2020-11978HighActively exploited
An issue was found in Apache Airflow versions 1.10.10 and below. A remote code/command injection vulnerability was discovered in one of the example DAGs shipped with Airflow which would allow any authenticated user to run arbitrary commands as the user running airflow worker/scheduler (depending on the executor in use). If you already have examples disabled by setting load_examples=False in the config then you are not vulnerable.
- CVE-2026-75157Low risk· EPSS 7%
Apache Airflow's asset queued-events DELETE endpoints checked the caller's Dag-axis permission with READ instead of EDIT. Any authenticated user who could read a Dag could delete that Dag's queued asset events, silently suppressing asset-triggered scheduling.
- CVE-2026-68971Medium
In Apache Airflow, the asset materialization endpoint (`POST /api/v2/assets/{asset_id}/materialize`) and the XCom result check on `wait_dag_run_until_finished` authorized the target Dag without its team, unlike every other authorization site. In multi-team mode with a team-aware auth manager, an authenticated user in one team could trigger Dag runs belonging to another team, supplying their own `dag_run_id` and `conf`, and could read another team's XCom values. Deployments using the FAB auth manager are unaffected. Users are advised to upgrade to apache-airflow 3.3.1 or later.
- CVE-2026-68970Medium
In Apache Airflow, the Task SDK did not mask the contents of a Variable whose JSON value is a list, so secrets stored in that shape appeared in cleartext in task logs and in the Rendered Templates UI. Masking was applied only when the deserialized value was a string or a dict; a list at the top level matched neither and was returned unmasked. Any authenticated user able to read the logs or rendered templates of a task that references such a Variable could recover the values, with no special configuration required. This is the list-shaped counterpart of CVE-2026-59244, whose fix covered the dict case only, so deployments that upgraded in response to that advisory remain affected and must upgrade again. Users are advised to upgrade to apache-airflow 3.3.1 or later.
Original NVD description (English source)
When a request to the Airflow core API carries both a session cookie and an explicit `Authorization: Bearer` token, Airflow resolves the caller from the cookie and ignores the bearer token, inverting the intended precedence of bearer over cookie. The request then executes -- and is recorded in the audit log -- as the cookie's principal rather than the identity the client explicitly presented. Only Apache Airflow 3.3.0 and 3.3.1 are affected. Earlier releases do not contain the code path that caches the cookie-derived user, and are not vulnerable. Exploiting this requires an attacker to first place a valid session cookie of their own into the victim's browser or client: for example by cookie tossing from a sibling subdomain, through cross-site scripting in a separate application sharing a parent domain, or via a shared workstation. Deployments that host the Airflow UI on a domain shared with other applications are therefore the most exposed; a deployment on a dedicated domain with no co-hosted applications is not reachable this way. The consequence is principal confusion and misattributed audit records rather than a direct privilege escalation. Users of 3.3.0 or 3.3.1 should upgrade to Apache Airflow 3.3.2 or later, which resolves the caller from the explicitly supplied credential whenever one is present.