Andrew Rukin

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.

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 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.

Incorrect implementation of JWT/OAuth authentication in Impala executors in Apache Impala versions up to and including 4.5.2 which allows attacked to access resources served by the executor's webserver when that webserver is configured to accept JWT/OAuth tokens.  Bearer token (JWT) signatures are not validated resulting in the webserver accepting any valid JWT. Users are recommended to either disable JWT/OAuth auth for Impala executors or upgrade to version 4.5.3, which fixes this issue.

Um problema de path traversal existe na flag de inicialização `trusted jar paths`, que é utilizada para referenciar URIs para o carregamento de arquivos de sistemas de arquivos locais ou remotos. Isso permite que um invasor carregue um arquivo JAR controlado via um caminho relativo, desde que o prefixo corresponda a um caminho já especificado em `trusted jar paths`. Embora o esquema não possa ser sobrescrito, isso pode resultar na execução de um JAR previamente carregado em um local diferente no sistema de arquivos por meio de DDLs do Impala, como `CREATE DATA SOURCE` e `CREATE TABLE`. Este problema requer que a flag `trusted jar paths` tenha um valor não vazio configurado por um administrador.

Um problema de Cross-Site Scripting (XSS) armazenado existe onde um usuário SQL com apenas permissões de SELECT pode injetar JavaScript em um alias de tabela. Este script é executado no navegador de outro usuário quando este visualiza o plano de consulta através da Web UI do Impala.

O Dag de exemplo compute-cluster no provedor Teradata do Apache Airflow declara os Dag Params como texto livre não restringido. Esses valores são aplicados diretamente aos operadores de compute-cluster, que os interpolam no DDL (Data Definition Language) do Teradata. Um usuário com permissão para disparar o Dag pode fornecer fragmentos de SQL que são executados usando a conexão da tarefa. Além disso, como o ID da conexão é um Param de texto livre, o usuário pode redirecionar a tarefa para qualquer outra conexão definida na implantação.

Na interface `hs2-http`, a assinatura do token Bearer não é verificada durante a etapa final da autenticação SAML2. Essa falha permite que um invasor altere o nome do usuário e forje identidades para agir como outro usuário sem a necessidade de autenticação prévia.

Ocorre uma autenticação inadequada durante a validação do token portador SAML no HiveServer2 em implantações que utilizam transporte HTTP com `hive.server2.authentication=SAML`. Um invasor de rede não autenticado pode se autenticar como um usuário arbitrário do Hive e obter uma sessão autenticada do HiveServer2 enviando um token Authorization: Bearer forjado para o endpoint HTTP `/cliservice`. Este exploit não requer credenciais do Hive, login no Provedor de Identidade (IdP) SAML ou conhecimento do segredo de assinatura do servidor, exigindo apenas alcance de rede à porta HTTP do HiveServer2.

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.

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.

Existe um problema onde o comando `trust-fetch-domains` é restringido por uma permissão de apenas leitura no objeto de confiança em vez de uma permissão de administração de confiança. Isso permite que um usuário IPA autenticado e sem privilégios acione uma atualização de confiança do Active Directory privilegiada usando um servidor e credenciais fornecidos por um invasor. Isso pode resultar na modificação não autorizada de dados de identidade de domínio confiável e de intervalo de ID no diretório LDAP do IPA.

A Execução Remota de Código é possível através de Injeção de URL JDBC. Isso ocorre quando uma aplicação não sanitiza adequadamente a URL JDBC, permitindo que um atacante injete parâmetros maliciosos que podem levar à execução de código arbitrário no servidor.

A Execução Remota de Código é possível através da instanciação arbitrária de classes no componente `plugin-schema-registry`. A instanciação arbitrária de classes ocorre quando uma aplicação cria uma instância de uma classe especificada por entrada fornecida pelo usuário, o que pode levar à execução de código não autorizado.

A autenticação está ausente nas APIs de Download, o que pode permitir o acesso não autorizado a recursos.

Existe um problema no código do cliente onde a verificação do nome do host TLS não é realizada corretamente. A verificação do nome do host TLS (Transport Layer Security) é um processo que garante que o servidor ao qual o cliente está se conectando é realmente o servidor que ele afirma ser, verificando o nome do host no certificado.

Os logs contêm tokens JWT (JSON Web Tokens) replicáveis, que são meios compactos e seguros para URLs de representação de reivindicações a serem transferidas entre duas partes.

O componente UnixAuth carece de proteção contra ataques de força bruta. O UnixAuth é um método utilizado para autenticação de usuários em contas do sistema Unix.

Um problema permite a escalada de privilégios através da manipulação de um parâmetro de URL.

Os endpoints de detalhamento e listagem de instâncias de tarefa da REST API retornam os `trigger kwargs` de uma tarefa adiada sem mascaramento. Isso permite que qualquer usuário autenticado com acesso de leitura de instância de tarefa com escopo de DAG visualize informações sensíveis, como chaves de API de provedores, em texto claro enquanto a tarefa estiver adiada.