CVE-2026-24098

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).

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.

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.

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.

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.

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.

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.

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.