CVE-2026-82310: Apache Airflow FAB Auth Bypass Vulnerability

CVE-2026-82310 Overview

CVE-2026-82310 affects the Apache Airflow Flask AppBuilder (FAB) provider. Deactivating a user account fails to invalidate authentication tokens issued before the deactivation. Password authentication correctly rejects the disabled account, but the Core API continues to accept an existing unexpired token naming that account. The token can also mint a replacement, so the user retains role-scoped access indefinitely after an administrator disables the account. The weakness is classified as [CWE-613] Insufficient Session Expiration. Deployments running Airflow 3 with the FAB auth manager and Core API token authentication are affected.

Critical Impact
Administrative deactivation intended as a containment action silently fails, allowing a disabled user to retain full role-scoped API access and refresh tokens indefinitely.

Affected Products

Apache Airflow deployments using the FAB auth manager (Airflow 3)
apache-airflow-providers-fab versions prior to 3.9.0
Airflow Core API token authentication paths that accept FAB-issued tokens

Discovery Timeline

2026-09-16 - CVE-2026-82310 published to the National Vulnerability Database
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-82310

Vulnerability Analysis

The FAB provider issues bearer tokens that name the authenticating user. When an administrator deactivates that user, the FAB password login path checks the active flag on the account row and rejects new logins. The Core API token validation path does not perform the equivalent check. The token remains cryptographically valid and continues to authorize requests scoped to the roles the account held at issuance.

The replacement path amplifies the impact. A holder of a still-valid token can call the token refresh endpoint and receive a new token, extending access beyond the original expiry. No signature forgery, credential theft, or privilege escalation is required. The disabled user replays their own legitimate credential and retains their existing role scope.

Root Cause

The root cause is missing state validation during token acceptance. The FAB provider validates token signature, expiry, and claims but does not re-check whether the referenced account is still active in the database. Session and token lifecycle are decoupled from account lifecycle, producing the [CWE-613] insufficient session expiration condition. Deactivation is treated as a login-time concern rather than a request-time authorization concern.

Attack Vector

The attack requires no exploitation skill. An administrator flags a user as inactive as a containment or offboarding action. The affected user, retaining a previously issued token, continues issuing API calls against the Core API. The user can also call the refresh endpoint to mint a new token that carries the same role scope. Access persists until the original token would have expired had refresh not been used, or indefinitely if the user keeps refreshing. See the GitHub Pull Request #72199 for the corrective change and the Openwall OSS Security Update for the coordinated disclosure notice.

Detection Methods for CVE-2026-82310

Indicators of Compromise

Core API requests authenticated as a user whose active flag is false in the FAB user table
Token refresh calls (/auth/token/refresh or equivalent) originating from an account marked deactivated
Successful API operations attributed to users after their audit-logged deactivation event
Divergence between the FAB login audit trail (rejecting a user) and the Core API access log (accepting the same user)

Detection Strategies

Correlate the FAB user status table against Core API access logs to flag requests naming inactive accounts
Alert on any token refresh request whose subject claim matches a user in a deactivated state
Baseline expected API activity per user and generate alerts on continued activity after administrative deactivation events

Monitoring Recommendations

Forward Airflow Core API logs and FAB admin action logs to a centralized SIEM for cross-source correlation
Track administrative deactivation events as high-value telemetry and pivot on the affected username for the following 24 hours
Monitor role-scoped API calls (DAG triggers, connection reads, variable access) attributed to recently deactivated users

How to Mitigate CVE-2026-82310

Immediate Actions Required

Upgrade apache-airflow-providers-fab to version 3.9.0 or later, which rejects tokens naming a deactivated account
Enumerate all currently deactivated users and revoke or rotate the signing key material used for their outstanding tokens
Audit Core API access logs for activity attributed to deactivated users since their deactivation timestamp
Treat prior deactivation actions as incomplete containment and repeat any dependent response steps

Patch Information

The Apache Airflow project resolved the issue in apache-airflow-providers-fab version 3.9.0. The fix adds an account-state check in the Core API token validation path so tokens naming a deactivated user are rejected. Details are available in GitHub Pull Request #72199 and the Apache Mailing List Thread.

Workarounds

Delete the user row rather than deactivating it, accepting the loss of audit continuity, until the patched provider is deployed
Rotate the FAB token signing secret after any deactivation event to invalidate all outstanding tokens for every user
Shorten Core API token lifetime and disable refresh to bound the window of retained access after deactivation
Restrict Core API network exposure so token replay from outside trusted networks is blocked

bash

# Upgrade the FAB provider to the patched release
pip install --upgrade 'apache-airflow-providers-fab>=3.9.0'

# Verify installed version
pip show apache-airflow-providers-fab | grep Version