Executive brief
Apache Airflow's FAB authentication provider manages user access control for the Airflow workflow orchestration platform. When an administrator deactivates a user account to revoke access, password-based login correctly rejects the disabled user; however, existing API tokens issued before deactivation continue to work and can mint replacement tokens indefinitely. This silent failure to revoke issued tokens means terminated employees or suspended accounts retain full operational access to Airflow workflows and data indefinitely.
Technical details
The vulnerability is a token revocation failure in Apache Airflow's FAB (Flask-AppBuilder) authentication manager. The FabAuthManager.deserialize_user function resolves tokens using only the user ID without checking whether the account is deactivated, allowing expired-but-unreplaced tokens to remain valid. An attacker with a previously issued token for a deactivated account can replay that token to authenticate to the Core API, then use it to mint replacement tokens before expiration. The attack requires no privilege escalation or signature forgery—only replay of the attacker's own legitimate token issued before deactivation. The fix, released in apache-airflow-providers-fab 3.9.0 and merged in Apache Airflow main branch on 2026-08-28, validates that the token subject refers to an active account.
Affected products
- Apache Airflow 3.x with FAB auth manager
- Apache apache-airflow-providers-fab before 3.9.0
Timeline
- 2026-09-16: disclosed: Published in NVD
- 2026-08-28: patched: Fix merged to Apache Airflow main branch (PR #72199); apache-airflow-providers-fab 3.9.0 or later contains the fix