CVE-2026-82311
Low risk· EPSS 9%Exploitation Probability (EPSS)
Low risk9th percentile - higher than 9% of all known CVEs
Summary
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.
Risk Assessment
If a session cookie is compromised, a password reset does not evict the attacker, allowing continued unauthorized access to the victim's account.
Recommendation
Upgrade apache-airflow-providers-fab to version 3.9.0 or later, which compares identifiers consistently and also fixes CVE-2026-86462. Applies to deployments with `[fab] session_backend=database`.
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-82310Low risk· EPSS 17%
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.
- 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.
Original NVD description (English source)
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] session_backend=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.

