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.

**Nome do Software Vulnerável e Versões Afetadas** Apache Airflow versões anteriores a 3.3.1 **Descrição** O backend de segredos de variáveis de ambiente resolve incorretamente Conexões ou Variáveis com escopo de equipe a partir do escopo da equipe errada. Isso ocorre porque a trava de segurança destinada a evitar esse comportamento só é executada quando nenhum escopo de equipe é fornecido e não consegue corresponder a nomes de equipe que contenham sublinhados. Consequentemente, o sistema realiza uma leitura global incondicional da variável `AIRFLOW CONN <TEAM> <ID>`, independentemente da equipe solicitante. No modo multi-equipe, um usuário autenticado pode usar o endpoint `POST /api/v2/connections/test` para resolver a Conexão de outra equipe e autenticar-se externamente usando essas credenciais. A exploração requer que a configuração `[core] multi team` esteja habilitada, `[core] test connection` esteja definida como `Enabled`, que segredos com escopo de equipe estejam provisionados como variáveis de ambiente no processo do servidor de API e o conhecimento do identificador codificado. **Recomendações** Atualize para o apache-airflow 3.3.1 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** Apache Airflow versões anteriores a 3.3.1 **Description** O mascarador de segredos na interface do usuário (UI) falha ao ocultar valores armazenados sob nomes de chaves sensíveis quando estes estão aninhados dentro de uma lista, tupla ou conjunto além do limite de profundidade de recursão. Isso resulta na exibição de Variáveis do Airflow com valores profundamente aninhados sem a devida máscara na UI de Variáveis. Este problema atua como uma defesa contra a observação inadvertida da tela (shoulder-surfing) e não ignora limites de controle de acesso, pois usuários autenticados com acesso à UI já podem recuperar o valor completo através da API REST de Variáveis. **Recommendations** Atualize para a versão apache-airflow 3.3.1 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** Apache Airflow versões anteriores a 3.3.1 **Descrição** Um usuário autenticado da API com acesso de leitura e escrita no XCom pode instanciar classes `airflow.*` arbitrárias no servidor da API. Isso ocorre porque o endpoint `GET /api/v2/{...}/xcomEntries/{key}?deserialize=true` passa um payload de string literal através da função `BaseXCom.deserialize value()` sem a proteção ` check forbidden xcom keys`. O problema é acionado quando um usuário grava um valor XCom e, posteriormente, o lê com o parâmetro `deserialize` definido como `true`. Trata-se de uma falha de desserialização, na qual dados não confiáveis são usados para abusar da lógica de um aplicativo para executar código não pretendido ou instanciar objetos não autorizados. **Recomendações** Atualize para a versão 3.3.1 ou posterior do apache-airflow.

**Nome do Software Vulnerável e Versões Afetadas** Apache Airflow versões anteriores a 3.3.1 **Descrição** Em implantações que utilizam o modo multi-equipe com um gerenciador de autenticação consciente de equipe, o endpoint de materialização de ativos `POST /api/v2/assets/{asset id}/materialize` e a verificação de resultado XCom em `wait dag run until finished` autorizam a Dag de destino sem verificar sua equipe. Isso ocorre porque o gerenciador de autenticação verifica o recurso `DAG` em vez do recurso `DAG:<team>`, ignorando as permissões de escopo de equipe. Consequentemente, um usuário autenticado de uma equipe pode disparar execuções de Dag pertencentes a outra equipe, fornecendo seu próprio `dag run id` e `conf`, e pode ler valores de XCom de outra equipe. Implantações que utilizam o gerenciador de autenticação FAB não são afetadas. **Recomendações** Atualize para a versão 3.3.1 ou posterior.

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.

**Nome do Software Vulnerável e Versões Afetadas** Apache Airflow versões anteriores a 3.3.1 **Description** O Task SDK não mascara o conteúdo de uma Variável quando seu valor JSON é uma lista. Isso ocorre porque a mascaração é aplicada apenas a valores desserializados que são strings ou dicionários, deixando listas de nível superior sem mascaração. Consequentemente, segredos armazenados neste formato aparecem em texto claro nos logs de tarefas e na interface Rendered Templates UI. Um usuário autenticado com permissões para visualizar logs de tarefas ou templates renderizados pode recuperar esses valores sem a necessidade de qualquer configuração especial. **Recommendations** Atualize para a versão apache-airflow 3.3.1 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** apache-airflow-providers-google versões anteriores a 22.3.0 **Description** O backend de segredos do Google Cloud Secret Manager no provedor Google falha ao aplicar o escopo de equipe ao resolver Conexões e Variáveis. Embora a variável `team name` seja aceita pelo backend, ela é descartada na fronteira de chamada interna, fazendo com que as pesquisas sejam resolvidas em relação a nomes de segredos agnósticos à equipe. Em implantações que utilizam o modo multi-equipe, isso permite que uma tarefa ou DAG pertencente a uma equipe resolva e obtenha as credenciais completas de uma Conexão ou Variável pertencente a outra equipe. **Recommendations** Atualize para a versão 22.3.0 ou posterior do apache-airflow-providers-google.

**Nome do Software Vulnerável e Versões Afetadas** Apache Airflow versão 3.3.0 **Description** No estado de tarefa `awaiting input`, o scheduler desserializa a variável `next kwargs` de uma instância de tarefa sem utilizar uma lista de permissões (allow-list). Um autor de DAG pode manipular esse valor através da API de execução de tarefas para disparar a importação de módulos arbitrários e a instanciação de objetos dentro do processo do scheduler, ou causar a terminação do job do scheduler. Esse processo ocorre automaticamente a cada 15 segundos e não é mitigado pela configuração padrão `allowed deserialization classes`. **Recommendations** Atualize para a versão 3.3.1 ou posterior do apache-airflow.

**Nome do Software Vulnerável e Versões Afetadas** Apache Airflow versões anteriores a 3.3.1 **Descrição** A camada de serialização falha ao restringir as classes importadas durante a reconstrução de nós de exceção. Ao chamar `import string()` em um nome de classe e instanciá-lo com argumentos de um blob serializado, o sistema permite que um chamável arbitrário seja importado e invocado. Isso pode ser acionado por meio do `executor config` de um operador, permitindo que um autor de Dag execute funções como `subprocess.check output` ou `builtins.eval`. O problema afeta o Scheduler, que reconstrói Dags serializadas, e o servidor de API através do endpoint `GET /api/v2/dags/{dag id}/details`. Ambos os componentes possuem acesso às credenciais do banco de dados de metadados e ao segredo de assinatura JWT. **Recomendações** Atualize para a versão apache-airflow 3.3.1 ou posterior.

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.

**Nome do Software Vulnerável e Versões Afetadas** Apache Airflow versões anteriores a 3.3.1 **Descrição** Dados sensíveis, incluindo valores de Variable e conteúdos de Connection `extra`, são gravados no log de auditoria em texto simples quando enviados através dos endpoints de processamento em lote `PATCH /api/v2/variables` e `PATCH /api/v2/connections`. Isso ocorre porque o mecanismo de mascaramento do log de auditoria reconhece apenas campos de requisição de nível superior, enquanto as requisições em lote aninham as entidades dois níveis abaixo, ignorando o processo de mascaramento. Consequentemente, qualquer usuário autenticado com acesso de leitura ao log de auditoria pode recuperar esses segredos, mesmo que não possua permissões específicas para ler Variables ou Connections. Além disso, a cópia do `extra` da Connection é armazenada sem criptografia no log, embora a tabela de conexões a criptografe. Este problema também é acionado pela ação Import Variables da interface do usuário do Airflow. **Recomendações** Atualize para a versão do apache-airflow 3.3.1 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** Apache Airflow versões anteriores a 3.3.1 **Descrição** Uma falha de autorização existe na API de Backfill onde uma discrepância na forma como o segmento de caminho `backfill id` é processado permite que um usuário autenticado com permissões de edição em qualquer Dag realize ações não autorizadas em outros Dags. A dependência de autorização utiliza `int()` para a análise, enquanto o manipulador de rota utiliza `NonNegativeInt` do pydantic, que aceita valores que o `int()` rejeita (por exemplo, `1.0` é convertido para `1`). Como o FastAPI resolve as dependências antes da validação do endpoint, a verificação de autorização e a operação real atuam em Dags diferentes. Isso permite que usuários leiam, pausem e cancelem backfills de outros Dags, ou movam execuções na fila para um estado de falha. Como os IDs de backfill são sequenciais, a identificação de alvos é trivial. **Recomendações** Atualize para a versão 3.3.1 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** apache-airflow-providers-yandex versões anteriores a 4.5.1 **Description** O backend de segredos Yandex Lockbox no provedor Yandex resolve um id de Conexão ou Variável com escopo de equipe por meio de uma busca agnóstica de equipe quando a busca com escopo de equipe falha. Em implantações que utilizam o modo multi-equipe, um usuário de uma equipe pode acessar segredos de outra equipe fornecendo um id que corresponda ao namespace dessa equipe, permitindo a recuperação total de credenciais. **Recommendations** Atualize para a versão 4.5.1 ou posterior do apache-airflow-providers-yandex.

**Nome do Software Vulnerável e Versões Afetadas** apache-airflow-providers-amazon versões anteriores a 9.34.0 **Description** Os backends do AWS Systems Manager Parameter Store e Secrets Manager no provedor Amazon resolvem um id de Conexão ou Variável com escopo de equipe por meio de uma busca agnóstica de equipe quando a busca com escopo de equipe falha. Em implantações que utilizam o modo multi-equipe, um usuário de uma equipe pode acessar segredos pertencentes a outra equipe ao fornecer um id que corresponda ao namespace dessa equipe, permitindo a recuperação total de credenciais. **Recommendations** Atualize para a versão 9.34.0 ou posterior do apache-airflow-providers-amazon.

**Nome do Software Vulnerável e Versões Afetadas** apache-airflow-providers-microsoft-azure versões anteriores a 14.1.0 **Description** O backend de segredos do Azure Key Vault no provedor Microsoft Azure resolve um id de Conexão ou Variável com escopo de equipe por meio de uma busca agnóstica de equipe quando a busca com escopo de equipe falha. Em implantações que utilizam o modo multi-equipe, um usuário de uma equipe pode acessar segredos pertencentes a outra equipe ao fornecer um id que corresponda ao namespace dessa equipe, permitindo a recuperação total de credenciais. **Recommendations** Atualize para a versão 14.1.0 ou posterior do apache-airflow-providers-microsoft-azure.

**Nome do Software Vulnerável e Versões Afetadas** apache-airflow-providers-fab versões anteriores a 3.7.2 **Description** No gerenciador de autenticação FAB do Apache Airflow, ocorre uma escalada de privilégios quando um DAG é criado com um `dag id` definido como `DAGs`. Este ID específico entra em conflito com o nome do recurso de permissão global para todos os DAGs gerado pela função `resource name()`. Consequentemente, um usuário com menos privilégios que receba `access control` por DAG para esse DAG específico recebe silenciosamente permissões globais, permitindo acesso de leitura e edição a todos os DAGs do sistema. **Recommendations** Atualize para o apache-airflow-providers-fab 3.7.2 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** apache-airflow versões anteriores a 3.3.0 **Description** Uma falha na função `BaseSerialization.deserialize()` permite a execução irrestrita de `import string()` de caminhos de classe controlados por um invasor quando o Scheduler ou o API Server carrega um DAG serializado. Um autor de DAG pode inserir um gatilho malicioso em um DAG para obter a execução remota de código no processo do API Server ou do Scheduler, ultrapassando a barreira de segurança que impede que o código do autor do DAG seja executado nesses processos. **Recommendations** Atualize para a versão 3.3.0 ou posterior do apache-airflow. Restrinja a configuração `[core] allowed deserialization classes` a uma lista de permissões restrita em implantações onde a confiança nos autores de DAG seja limitada.

**Nome do Software Vulnerável e Versões Afetadas** Apache Airflow versões anteriores a 3.3.0 **Description** Um erro no endpoint de grafo de agendamento `/ui/dependencies` permite que um usuário da interface autenticado com permissões de leitura em alguns Dags enumere identificadores de outros Dags que ele não tem autorização para ler. Embora o sistema aplique um filtro de Dags legíveis à chave de Dag serializada de nível superior, ele falha em propagar esse filtro para os campos `dep.source` e `dep.target` de entradas de dependência de gatilho (trigger) e sensor. Este problema afeta implantações que utilizam o escopo de leitura por Dag para manter a privacidade dos identificadores de Dag entre equipes. **Recommendations** Atualize para a versão 3.3.0 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** apache-airflow versões anteriores a 3.3.0 **Descrição** Ocorre uma falha de autorização quando um usuário com permissão para ler um Dag específico consegue expor o código-fonte de outros Dags localizados no mesmo arquivo de origem. Este problema afeta implantações que co-localizam múltiplos Dags em um único arquivo e dependem do controle de acesso por Dag. A falha reside no endpoint `GET /api/v2/dagSources/{dag id}` e na visualização de origem do Dag correspondente na interface do usuário, que retornam o arquivo de origem completo sem redigir os Dags não autorizados. A variável `dag id` é utilizada para identificar o Dag solicitado. **Recomendações** Atualize para a versão 3.3.0 ou posterior do apache-airflow.