On 16 September 2026 the Apache Airflow project published a batch of CVEs for its FAB and Keycloak auth providers, with more following on 21 September and 15 October. Several score 9.1 or 9.8 in NVD. Most of them only matter if you use one specific login path, which is the point of this post: read your auth config before you read the scores.
The common thread is that Airflow's identity checks were fine in the happy path and weak at the edges. Tokens from the wrong tenant, the wrong client, a closed session or a disabled account were still accepted.
What's affected
All of these are fixed in provider packages, not in Airflow core, except one logout bug. The table groups them by the auth setup you need to be exposed.
| CVE | Auth setup | Problem | Fixed in |
|---|---|---|---|
| CVE-2026-75156 | FAB provider 3.7.3 to 3.8.0, Azure AD OAuth | id_token issuer and audience not checked, so a token from any Azure tenant logs in. Incomplete fix for CVE-2026-59243 | providers-fab 3.8.1 |
| CVE-2026-86466 | FAB provider, Authentik OAuth | Audience never checked, so a token minted for another Authentik app logs in | providers-fab 3.9.0 |
| CVE-2026-82311 | FAB provider, session_backend=database | Password reset leaves existing sessions alive (ID type mismatch) | providers-fab 3.9.0 |
| CVE-2026-86462 | FAB provider, database sessions | Admin user-edit PATCH never invalidates sessions | providers-fab 3.9.0 |
| CVE-2026-82310 | Airflow 3, FAB, Core API tokens | Deactivated account's old token still works and can mint a new one | providers-fab 3.9.0 |
| CVE-2026-76187 | Keycloak auth manager, shared realm | Token endpoint accepts client credentials for any confidential client in the realm | providers-keycloak 0.10.0 |
| CVE-2026-76186 | Airflow 3.3 or later, Keycloak | Identity from the session token, privileges from separate unauthenticated cookies | providers-keycloak 0.10.0 |
| CVE-2026-96806 | Keycloak auth manager | Logout revokes a token, then middleware issues a fresh one | providers-keycloak 0.11.1 |
| CVE-2026-92228 | Keycloak, multi-team mode | Every team role gets global read on audit logs | providers-keycloak 0.11.1 |
| CVE-2026-86473 | Core API bearer clients | Logout with an Authorization header revokes nothing | apache-airflow 3.3.2 |
CVE-2026-75156 is the one to read twice. NVD's description says operators who already applied the CVE-2026-59243 fix are still affected, because that fix added signature verification but not issuer or audience checks. Signing keys come from Microsoft's multi-tenant JWKS endpoint, so anyone who can register an Azure tenant can mint a valid token. NVD scores it 9.1.
CVE-2026-82311 is scored 9.8 by NVD, but the description sets a narrow trigger. The attacker must already hold a copy of the victim's session cookie, and the bug only defeats the containment step of resetting the password.
How to check if you're exposed
First find out which auth manager and which providers you run:
pip list 2>/dev/null | grep -E "apache-airflow(-providers-(fab|keycloak))?\b"
airflow config get-value core auth_manager
airflow config get-value fab session_backend
Then look for the OAuth provider in webserver_config.py and for a shared Keycloak realm:
grep -nE "OAUTH_PROVIDERS|azure|authentik|AUTH_TYPE" webserver_config.py
If you use Keycloak, list the confidential clients in the realm Airflow points at. Any client besides Airflow's own means CVE-2026-76187 applies until you upgrade. A realm that only holds Airflow's client is not reachable through that route.
For logout and session issues, the question is operational. Do you rely on password reset or account deactivation to cut off a suspected compromise? If yes, treat every session and token issued before the change as live until you upgrade.
What to do now
- Upgrade apache-airflow-providers-fab to 3.9.0 or later. That single release covers the FAB items in the table, including the Azure fix that first shipped in 3.8.1.
- Upgrade apache-airflow-providers-keycloak to 0.11.1 or later, which includes the 0.10.0 fixes.
- Upgrade apache-airflow to 3.3.2 or later if API clients log in with bearer tokens.
- After upgrading, rotate: restart the API server and webserver, and invalidate outstanding sessions by changing the secret key where your setup allows it. Shorten the token lifetime, since NVD notes the default is 24 hours.
- If you suspect past misuse, review login events for Azure AD or Authentik users who do not exist in your directory.
- Stop sharing one Keycloak realm between Airflow and unrelated confidential clients when you can. Separate realms shrink the blast radius even on patched versions.
Why it matters
Airflow often holds connection secrets for every system a data team touches. Anyone who gets a session on it can read variables, trigger DAGs and, in many deployments, reach production credentials.
The advisories also show a pattern worth testing in your own SSO code. Verifying a token signature is not the same as verifying that the token was meant for you. Issuer, audience and subject binding are separate checks, and a fix that adds only the first one leaves the door ajar. That is exactly why the Azure fix had to be repeated and why the Authentik path needed its own CVE.
The second lesson is about containment. Password reset, deactivation and logout are the actions responders run first. Three of these CVEs are about those actions silently not working.
Try it yourself
Pull your installed provider versions into an SBOM and see which of these packages you carry. Our free scanner at https://gold.safeguard.sh/scan accepts a requirements.txt, runs in the browser, and the file never leaves your machine. It handles up to 100 dependencies per scan.
Quick check
You applied the fix for CVE-2026-59243 and use Azure AD login. Are you done?
No. CVE-2026-75156 says that fix only added signature checks. You need apache-airflow-providers-fab 3.8.1 or later, and 3.9.0 if you also use Authentik.
Your Keycloak realm contains only Airflow's own client. Does CVE-2026-76187 apply?
The description requires a shared realm with other confidential clients, so the practical exposure is low. You should still upgrade, because the Keycloak provider has other fixes in 0.10.0 and 0.11.1.
