Jarek Potiuk

The Apache Airflow Keycloak auth manager did not end the session on logout: the logout route revoked the presented token, but `KeycloakJWTMiddleware` then issued a new, unrevoked token on the same response, so the user stayed logged in. Deployments using the Keycloak auth manager are affected: after a user logs out, anyone with later access to the same browser (for example on a shared workstation) can continue to act as that user. Users of apache-airflow-providers-keycloak are recommended to upgrade to apache-airflow-providers-keycloak 0.11.1 or later.

The Apache Airflow Keycloak provider's multi-team provisioning (` attach team permissions`) granted every team role global read access to audit logs. Deployments that enable multi-team mode with the Keycloak auth manager and provision teams through it are affected: any authenticated member of one team could read other teams' audit events through the UI or the event-log API. Users of apache-airflow-providers-keycloak are recommended to upgrade to apache-airflow-providers-keycloak 0.11.1 or later.

The Apache Airflow SSH provider hook disables SSH host-key verification by default: unless `host key` is configured or `no host key check` is explicitly set to false, it accepts any server key. This affects SSH and SFTP connections that rely on the default. An attacker in a machine-in-the-middle position between the worker and the SSH or SFTP server can impersonate the server and capture the credentials or data a task sends. Users of apache-airflow-providers-ssh and apache-airflow-providers-sftp are recommended to upgrade to apache-airflow-providers-ssh 7.0.0 and apache-airflow-providers-sftp 7.0.0 or later. The deferrable SFTP code paths had the same default and are covered separately by CVE-2026-94135; apache-airflow-providers-sftp 7.0.0 fixes both.

The Apache Airflow SFTP provider's deferrable code paths (`SFTPTrigger`, `SFTPHookAsync`, `SFTPClientPool`) disable SSH host-key verification by default unless the connection explicitly sets `no host key check` to false. Deployments that run SFTP sensors or operators in deferrable mode are affected. An attacker in a machine-in-the-middle position between the triggerer and the SFTP server can impersonate the server and capture the credentials or data exchanged. Users of apache-airflow-providers-sftp are recommended to upgrade to apache-airflow-providers-sftp 7.0.0 or later. This is a separate defect from CVE-2026-94134 (the synchronous SSH hook default, which also affects the SFTP hook); users who applied the fix for one also need this release for the other - apache-airflow-providers-sftp 7.0.0 fixes both.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-teradata versions prior to 3.7.0 **Description** The Teradata provider in Apache Airflow embeds cloud storage credentials directly into SQL statements as plain string literals within the `CREATE MULTISET TABLE ... LOCATION` statement. This occurs when using `S3ToTeradataOperator` or `AzureBlobStorageToTeradataOperator` with a private bucket and no `teradata authorization name` configured. Consequently, credentials are exposed in two locations: the Airflow task logs and Teradata's DBQL query logs and live monitoring views. Specifically, `S3ToTeradataOperator` may expose runtime AWS credentials and STS session tokens in Airflow logs, while `AzureBlobStorageToTeradataOperator` exposes storage account keys within Teradata's internal logs. **Recommendations** Upgrade to apache-airflow-providers-teradata version 3.7.0 or later. Configure `teradata authorization name` with a Teradata `AUTHORIZATION` object to prevent credentials from being inlined. Rotate any credentials previously used through the inline path.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-snowflake versions prior to 6.18.0 **Description** The Snowflake provider fails to validate the `account` and `region` fields of a connection before interpolating them into request URLs. This allows an attacker with permissions to edit the connection, but not read its secrets, to inject characters such as `/`, `?`, or `#` into the `account` field. This manipulation changes the intended domain into a path, query, or fragment, granting the attacker control over the request host. Consequently, the provider may send an `Authorization: Bearer` header containing a JWT (JSON Web Token), an OAuth token, or a programmatic access token to a host controlled by the attacker, who can then replay it against the legitimate Snowflake endpoint. This issue affects the SQL API endpoint `https://{account}.snowflakecomputing.com/api/v2/statements`, the OAuth token-request URL, and the Cortex Agent base URL. **Recommendations** Upgrade to apache-airflow-providers-snowflake version 6.18.0 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-google versions prior to 22.6.0 **Description** The Google provider in Apache Airflow constructs Google Drive search expressions by interpolating file and folder names directly into single-quoted string literals without escaping the quote character. This allows a name containing an apostrophe to terminate the literal early, enabling an attacker to append arbitrary clauses to the query. In scenarios such as wildcard `gcs to gdrive` transfers, these names may originate from source bucket listings controlled by external data producers or ingest-only service accounts. An attacker can use this to manipulate which file or folder the hook resolves, potentially directing uploads to an attacker-controlled folder or causing downloads to retrieve a malicious file instead of the intended one. **Recommendations** Upgrade to apache-airflow-providers-google version 22.6.0 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-teradata versions prior to 3.7.0 **Description** The compute-cluster example Dag in the Apache Airflow Teradata provider declares Dag Params as unconstrained free text. These values are templated directly into compute-cluster operators, which interpolate them into Teradata DDL (Data Definition Language). A user with permissions to trigger the Dag can provide SQL fragments that execute using the task's connection. Additionally, because the connection ID is a free-text Param, the user can redirect the task to any other connection defined in the deployment. **Recommendations** Upgrade to version 3.7.0 or later. For users who copied the example Dag, apply constraints to the Params to use validated identifiers and a closed value set, and remove connection selection and free-form option strings from trigger-time input.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions 3.3.0 through 3.3.1 **Description** An issue exists in the Airflow core API where the system incorrectly prioritizes a session cookie over an explicit `Authorization: Bearer` token when both are present in a request. This causes the system to resolve the caller based on the cookie and ignore the bearer token, leading to principal confusion and misattributed audit records. Exploitation requires an attacker to place a valid session cookie into the victim's browser or client, which can occur via cookie tossing from a sibling subdomain, cross-site scripting in a separate application sharing a parent domain, or through a shared workstation. This is primarily a risk for deployments hosting the Airflow UI on a domain shared with other applications. **Recommendations** Upgrade Apache Airflow versions 3.3.0 through 3.3.1 to version 3.3.2 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.2 **Description** The `/assets/events` API endpoint fails to restrict asset events to the Dags that the caller is authorized to read. Authenticated users with asset-read access can enumerate asset events for Dags they lack permission to view, exposing the source Dag ID, task ID, run ID, and event timestamps. Additionally, the absence of a filter in the count query allows the `total entries` and pagination features to disclose the existence of hidden Dags. This issue occurs in deployments utilizing per-Dag access control to separate teams or tenants. **Recommendations** Upgrade to apache-airflow version 3.3.2 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.2 **Description** The Core API logout endpoint only revokes session tokens provided via the ` token` cookie. If a client uses an Authorization bearer header for authentication during logout, the endpoint returns a successful response without revoking the token. This allows the token to remain valid until its expiration, which is 24 hours by default. An attacker possessing a copy of this token can maintain access to the victim's account even after the victim has logged out. **Recommendations** Upgrade to version 3.3.2 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.2 **Description** The asset queued-events DELETE endpoints incorrectly verify the caller's Dag-axis permission using `READ` instead of `EDIT`. This allows any authenticated user with read access to a Dag to delete its queued asset events, which silently suppresses asset-triggered scheduling. This issue occurs in deployments where asset-triggered scheduling is active and Dag read access is granted more broadly than edit access, which is the standard Role-Based Access Control (RBAC) configuration. **Recommendations** Upgrade to apache-airflow version 3.3.2 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-keycloak versions prior to 0.10.0 **Description** The unauthenticated token endpoint accepts a client-credentials grant for any confidential client registered in the Keycloak realm, rather than restricting it to the client configured for Airflow. Because no allowlist restricts which client IDs may authenticate, credentials from an unrelated application sharing the same realm are accepted as valid Airflow login credentials, allowing Airflow to mint a signed session token for that application's service account. Additionally, the endpoint allows unauthenticated credential guesses against Keycloak using Airflow's identity. This issue affects deployments using the Keycloak auth manager where the realm is shared with other confidential clients. An attacker with valid credentials for any of those clients can gain access to any endpoint that requires authentication, as well as permissions held by that specific service account. **Recommendations** Upgrade to version 0.10.0 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-fab versions prior to 3.9.0 **Description** Deactivating a user account does not invalidate tokens issued to that account prior to the deactivation. While password authentication correctly rejects disabled accounts, the Core API continues to accept existing, unexpired tokens and allows them to mint replacements. This enables an account to maintain role-scoped access indefinitely after an administrator has disabled it by replaying legitimate credentials. This issue occurs in deployments using Airflow 3 with the FAB auth manager and Core API token authentication when an account is deactivated but its record remains in the database. **Recommendations** Upgrade to version 3.9.0 or later.

🚨 CVE-2026-97636 Apache Airflow HashiCorp provider: the HashiCorp Vault secrets backend's team-scope guard can be bypassed with a user-controlled key. In a multi-team deployment, a Dag author scoped to one team can supply a Variable key containing a path separator that causes the backend to resolve a secret belonging to a different team, because after the team-scoped lookup misses the backend falls back to a team-agnostic path concatenated from the unvalidated key. The Execution API Variables route accepts a path-shaped key, so this is reachable from ordinary Dag code. Affects multi-team deployments using the HashiCorp Vault secrets backend. Single-team deployments are not affected, as there is no cross-team boundary to cross. This is the same class as CVE-2026-86465, CVE-2026-68870, CVE-2026-68871 and CVE-2026-68872 in the Akeyless, Azure Key Vault, Yandex Lockbox and Amazon secrets backends. Users of apache-airflow-providers-hashicorp are recommended to upgrade to version 4.8.0 or later, which fixes the issue. 🎖@cveNotify

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-fab versions prior to 3.9.0 **Description** Resetting a user password fails to delete existing database-backed sessions when using the FAB auth manager with `[fab] session backend=database`. This occurs because the cleanup process compares a string identifier stored by Flask-Login in the session against the user's integer database identifier, resulting in a mismatch that prevents session removal. Consequently, an attacker possessing a victim's session cookie maintains access even after a password reset. Additionally, a similar issue exists via the Admin user-edit endpoint. **Recommendations** Upgrade to version 3.9.0 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow Keycloak provider versions 3.3 and later **Description** The Keycloak auth manager retrieves a user's identity from a signed Airflow session token but obtains Keycloak access and refresh tokens from separate, unauthenticated cookies. Because the system fails to verify that both the session identity and the tokens refer to the same subject, an attacker with a valid Airflow login and another user's Keycloak tokens can pair them. This allows the attacker to perform requests with the privileges of the foreign token while the session identity, audit logs, and cache keys still reflect the attacker's account. Additionally, the refresh process re-issues a session token that maintains this mismatched pairing across sessions. **Recommendations** Upgrade apache-airflow-providers-keycloak to version 0.10.0 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-fab versions prior to 3.9.0 **Description** Changing a user password via the Admin user-edit PATCH endpoint fails to invalidate existing database-backed sessions. This allows an attacker possessing a victim's session cookie to maintain full access to the account even after a password reset. This issue specifically affects deployments using the FAB auth manager with database-backed sessions. The trigger is a routine password change performed by an administrator or the user, requiring no direct interaction from an attacker with the endpoint. **Recommendations** Upgrade to version 3.9.0 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-fab versions prior to 3.9.0 **Description** The Authentik OAuth path in the FAB auth manager fails to validate the issuer or audience claims of the accepted `id token`. This allows an attacker who possesses a valid token minted by the same Authentik identity provider for a different client application to present it to Airflow and be authenticated as the specified user, as the audience claim is not verified. **Recommendations** Upgrade to version 3.9.0 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow FAB provider versions 3.7.3 through 3.8.0 **Description** An issue exists during OAuth login when the FAB auth manager is configured with Azure AD as an OAuth provider. The software fails to validate the issuer or audience of Azure AD `id token`s. Since signing keys are retrieved from a multi-tenant JWKS (JSON Web Key Set) endpoint, an `id token` generated in any Azure tenant, including those created by an attacker, can pass signature verification. This allows an attacker to provide a controlled token to manipulate username and role assignments, enabling unauthorized authentication to the Airflow UI. **Recommendations** Upgrade Apache Airflow FAB provider versions 3.7.3 through 3.8.0 to version 3.8.1 or later.