{"api_version":"1","generated_at":"2026-09-16T10:53:06+00:00","cve":"CVE-2026-82310","urls":{"html":"https://cve.report/CVE-2026-82310","api":"https://cve.report/api/cve/CVE-2026-82310.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-82310","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-82310"},"summary":{"title":"Apache Airflow FAB provider: FAB auth manager: deactivated users retain and renew Core API JWT access","description":"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.\n\nAffects 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.\n\nUsers of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account.","state":"PUBLISHED","assigner":"apache","published_at":"2026-09-16 10:16:53","updated_at":"2026-09-16 10:16:53"},"problem_types":["CWE-613","CWE-613 CWE-613: Insufficient Session Expiration"],"metrics":[],"references":[{"url":"https://github.com/apache/airflow/pull/72199","name":"https://github.com/apache/airflow/pull/72199","refsource":"security@apache.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://lists.apache.org/thread/85h9r50bmy8vgkgr5nyddryj1p5pxxy2","name":"https://lists.apache.org/thread/85h9r50bmy8vgkgr5nyddryj1p5pxxy2","refsource":"security@apache.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"http://www.openwall.com/lists/oss-security/2026/09/15/10","name":"http://www.openwall.com/lists/oss-security/2026/09/15/10","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-82310","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-82310","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Apache Software Foundation","product":"Apache Airflow FAB provider","version":"affected 2.0.0 3.9.0 semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Mayank Jangid (OpenSec)","lang":"en"},{"source":"CNA","value":"Jarek Potiuk","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"providerMetadata":{"dateUpdated":"2026-09-16T09:13:05.055Z","orgId":"af854a3a-2127-422b-91ae-364da2661108","shortName":"CVE"},"references":[{"url":"http://www.openwall.com/lists/oss-security/2026/09/15/10"}],"title":"CVE Program Container"}],"cna":{"affected":[{"collectionURL":"https://pypi.python.org","defaultStatus":"unaffected","packageName":"apache-airflow-providers-fab","packageURL":"pkg:pypi/apache-airflow-providers-fab","product":"Apache Airflow FAB provider","vendor":"Apache Software Foundation","versions":[{"lessThan":"3.9.0","status":"affected","version":"2.0.0","versionType":"semver"}]}],"credits":[{"lang":"en","type":"finder","value":"Mayank Jangid (OpenSec)"},{"lang":"en","type":"remediation developer","value":"Jarek Potiuk"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"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.<br><br>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.<br><br>Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account."}],"value":"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.\n\nAffects 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.\n\nUsers of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account."}],"metrics":[{"other":{"content":{"text":"moderate"},"type":"Textual description of severity"},"scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-613","description":"CWE-613: Insufficient Session Expiration","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-09-16T09:09:07.539Z","orgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","shortName":"apache"},"references":[{"tags":["patch"],"url":"https://github.com/apache/airflow/pull/72199"},{"tags":["vendor-advisory"],"url":"https://lists.apache.org/thread/85h9r50bmy8vgkgr5nyddryj1p5pxxy2"}],"source":{"discovery":"UNKNOWN"},"title":"Apache Airflow FAB provider: FAB auth manager: deactivated users retain and renew Core API JWT access","x_generator":{"engine":"airflow-s/generate_cve_json.py"}}},"cveMetadata":{"assignerOrgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","assignerShortName":"apache","cveId":"CVE-2026-82310","datePublished":"2026-09-16T09:09:07.539Z","dateReserved":"2026-08-28T12:58:11.839Z","dateUpdated":"2026-09-16T09:13:05.055Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-16 10:16:53","lastModifiedDate":"2026-09-16 10:16:53","problem_types":["CWE-613","CWE-613 CWE-613: Insufficient Session Expiration"],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"82310","Ordinal":"1","Title":"Apache Airflow FAB provider: FAB auth manager: deactivated users","CVE":"CVE-2026-82310","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"82310","Ordinal":"1","NoteData":"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.\n\nAffects 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.\n\nUsers of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account.","Type":"Description","Title":"Apache Airflow FAB provider: FAB auth manager: deactivated users"}]}}}