GPU VulnDB

Database/Control plane, storage & DevOps

Apache Airflow FAB provider: Authentik OAuth path does not check id_token issuer or audience

CVSS 8.1CVE-2026-86466Control plane, storage & DevOpscurated

Impact

Airflow's FAB auth manager accepts an Authentik id_token without validating the issuer or audience claim, so a token that the same Authentik instance minted for a completely different client application authenticates the named user into Airflow. Where Airflow schedules GPU training and batch inference DAGs, that is an authentication bypass into the job control plane: the attacker inherits whatever the impersonated user can do, which typically means defining or editing DAGs that execute code on fleet workers and reading connection credentials for storage and registries. Any other application behind the same Authentik tenant becomes a path into the scheduler. The fix for CVE-2026-75156 covered only the Azure AD path in the same file, so operators who already patched that one are still exposed on Authentik.

Who can reach it

Network access to the Airflow web UI, plus a valid id_token from the same Authentik identity provider issued for any other client application. No Airflow account or credentials needed.

What to do

Upgrade apache-airflow-providers-fab to 3.9.0 or later and restart the Airflow webserver/API server; the provider is a Python package, so this is a redeploy of the Airflow images or a pip upgrade plus daemon restart, no worker node drain. Until then, consider switching the FAB auth manager off the Authentik OAuth path or isolating Airflow behind a proxy that validates the audience claim itself.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.