Apache Airflow FAB provider: deactivating a user account does not stop tokens issued to that account before deactivation. Password authentication correctly rejects the disabled account, but the Core API continues to accept an existing, unexpired token naming it, and lets that token mint a replacement — so the account keeps its role-scoped access indefinitely after an administrator has disabled it. The user replays their own legitimate credential; no signature forgery or privilege escalation is involved, and the access stays within the roles the account already held.
Affects deployments using Airflow 3 with the FAB auth manager and Core API token authentication, where an administrator deactivates an account whose row remains in the database and whose previously issued token has not expired. The trigger is administrative deactivation as a containment action, which silently fails to contain.
Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account.
Severity: moderate
Affected versions:
- Apache Airflow FAB provider (apache-airflow-providers-fab) before 3.9.0
Description:
Apache Airflow FAB provider: the Authentik OAuth path in the FAB auth manager does not validate the issuer or audience claims of the idtoken it accepts. An attacker holding a token that the same Authentik identity provider minted for a different client application can present it to Airflow and be authenticated as the user it names, because the audience claim is never checked. Affects deployments using the FAB auth manager with Authentik OAuth where the same Authentik instance also serves other applications; the attacker needs a valid token for any of those other applications, not for Airflow.
CVE-2026-75156 corrected the same missing validation on the Azure AD path in this file; the Authentik path was left unchanged and is fixed here. Deployments that applied the CVE-2026-75156 fix and use Authentik must also upgrade for this one.
Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which fixes the issue.
Credit:
Ritik Chaddha & NEO by ProjectDiscovery (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/72645 https://www.cve.org/CVERecord?id=CVE-2026-75156 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-86466
Severity: moderate
Affected versions:
- Apache Airflow FAB provider (apache-airflow-providers-fab) 3.2.0 before 3.9.0
Description:
Apache Airflow FAB provider: changing a user's password through the Admin user-edit PATCH endpoint does not invalidate that user's existing database-backed sessions. An attacker who already holds a copy of the victim's session cookie keeps full access as that user after the password change, so the password reset does not evict them. Affects deployments using the FAB auth manager with database-backed sessions; an administrator (or the user themselves) performing a routine password change is the trigger, and no attacker interaction with the endpoint is needed.
This is a second, independent route to the outcome addressed by CVE-2026-82311, which corrected an identifier comparison in the session-invalidation helper. That fix does not repair this endpoint, because the PATCH path never calls the helper at all. Deployments that applied the CVE-2026-82311 fix must also upgrade for this one.
Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which fixes the issue.
Credit:
OpenSec Intelligence (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/72657 https://www.cve.org/CVERecord?id=CVE-2026-82311 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-86462
Severity: moderate
Affected versions:
- Apache Airflow FAB provider (apache-airflow-providers-fab) 2.4.2 before 3.9.0
Description:
Apache Airflow FAB provider: resetting a user's password does not delete that user's existing database-backed sessions, despite documented behaviour that it does. The cleanup compares the string identifier Flask-Login stores in the session against the user's integer database identifier, so the comparison never matches and no session is removed. An attacker who already holds a copy of the victim's session cookie keeps access as that user after the password change, so the reset does not evict them.
Affects deployments using the FAB auth manager with [fab] sessionbackend=database. The trigger is an administrator (or the user) running the supported password-reset command as a containment action after a session cookie has been compromised; the secure-cookie backend is out of scope, as it documents that it cannot centrally delete sessions.
apache-airflow-providers-fab 3.9.0 also fixes CVE-2026-86462, a second, independent route to the same outcome via the Admin user-edit endpoint; a single upgrade closes both.
Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which compares the identifiers consistently.
Credit:
Mayank Jangid (OpenSec) (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/72198 https://www.cve.org/CVERecord?id=CVE-2026-86462 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-82311
Severity: moderate
Affected versions:
- Apache Airflow FAB provider (apache-airflow-providers-fab) 2.0.0 before 3.9.0
Description:
Apache Airflow FAB provider: deactivating a user account does not stop tokens issued to that account before deactivation. Password authentication correctly rejects the disabled account, but the Core API continues to accept an existing, unexpired token naming it, and lets that token mint a replacement — so the account keeps its role-scoped access indefinitely after an administrator has disabled it. The user replays their own legitimate credential; no signature forgery or privilege escalation is involved, and the access stays within the roles the account already held.
Affects deployments using Airflow 3 with the FAB auth manager and Core API token authentication, where an administrator deactivates an account whose row remains in the database and whose previously issued token has not expired. The trigger is administrative deactivation as a containment action, which silently fails to contain.
Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account.
Credit:
Mayank Jangid (OpenSec) (finder) Jarek Potiuk (remediation developer)
References:
https://github.com/apache/airflow/pull/72199 https://airflow.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-82310