Apache Airflow FAB CVE-2026-82310

Requires Airflow 3 deployed with the FAB auth manager AND Core API token authentication enabled. The attacker must already hold a valid, unexpired token that was legitimately issued to the account while it was still active, and the deactivated account's row must remain in the database (deactivated, not deleted). Exploitation is triggered specifically after an administrator deactivates the account; the actor is effectively the deactivated account holder replaying their own credential. Limiting factors: access is strictly bounded to the roles the account already held (no escalation), the token must not have expired, and it does not affect deployments that delete accounts rather than deactivate them or that do not use Core API token auth. PR:H reflects that a valid pre-issued account credential is a prerequisite.

This is a genuine but bounded security-hygiene defect, not a top-tier emergency. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H = 7.2 High) is internally consistent and honest: PR:H correctly reflects that the actor must already possess a valid, unexpired token issued to the account before deactivation - i.e. they are effectively the account holder, not an outside attacker. EPSS is low (0.25%, 16th percentile), there is no CISA KEV listing, and no public exploit code was identified - signals that align with the intrinsic nature of the bug (it is a containment-failure exploitable only by the very insider being contained, not a mass-exploitable remote flaw). The description explicitly states 'no signature forgery or privilege escalation is involved' and access 'stays within the roles the account already held,' which contradicts the input 'Privilege Escalation' tag and confirms this is a session/token-expiration failure (CWE-613), not an escalation primitive. No SSVC decision data was provided. Real-world priority is moderate and situational: it matters acutely when an organization deactivates an account as an incident-response containment step (e.g. a departing or compromised insider) and wrongly assumes access is severed.

An administrator deactivates a user account (a departing employee or a suspected-compromised operator) as a containment action, and password login is correctly refused. However, the account holder - or anyone holding that account's still-valid Core API token - continues issuing authenticated Core API calls with the pre-existing token and even uses it to mint a fresh replacement token, retaining role-scoped access indefinitely. No public exploit code exists; exploitation is a straightforward replay of the actor's own legitimate, unexpired credential.