CVE-2026-82310: Apache Airflow FAB provider: FAB auth manager: deactivated users retain and renew Core API JWT access

Published Sep 15, 2026
·
Updated

Apache Airflow FAB provider: deactivating a user account does not stop tokens issued to that account before deactivation. Password authentication correctly rejects the disabled account, but the Core API continues to accept an existing, unexpired token naming it, and lets that token mint a replacement — so the account keeps its role-scoped access indefinitely after an administrator has disabled it. The user replays their own legitimate credential; no signature forgery or privilege escalation is involved, and the access stays within the roles the account already held.

Affects deployments using Airflow 3 with the FAB auth manager and Core API token authentication, where an administrator deactivates an account whose row remains in the database and whose previously issued token has not expired. The trigger is administrative deactivation as a containment action, which silently fails to contain.

Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account.

Affected Software

2 affected components
apache-airflow-providers-fab<3.9.0
Apache Airflow=3

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade apache-airflow-providers-fab to a version that resolves this vulnerability.

    Fixed in 3.9.0
  2. Compensating control

    For deployments affected by CVE-2026-82310, treat administrative account deactivation as not reliably containing access for existing unexpired Core API JWTs; mitigate exposure by restricting/monitoring Core API token usage until upgraded.

Event History

Sep 16, 2026
CVE Published
via MITRE·09:09 AM
Data Sourced
via MITRE·09:09 AM
DescriptionWeakness

Frequently Asked Questions

1

Who is exposed to this issue?

Deployments using Airflow 3 with the FAB auth manager and Core API token authentication are affected when an administrator deactivates an account that remains in the database and has a previously issued, unexpired token.

2

What does an attacker need to continue accessing the Core API?

The attacker needs an existing legitimate, unexpired token issued to their own account before it is deactivated. They do not need to forge a signature or gain privileges beyond the roles already assigned to that account.

3

Does deactivating the account stop password-based access?

Yes. Password authentication rejects the disabled account, but an existing Core API token remains accepted and can be used to mint replacement tokens.

4

What should be done to remediate the issue?

Upgrade apache-airflow-providers-fab to version 3.9.0 or later. This version rejects tokens that name a deactivated account.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203