GPU VulnDB

Database/Control plane, storage & DevOps

Airflow FAB provider: password reset fails to evict existing sessions, so a stolen cookie keeps working

CVSS 9.8CVE-2026-82311Control plane, storage & DevOpscurated

Impact

With the FAB auth manager and [fab] session_backend=database, resetting a user's password is documented to drop that user's existing sessions, but the cleanup compares Flask-Login's string identifier against the integer database id, so it never matches and no session is deleted. The practical consequence is that the standard containment action after a stolen Airflow session cookie does not contain anything: whoever holds the cookie keeps acting as that user - triggering DAGs, reading connections, editing pipeline code paths - while the operator believes access was revoked. On a GPU fleet where Airflow schedules training and data movement, that is a false sense of having closed an incident.

Who can reach it

An attacker who already holds a copy of a victim's Airflow session cookie. No new access is gained by this flaw; it defeats the revocation step. Deployments using the secure-cookie backend are out of scope, since that backend documents that it cannot delete sessions centrally.

What to do

Upgrade apache-airflow-providers-fab to 3.9.0 or later, which compares the identifiers consistently; the same release also fixes CVE-2026-86462, an independent route to the same outcome through the Admin user-edit endpoint. Provider package upgrade plus a webserver restart. Until then, contain a compromised session by deleting the user's rows from the session table directly or rotating the Airflow secret key, rather than relying on the password reset.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.