Resetting a user's password in the Apache Airflow FAB provider does not invalidate existing database‑backed sessions because the cleanup logic compares a string session identifier stored by Flask‑Login with an integer user identifier in the database, causing the comparison to always fail. As a result, an attacker who has a valid session cookie can continue to act as that user even after a password reset. This flaw violates the documented expectation that a password reset should revoke all active sessions, exposing the account to persistent unauthorized access.

The vulnerability affects deployments that use the FAB authentication manager with the database session backend (the default when `[fab] session_backend=database` is configured). Any installation of apache‑airflow‑providers‑fab prior to version 3.9.0 is susceptible. The issue does not apply to the secure‑cookie backend, which is explicitly acknowledged as incapable of centrally deleting sessions. Versions 3.9.0 and later include a fix that consistently compares identifiers and removes compromised sessions after a password reset.

Exploitation requires an attacker to possess a valid session cookie; simply resetting the password does not provide new access. The EPSS score of < 1 % indicates a very low probability of widespread exploitation, yet the CVSS score of 9.8 reflects the severe impact if an account is already compromised. The flaw is not listed in CISA’s KEV catalog, but it remains a high‑risk condition for any account that has had a session stolen. Attackers commonly obtain session cookies through phishing, web‑application attacks, or social engineering, and then trigger a password reset via an admin or the user themselves, enabling permanent session persistence.