Opensec Intelligence

Apache Airflow's CLI records its arguments in the audit log but masks secrets by argument position, so some supported command shapes leave secrets in cleartext, for example a trailing `--description` on Variable commands, `--conn-extra`, and the inline `--password` of `airflow keycloak-auth-manager` commands. A user who can read audit events but is denied Variable and Connection access can retrieve those values through the event-log API. Users of apache-airflow are recommended to upgrade to 3.4.0 or later. Audit-log entries written before the upgrade keep the cleartext values: purge the affected entries and rotate the secrets they contain. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later.

Multi-team provisioning in the Apache Airflow Keycloak provider allows every team role to have global read access to audit logs. This occurs within the ` attach team permissions()` function. In deployments where multi-team mode is enabled using the Keycloak auth manager for team provisioning, any authenticated member of a team can access audit events belonging to other teams via the user interface or the event-log API endpoint.

The Core API logout endpoint only revokes session tokens provided via the ` token` cookie. If a client uses an Authorization bearer header for authentication during logout, the endpoint returns a successful response without revoking the token. This allows the token to remain valid until its expiration, which is 24 hours by default. An attacker possessing a copy of this token can maintain access to the victim's account even after the victim has logged out.

Changing a user password via the Admin user-edit PATCH endpoint fails to invalidate existing database-backed sessions. This allows an attacker possessing a victim's session cookie to maintain full access to the account even after a password reset. This issue specifically affects deployments using the FAB auth manager with database-backed sessions. The trigger is a routine password change performed by an administrator or the user, requiring no direct interaction from an attacker with the endpoint.