Jarek Potiuk

Apache Airflow's public Import Errors API returns the raw parse-failure stack trace to any user with the `ImportError.can read` permission when the failing file has no registered DAG. This happens when a file fails to parse before any DAG is defined, or when all of its previously registered DAGs are removed but the parse error remains. Users who should not see that file's details can read stack traces that may expose file paths and code. Users are advised to upgrade to Apache Airflow 3.4.0 or later, which restricts these stack traces to users with the new `IMPORT ERRORS ALL` permission.

Apache Airflow's secrets masker matched sensitive key names only in their snake case form, so values stored under camelCase keys such as `privateKey`, `connectionString`, `webhookUrl` or `accessKey` — for example in a Connection's extra or a Variable — were not redacted in task logs, rendered template fields or API responses. A user who can read task logs or rendered templates, but is not meant to see those credentials, could read them in cleartext. Users are advised to upgrade to apache-airflow 3.4.0 or later. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later.

Apache Airflow's Task SDK secret cache built its keys from the team name and secret id with unescaped ` ` delimiters, so different (team, secret id) pairs could collide. In multi-team deployments a Dag author could read another team's Variable or Connection value by crafting a colliding secret id. Only deployments with both `core.multi team = True` and `secrets.use cache = True` are affected. Users are advised to upgrade to apache-airflow 3.4.0 or later. Deployments that cannot upgrade can set `secrets.use cache = False`.

Apache Airflow 3.3.1 shipped a fix for CVE-2026-67260 that checks the scheduler's decoded `next kwargs` value is a dictionary, but performs that check only after deserializing the whole stored payload. Deserialization reconstructs nested objects of classes permitted by the deserialization allow-list — which by default includes Airflow's own classes — and runs their constructors inside the scheduler process before the check can reject the value. A Dag author, who controls a task's `next kwargs` through the task execution API, can therefore still trigger constructor execution in the scheduler when the `awaiting input` timeout sweep processes the task, and in the API server when the task instance is served to a worker using an older Execution API version; no non-default configuration is required. Versions before 3.3.0 are not affected. This is an incomplete fix for CVE-2026-67260: deployments that upgraded to 3.3.1 for that issue must also upgrade to apache-airflow 3.4.0 or later.

Apache Airflow's asset API endpoints returned the IDs of Dags that are scheduled on, produce, or consume an asset without checking whether the caller may read those Dags. An authenticated user with asset read access could learn the IDs of Dags they are not authorized to see. Users are advised to upgrade to apache-airflow 3.4.0 or later. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later.

Apache Airflow's API endpoint for deleting an asset's queued events checked Dag edit permission against the `dag id` query parameter, but deleted the queued events of every Dag the caller could read. An authenticated user with edit permission on one Dag and read access to others could suppress asset-triggered runs of Dags they cannot edit. This is an incomplete fix for CVE-2026-75157: users who upgraded to apache-airflow 3.3.2 for that fix are still affected and should upgrade to apache-airflow 3.4.0 or later.

Apache Airflow's asynchronous connection test checked permissions when the test was queued — only create permission when the connection ID did not exist yet — but, when the test completed with `commit on success`, wrote the tested connection under that ID. A user allowed to create but not edit connections could overwrite a connection someone else had created in the meantime. Only deployments that enable the non-default `[core] test connection` setting are affected. Users are advised to upgrade to apache-airflow 3.4.0 or later.

Apache Airflow's logout endpoint attempted to revoke the presented token on the server, but any failure during revocation was silently ignored and logout still reported success. When the auth manager redirects logout to an external logout URL (for example the FAB or Keycloak auth managers), server-side revocation is the only thing that invalidates the Airflow token; it failed on database errors and, reliably, for tokens from an external issuer accepted via `[api auth] trusted jwks url` whose token identifier is longer than 32 characters. Anyone holding a copy of a user's token from before logout could keep using it against the Airflow API until it expired. Users are advised to upgrade to apache-airflow 3.4.0 or later.

Apache Airflow rebuilt deadline alert fields through generic deserialization, which imports and instantiates the class named in the serialized Dag, in the scheduler and API server. A Dag author could cause classes within Airflow's deserialization allow list to be constructed in those processes with arguments they control. Deployments whose Dags use deadline alerts are affected. This is an incomplete fix of CVE-2026-45360, which only hardened the `reference` field; deployments that applied that fix remain affected through the `callback` and `interval` fields. Users of apache-airflow are recommended to upgrade to 3.4.0 or later.

Apache Airflow's secrets masker stopped descending into nested structures after five levels, so a secret registered with the masker — for example a Connection password or a Variable value — that appeared more than five containers deep under non-sensitive keys was shown in cleartext in task logs and rendered template fields. A user who can read task logs or rendered templates, but is not meant to see those secrets, could read them. Users are advised to upgrade to apache-airflow 3.4.0 or later. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later.

The `example dag decorator` example Dag shipped with Apache Airflow validated an IP address fetched over HTTP with Python's `ipaddress` module and then placed it into a shell command. `ipaddress` accepts IPv6 zone identifiers containing arbitrary characters, so when example Dags are loaded (`load examples` enabled), a user who can trigger that Dag with a custom `url` parameter could point it at a server whose response injects shell commands run on the worker. This is an incomplete fix for CVE-2025-54941; users who upgraded for CVE-2025-54941 should upgrade again. Users are advised to upgrade to apache-airflow 3.4.0 or later, or to disable example Dags (`load examples = False`), which is recommended for production.

O agendador desserializa completamente os valores XCom gravados pelo código da tarefa durante a avaliação de dependências de tarefas. Isso permite que um autor de DAG controle dados que são desserializados dentro do processo do agendador, ignorando o modelo de segurança que restringe tais capacidades ao Gerente de Implantação. Este problema afeta implantações onde os autores de DAG são considerados menos confiáveis do que os Gerentes de Implantação e ocorre quando o agendador avalia uma dependência de tarefa que lê um valor XCom gravado por uma tarefa.

Apache Airflow's CLI records its arguments in the audit log but masks secrets by argument position, so some supported command shapes leave secrets in cleartext, for example a trailing `--description` on Variable commands, `--conn-extra`, and the inline `--password` of `airflow keycloak-auth-manager` commands. A user who can read audit events but is denied Variable and Connection access can retrieve those values through the event-log API. Users of apache-airflow are recommended to upgrade to 3.4.0 or later. Audit-log entries written before the upgrade keep the cleartext values: purge the affected entries and rotate the secrets they contain. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later.

The Apache Airflow connections API did not mask the apprise provider's `config` connection extra, which can embed notification-service credentials. A user with permission to read connections could retrieve it in cleartext, although Airflow 3 treats connection credentials as write-only. Users are advised to upgrade to apache-airflow 3.4.0 or later. Airflow 2.x is also affected; Airflow 2 has reached end of life and will not receive a fix, so Airflow 2 users should upgrade to Apache Airflow 3.4.0 or later.

Apache Airflow did not reject reserved serialization keys inside a Dag run's `conf`. A user allowed to trigger a Dag that uses a deadline alert with an asynchronous callback could pass a `conf` that, once the deadline was missed, either crashed the scheduler repeatedly or was rebuilt into objects inside the Triggerer. Users are advised to upgrade to apache-airflow 3.4.0 or later.

A API de Execução de Tarefas armazena valores XCom gravados por uma tarefa sem aplicar a verificação de chave reservada. Isso permite que o autor de um DAG grave um XCom que, ao ser visualizado via API com a desserialização habilitada, força o servidor da API a instanciar classes do namespace `airflow.*` usando argumentos escolhidos pelo autor.

O fluxo de login SAML do gerenciador de autenticação AWS não vincula a resposta de autenticação ao navegador que iniciou a solicitação. O manipulador de login descarta o ID `AuthnRequest` e o callback valida a asserção sem exigir um `InResponseTo` correspondente. Isso permite que um invasor não autenticado induza uma vítima a carregar uma página, completando um login SAML no navegador da vítima usando a própria asserção do invasor. Consequentemente, a vítima é silenciosamente conectada à conta do Airflow do invasor, e qualquer ação subsequente realizada pela vítima ocorre em uma sessão controlada pelo invasor.

O gerenciador de autenticação Keycloak não encerra a sessão ao fazer logout. Embora a rota de logout revogue o token apresentado, o `KeycloakJWTMiddleware` emite um novo token não revogado na mesma resposta, fazendo com que o usuário permaneça conectado. Isso permite que qualquer pessoa com acesso posterior ao mesmo navegador, como em uma estação de trabalho compartilhada, continue a agir como esse usuário.

Caminhos de código adiáveis (deferrable) no provedor SFTP, especificamente `SFTPTrigger`, `SFTPHookAsync` e `SFTPClientPool`, desativam a verificação de chave de host SSH por padrão, a menos que a variável `no host key check` seja explicitamente definida como false. Isso afeta implantações que executam sensores ou operadores SFTP em modo adiável. Um invasor em uma posição de machine-in-the-middle entre o triggerer e o servidor SFTP pode personificar o servidor e capturar as credenciais ou dados trocados.

O provisionamento de múltiplas equipes no provedor Keycloak do Apache Airflow concede a cada função de equipe acesso de leitura global aos logs de auditoria. Isso ocorre na função ` attach team permissions()`. Em implantações onde o modo de múltiplas equipes é habilitado usando o gerenciador de autenticação Keycloak para o provisionamento de equipes, qualquer membro autenticado de uma equipe pode acessar eventos de auditoria de outras equipes por meio da interface do usuário ou do endpoint da API de log de eventos.