Pierre Jeambrun

Apache Airflow's logout endpoint attempted to revoke the presented token on the server, but any failure during revocation was silently ignored and logout still reported success. When the auth manager redirects logout to an external logout URL (for example the FAB or Keycloak auth managers), server-side revocation is the only thing that invalidates the Airflow token; it failed on database errors and, reliably, for tokens from an external issuer accepted via `[api auth] trusted jwks url` whose token identifier is longer than 32 characters. Anyone holding a copy of a user's token from before logout could keep using it against the Airflow API until it expired. Users are advised to upgrade to apache-airflow 3.4.0 or later.

The Event Log detail endpoint "GET /api/v2/eventLogs/{event log id}" fetches audit-log rows directly by numeric ID after performing only a generic Audit Log permission check. This differs from the collection endpoint "GET /api/v2/eventLogs", which applies per-Dag scoping. Consequently, an authenticated UI or API user with audit-log read permission for a single Dag can retrieve audit-log entries for any other Dag by guessing or enumerating the `event log id` variable.

A user with asset materialize permission via the UI or API can trigger DAGs (Directed Acyclic Graphs, which are collections of all the tasks you want to run, organized in a way that reflects their relationships) to which they do not have access.

The FastAPI DagVersion listing API in Apache Airflow does not enforce per-DAG authorization filtering when a request is made with the `dag id` parameter set to '~' (wildcard for all DAGs). This allows the retrieval of version metadata for DAGs that the requesting user is not authorized to access.