Database/Control plane, storage & DevOps

Airflow FAB provider: deactivated accounts keep working through already-issued API tokens

CVSS 7.2CVE-2026-82310Control plane, storage & DevOpscurated

Impact

Disabling an Airflow account is the standard containment step when a pipeline operator leaves or an account is suspected compromised. Here it silently fails: the Core API keeps accepting an unexpired token naming the deactivated user, and that token can mint a replacement, so access persists indefinitely at the roles the account already held. On a GPU fleet Airflow is usually the thing that submits training and batch inference DAGs, so the retained access means continued ability to schedule work on expensive accelerators, read connection-scoped data, and trigger pipelines the operator believed were cut off. There is no privilege escalation and no forged signature - the holder simply replays a credential that was supposed to be dead.

Who can reach it

Authenticated - the holder of a previously issued Core API token for an account an administrator has since deactivated. Network reach to the Airflow Core API is enough; no new credentials are needed.

What to do

Upgrade apache-airflow-providers-fab to 3.9.0 or later, which rejects tokens naming a deactivated account, and restart the Airflow API server / webserver. Until then, treat deactivation as insufficient: delete the user row or rotate the API signing secret to invalidate outstanding tokens, accepting that rotation logs out every user. Scheduler and workers do not need to be touched.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-82310 https://github.com/apache/airflow/pull/72199 https://lists.apache.org/thread/85h9r50bmy8vgkgr5nyddryj1p5pxxy2 http://www.openwall.com/lists/oss-security/2026/09/15/10

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.