Jarek Potiuk

Apache Airflow FAB provider versions 3.7.3 through 3.8.0 do not validate the issuer or audience of Azure AD `id token`s during OAuth login. Deployments are affected only when the FAB auth manager is configured with Azure AD as an OAuth provider. Because the signing keys are fetched from Microsoft's **multi-tenant** JWKS endpoint, an `id token` minted in *any* Azure tenant — including one the attacker creates — passes signature verification, and the username and role assignments are then read from that attacker-controlled token. Anyone able to register an Azure tenant can therefore authenticate to the Airflow UI with no prior access to the deployment. The fix for **CVE-2026-59243** was incomplete, and this advisory closes the remaining gap: that fix made the provider verify the `id token` signature, but did not add issuer or audience checks. Operators who already applied the CVE-2026-59243 fix are **still affected and must upgrade again** — 3.7.3 is the release that shipped that fix, so every version containing it falls inside this affected range. Upgrade to apache-airflow-providers-fab `3.8.1` or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.1 **Description** The environment-variable secrets backend incorrectly resolves team-scoped Connections or Variables from the wrong team's scope. This occurs because the security guard intended to prevent this behavior only executes when no team scope is provided and fails to match team names containing underscores. Consequently, the system performs an unconditional global read of the `AIRFLOW CONN <TEAM> <ID>` variable, regardless of the requesting team. In multi-team mode, an authenticated user can use the `POST /api/v2/connections/test` endpoint to resolve another team's Connection and authenticate outward using those credentials. Exploitation requires the `[core] multi team` setting to be enabled, `[core] test connection` to be set to `Enabled`, team-scoped secrets to be provisioned as environment variables in the API-server process, and knowledge of the encoded identifier. **Recommendations** Upgrade to apache-airflow 3.3.1 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.1 **Description** The secrets masker in the UI fails to hide values stored under sensitive key names when they are nested inside a list, tuple, or set beyond the recursion-depth limit. This results in Airflow Variables with deeply-nested values being displayed unmasked in the Variables UI. This issue serves as a shoulder-surfing defense and does not bypass access-control boundaries, as authenticated users with UI access can already retrieve the full value via the Variables REST API. **Recommendations** Upgrade to apache-airflow version 3.3.1 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.1 **Description** An authenticated API user with XCom write-and-read access can instantiate arbitrary `airflow.*` classes on the API server. This occurs because the `GET /api/v2/{...}/xcomEntries/{key}?deserialize=true` endpoint passes a string-literal payload through the `BaseXCom.deserialize value()` function without the ` check forbidden xcom keys` guard. The issue is triggered when a user writes an XCom value and subsequently reads it back with the `deserialize` parameter set to `true`. This is a deserialization flaw, where untrusted data is used to abuse the logic of an application to execute unintended code or instantiate unauthorized objects. **Recommendations** Upgrade to apache-airflow version 3.3.1 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.1 **Description** In deployments using multi-team mode with a team-aware auth manager, the asset materialization endpoint `POST /api/v2/assets/{asset id}/materialize` and the XCom result check on `wait dag run until finished` authorize the target Dag without verifying its team. This occurs because the auth manager checks the `DAG` resource instead of the `DAG:<team>` resource, bypassing team-scoped permissions. Consequently, an authenticated user from one team can trigger Dag runs belonging to another team by providing their own `dag run id` and `conf`, and can read XCom values from another team. Deployments using the FAB auth manager are not affected. **Recommendations** Upgrade to version 3.3.1 or later.

Apache Airflow's Config API did not mask team-scoped sensitive configuration values in multi-team deployments. When an administrator has enabled multi-team mode and exposed the Config API, an authenticated Viewer holding only configuration-read access — with no prior access to the secret — could read a team-scoped Celery broker URL, including its embedded credentials, in cleartext, while the equivalent global option was correctly masked. The secrets masker matched only base section and option names and did not normalize team-prefixed sections before the sensitivity check (CWE-200). This is a distinct masker bypass from CVE-2026-48828 and CVE-2026-48892: deployments that upgraded to apache-airflow 3.3.0 to address those issues remain affected by this team-scoped variant. Users are advised to upgrade to apache-airflow 3.3.1 or later, which normalizes team-scoped sections before masking.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.1 **Description** The Task SDK fails to mask the contents of a Variable when its JSON value is a list. This occurs because masking is only applied to deserialized values that are strings or dictionaries, leaving top-level lists unmasked. Consequently, secrets stored in this format are displayed in cleartext within task logs and the Rendered Templates UI. An authenticated user with permissions to view task logs or rendered templates can recover these values without any special configuration. **Recommendations** Upgrade to apache-airflow version 3.3.1 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-google versions prior to 22.3.0 **Description** The Google Cloud Secret Manager secrets backend in the Google provider fails to apply the team scope when resolving Connections and Variables. Although the `team name` variable is accepted by the backend, it is dropped at the internal call boundary, causing lookups to resolve against team-agnostic secret names. In deployments using multi-team mode, this allows a task or DAG belonging to one team to resolve and obtain the full credentials of a Connection or Variable belonging to another team. **Recommendations** Upgrade to apache-airflow-providers-google version 22.3.0 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow version 3.3.0 **Description** In the `awaiting input` task state, the scheduler deserializes the `next kwargs` variable of a task instance without using an allow-list. A DAG author can manipulate this value via the task execution API to trigger arbitrary module imports and object instantiation within the scheduler process, or cause the scheduler job to terminate. This process occurs automatically every 15 seconds and is not mitigated by the default `allowed deserialization classes` setting. **Recommendations** Upgrade to apache-airflow version 3.3.1 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.1 **Description** The serialization layer fails to restrict the classes imported during the reconstruction of exception nodes. By calling `import string()` on a class name and instantiating it with arguments from a serialized blob, the system allows an arbitrary callable to be imported and invoked. This can be triggered via an operator's `executor config`, enabling a Dag author to execute functions such as `subprocess.check output` or `builtins.eval`. The issue affects the Scheduler, which reconstructs serialized Dags, and the API server via the `GET /api/v2/dags/{dag id}/details` endpoint. Both components have access to metadata database credentials and the JWT signing secret. **Recommendations** Upgrade to apache-airflow version 3.3.1 or later.

Apache Airflow's Task SDK rebuilt a `Callback` object from serialized data by re-running its constructor, which imports the module named by the stored callback path. Because `SyncCallback` is itself an Airflow class it passes the default `allowed deserialization classes` allow-list, so tightening that setting does not help. A Dag author — who controls a task instance's `next kwargs` through the task execution API — can therefore cause an arbitrary module to be imported inside the scheduler process, when the scheduler's `awaiting input` timeout sweep deserializes that value. No non-default configuration is required; the sweep runs unconditionally. Versions before 3.3.0 are not affected: the class existed, but the scheduler sweep that reaches it did not. This is a separate code path from CVE-2026-58076 and CVE-2026-67260, which cover different gadgets reaching deserialization — applying either of those fixes does not address this one. Users are advised to upgrade to apache-airflow 3.3.1 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.1 **Description** Sensitive data, including Variable values and Connection `extra` contents, are written to the audit log in cleartext when submitted via the bulk endpoints `PATCH /api/v2/variables` and `PATCH /api/v2/connections`. This occurs because the audit-log masking mechanism only recognizes top-level request fields, while bulk requests nest entities two levels deeper, bypassing the masking process. Consequently, any authenticated user with audit-log read access can recover these secrets, even if they lack specific permissions to read Variables or Connections. Additionally, the Connection `extra` data is stored unencrypted in the log, despite being encrypted in the connection table. This issue is also triggered by the Airflow UI's Import Variables action. **Recommendations** Upgrade to apache-airflow version 3.3.1 or later.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.1 **Description** An authorization flaw exists in the Backfill API where a discrepancy in how the `backfill id` path segment is parsed allows an authenticated user with edit permissions on any single Dag to perform unauthorized actions on other Dags. The authorization dependency uses `int()` for parsing, while the route handler uses pydantic's `NonNegativeInt`, which accepts values that `int()` rejects (for example, `1.0` is coerced to `1`). Because FastAPI resolves dependencies before endpoint validation, the authorization check and the actual operation act on different Dags. This allows users to read, pause, and cancel backfills of other Dags, or move queued runs to a failed state. Since backfill ids are sequential, identifying targets is trivial. **Recommendations** Upgrade to version 3.3.1 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-yandex versions prior to 4.5.1 **Description** The Yandex Lockbox secrets backend in the Yandex provider resolves a team-scoped Connection or Variable id using a team-agnostic lookup if the team-scoped lookup fails. In deployments utilizing multi-team mode, a user in one team can access secrets from another team by providing an id that matches that team's namespace, allowing full retrieval of credentials. **Recommendations** Upgrade to apache-airflow-providers-yandex version 4.5.1 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-amazon versions prior to 9.34.0 **Description** The AWS Systems Manager Parameter Store and Secrets Manager backends in the Amazon provider resolve a team-scoped Connection or Variable id through a team-agnostic lookup if the initial team-scoped lookup fails. In deployments utilizing multi-team mode, a user in one team can access secrets belonging to another team by providing an id that matches that team's namespace, allowing full retrieval of credentials. **Recommendations** Upgrade to apache-airflow-providers-amazon version 9.34.0 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-microsoft-azure versions prior to 14.1.0 **Description** The Azure Key Vault secrets backend in the Microsoft Azure provider resolves a team-scoped Connection or Variable id using a team-agnostic lookup if the initial team-scoped lookup fails. In deployments utilizing multi-team mode, a user from one team can access secrets belonging to another team by providing an id that matches that team's namespace, allowing full retrieval of credentials. **Recommendations** Upgrade to apache-airflow-providers-microsoft-azure version 14.1.0 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow-providers-fab versions prior to 3.7.2 **Description** In the Apache Airflow FAB auth manager, a privilege escalation occurs when a DAG is created with a `dag id` of `DAGs`. This specific ID collides with the global all-DAGs permission resource name generated by the `resource name()` function. Consequently, a lower-privileged user granted per-DAG `access control` for that specific DAG is silently granted global permissions, allowing them read and edit access to every DAG in the system. **Recommendations** Upgrade to apache-airflow-providers-fab 3.7.2 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow versions prior to 3.3.0 **Description** A bug in the `BaseSerialization.deserialize()` function allows unrestricted `import string()` of attacker-controlled class paths when the Scheduler or API Server loads a serialized DAG. A DAG author can embed a malicious trigger into a DAG to achieve remote code execution on the API Server or Scheduler process, bypassing the security boundary that prevents DAG-author code from executing within those processes. **Recommendations** Upgrade to apache-airflow version 3.3.0 or later. Restrict the `[core] allowed deserialization classes` configuration to a narrow allowlist in deployments where trust in DAG authors is limited.

**Name of the Vulnerable Software and Affected Versions** Apache Airflow versions prior to 3.3.0 **Description** A bug in the `/ui/dependencies` scheduling graph endpoint allows an authenticated UI user with read permissions on some Dags to enumerate identifiers of other Dags they are not authorized to read. While the system applies a readable-Dag filter to the top-level serialized Dag key, it fails to propagate this filter to the `dep.source` and `dep.target` fields of trigger and sensor dependency entries. This issue affects deployments that use per-Dag read scoping to maintain privacy of Dag identifiers across teams. **Recommendations** Update to version 3.3.0 or later.

**Name of the Vulnerable Software and Affected Versions** apache-airflow versions prior to 3.3.0 **Description** An authorization bypass occurs when a user with permission to read a specific Dag can disclose the source code of other Dags located within the same source file. This issue affects deployments that co-locate multiple Dags in a single file and rely on per-DAG access control. The flaw exists in the `GET /api/v2/dagSources/{dag id}` endpoint and the corresponding Dag-source view in the UI, which return the entire source file without redacting unauthorized Dags. The `dag id` variable is used to identify the requested Dag. **Recommendations** Upgrade to apache-airflow version 3.3.0 or later.