GPU VulnDB

Database/Control plane, storage & DevOps

Airflow FAB provider: password change through the Admin PATCH endpoint does not evict existing sessions

CVSS 9.1CVE-2026-86462Control plane, storage & DevOpscurated

Impact

Changing a user's password through the Admin user-edit PATCH endpoint leaves that user's database-backed sessions valid. An attacker holding a stolen session cookie keeps full access as that user after the reset, so the standard incident response for a compromised Airflow account - rotate the password - does not actually remove the intruder. That matters on a GPU fleet because the Airflow account can hold DAG-editing or connection-editing rights, which are a path to code execution on workers and, in some configurations, on the scheduler. This is a second, independent route to the outcome addressed by CVE-2026-82311: that fix corrected an identifier comparison in the session-invalidation helper, but the PATCH path never calls the helper, so deployments that applied it are still exposed.

Who can reach it

Remote attacker who already holds a copy of a victim's Airflow session cookie. No interaction with the vulnerable endpoint is needed by the attacker - the routine password change by an admin or the user themselves is the trigger. Affects deployments using the FAB auth manager with database-backed sessions.

What to do

Upgrade apache-airflow-providers-fab to 3.9.0 or later and restart the webserver / API server. Applying the CVE-2026-82311 fix alone is not sufficient. For any account suspected compromised before upgrading, purge its rows from the session table directly rather than relying on the password change. Package upgrade plus a daemon restart.

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.