CVE-2026-82310
Low risk· EPSS 17%Exploitation Probability (EPSS)
Low risk17th percentile - higher than 17% of all known CVEs
Summary
In Apache Airflow FAB provider, deactivating a user account does not invalidate previously issued tokens. These tokens remain valid and can be used to gain access even after the account is deactivated by an administrator.
Risk Assessment
Account deactivation as a containment measure does not work, potentially leading to unauthorized access by deactivated accounts.
Recommendation
It is recommended to upgrade apache-airflow-providers-fab to version 3.9.0 or later, which rejects tokens for deactivated accounts.
Other vulnerabilities in Apache Airflow FAB provider
See all- CVE-2026-75156Critical
Apache Airflow FAB provider versions 3.7.3 through 3.8.0 do not validate the issuer or audience of Azure AD `id_token`s during OAuth login. Deployments are affected only when the FAB auth manager is configured with Azure AD as an OAuth provider. Because the signing keys are fetched from Microsoft's multi-tenant JWKS endpoint, an `id_token` minted in any Azure tenant — including one the attacker creates — passes signature verification, and the username and role assignments are then read from that attacker-controlled token. Anyone able to register an Azure tenant can therefore authenticate to the Airflow UI with no prior access to the deployment.
- CVE-2026-86466Low risk· EPSS 4%
Apache Airflow FAB provider: the Authentik OAuth path in the FAB auth manager does not validate the issuer or audience claims of the id_token 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.
- CVE-2026-86462Low risk· EPSS 9%
In the Apache Airflow FAB provider, changing a user's password via the Admin user-edit PATCH endpoint does not invalidate that user's existing database-backed sessions. An attacker holding a copy of the victim's session cookie retains full access after the password change.
- CVE-2026-82311Low risk· EPSS 9%
In the Apache Airflow FAB provider, resetting a user's password does not delete that user's existing database-backed sessions, despite documented behaviour. The cleanup compares a string session identifier with the user's integer database identifier, so the comparison never matches and no session is removed, leaving an attacker with a copied cookie still authenticated.
Original NVD description (English source)
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.