Dois avisos críticos descrevem caminhos para executar workflows sem autenticação. Outro aviso aponta acesso anônimo ao serviço gRPC da edição Open Source. As demais fichas explicam falhas na exclusão de recursos, nas restrições de acesso HTTP e nas respostas da aplicação. Para conferir seu ambiente, compare a versão instalada com cada faixa e examine a configuração ou o comportamento indicado na ficha.
AplicativoKestra
Data do compilado
Vulnerabilidades11
As pontuações reproduzem o CVSS 3.1 dos comunicados. As faixas afetadas e corrigidas mantêm os valores da API, inclusive sobreposições e intervalos sem limite superior. A situação corrigida indica uma correção informada pelo projeto, sem afirmar que sua instância recebeu a atualização. As ressalvas de cada ficha explicam as divergências presentes na fonte.
Gravidade críticaCVSS: 10,0/10Correção disponível
Separador codificado na URL evita o filtro de autenticação
O filtro de autorização analisa o caminho ainda codificado, mas o roteador usado para compatibilidade com URLs antigas trabalha com o caminho decodificado. Uma barra representada por %2F pode fazer a requisição escapar do filtro e depois alcançar um endpoint do tenant main. Na edição Open Source, esse caminho permite criar e executar workflows sem credenciais, com execução de comandos sob as permissões do processo.
Casos de uso afetados
Você expõe a interface HTTP da edição Open Source e usa uma versão afetada. O roteamento de URLs sem tenant pode aceitar chamadas anônimas de criação e execução de workflows.
Você executa tarefas com permissões de root e disponibiliza o socket do Docker no container. O comprometimento demonstrado pode alcançar o host por esse recurso montado.
Confira na sua instância
Identifique a linha exata da instalação e compare-a separadamente com a tabela. Revise os registros do proxy e do servidor procurando %2F junto ao segmento /api/v1, especialmente em chamadas para flows e executions. Na implementação implantada, confira se a normalização do caminho e o filtro de autenticação cobrem as mesmas rotas que TenantAliasingRooter encaminha.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
io.kestra:kestra 1.0.x
< 1.0.60
1.0.60
io.kestra:kestra 1.1.x
>= 1.1.0, <= 1.1.20
Não informadas
io.kestra:kestra 1.2.x
>= 1.2.0, <= 1.2.24
Não informadas
io.kestra:kestra 1.3.x
>= 1.3.0, < 1.3.38
1.3.38
O aviso se aplica à edição Open Source. A API informa versões corrigidas para as linhas 1.0 e 1.3, mas deixa patched_versions vazio nas linhas 1.1 e 1.2. A situação corrigida não indica uma correção disponível dentro dessas duas linhas.
Gravidade críticaCVSS: 9,8/10Correção disponível
Prefixo público do webhook libera a execução comum de workflows
O filtro de autenticação interpreta as entradas de open-urls como prefixos. O prefixo destinado aos webhooks também coincide com a rota comum de execução quando o namespace se chama exatamente webhook. Uma chamada anônima pode iniciar workflows desse namespace com entradas escolhidas pelo atacante, sem fornecer a chave de um gatilho. Segredos presentes nas saídas podem ser expostos e tarefas de shell que incorporam essas entradas podem executar comandos.
Casos de uso afetados
Você mantém workflows no namespace webhook e usa as entradas padrão de open-urls. Esses workflows podem receber execuções anônimas pelo endpoint comum, inclusive com seleção de uma revisão anterior.
Você usa entradas do workflow dentro de comandos de shell ou devolve segredos nos outputs. A execução anônima pode produzir comandos não autorizados ou revelar essas credenciais.
Confira na sua instância
Localize workflows no namespace exato webhook e leia kestra.server.basic-auth.open-urls. Confira se a versão implantada distingue a rota comum de execução da rota de gatilho, que inclui namespace, id e key. Revise os registros de acesso a /api/v1/main/executions/webhook/<id> e associe eventuais respostas de sucesso às execuções criadas, sem iniciar workflows de produção para conferir a falha.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
io.kestra:kestra
<= 1.3.37
1.3.38
A colisão demonstrada exige o namespace exato webhook. Nomes como webhooks, Webhook e webhook.prod não reproduziram esse caminho. A execução como root ocorreu no ambiente da demonstração e depende das permissões do processo no seu ambiente.
Gravidade altaCVSS: 8,3/10Correção disponível
Serviço gRPC aceita acesso anônimo ao controle dos workers
A edição Open Source abre um servidor gRPC separado, normalmente na porta 50051, com transporte sem criptografia e sem verificação de credenciais. A autenticação do servidor HTTP não alcança esse serviço. Um cliente com acesso à porta pode consultar ou alterar metadados de namespaces e se registrar como worker, recebendo configurações e enviando resultados falsos de tarefas.
Casos de uso afetados
Você executa a edição Open Source em modo standalone ou webserver e a porta 50051 está acessível a máquinas sem autorização para atuar como workers.
Você usa o chart Helm sem uma NetworkPolicy que restrinja o acesso ao controller. Outros pods do cluster podem alcançar o serviço mesmo quando ele não está publicado na internet.
Confira na sua instância
Confira a edição instalada, os endereços de escuta e a exposição da porta 50051 nos Services ou na configuração de acesso do host. Verifique quais origens conseguem chegar ao controller e limite esse acesso aos workers autorizados. Na versão atualizada, confira o mecanismo de autenticação aplicado ao servidor gRPC, pois uma resposta 401 do servidor HTTP não comprova a proteção dessa porta.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
kestra (Open Source)
>= 2.0.0
2.0.3
A API informa correção em 2.0.3, embora o corpo do aviso ainda diga que não há versão corrigida após analisar 2.0.2. O relato foi fundamentado na análise do código, sem execução em um cluster. A edição Enterprise usa mecanismos diferentes e não é afetada da mesma forma.
Gravidade moderadaCVSS: 6,5/10Correção disponível
Validação da URL permite contornar restrições das chamadas HTTP
As listas de destinos permitidos e proibidos comparam o início da URL inteira, sem identificar corretamente o host da conexão. Endereços com sufixos adicionais ou informações de usuário podem satisfazer essa comparação e apontar para outro destino. Além disso, a validação ocorre somente na URL inicial, permitindo que um redirecionamento conduza a chamada a um endereço que deveria ser recusado.
Casos de uso afetados
Você usa allowed-list ou denied-list para restringir chamadas feitas por workflows. Um editor pode influenciar uma tarefa HTTP ou a função http() para alcançar um serviço interno por uma URL aceita indevidamente ou por um redirecionamento.
Confira na sua instância
Confira as duas listas na configuração efetiva e o uso de followRedirects nas chamadas dos workflows. Na implementação de HttpClient da sua versão, a validação deve considerar o host obtido da URL e cada destino de redirecionamento. Listas vazias deixam essas restrições inativas. Confira também o aviso GHSA-g769-pv29-qhff, que descreve outra falha na versão 2.0.1.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
io.kestra:core
2.0.0
>= 2.0.1
O relato distingue a comparação de URLs demonstrada da análise de código sobre redirecionamentos. Também registra que a preservação de informações de usuário na URL não foi confirmada especificamente para o caminho Pebble http().
Gravidade moderadaCVSS: 5,4/10Correção disponível
Workflows excluídos continuam disponíveis para execução
A exclusão grava uma revisão marcada como removida, mas o caminho de criação de execuções consulta o workflow com allowDeleted=true. A validação seguinte recusa workflows desabilitados ou inválidos e não verifica a marca de exclusão. Assim, um workflow ausente da interface ainda pode executar tarefas e acessar os segredos que utiliza.
Casos de uso afetados
Você exclui um workflow para aposentar um script ou interromper o uso de uma credencial. Uma chamada autenticada ao endpoint de execução ainda pode iniciar esse workflow, apesar de a consulta e a busca indicarem que ele foi removido.
Confira na sua instância
Cruze o histórico de exclusões com as execuções posteriores dos mesmos pares namespace e flowId. Na versão instalada, confira se getFlowIfExecutableOrThrow rejeita o estado deleted e se a consulta usada para executar workflows exclui as revisões removidas. O desaparecimento na interface não comprova que a execução foi recusada.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
io.kestra:kestra
<= 1.3.38
1.3.39, 2.0.0
Na edição Open Source com autenticação ativa, o cenário demonstrado exige acesso autenticado. Outros caminhos que permitam iniciar execuções podem ampliar a exposição.
Gravidade moderadaCVSS: 5,3/10Correção disponível
Identificação de nomes de acesso pelo tempo de autenticação
A autenticação básica compara o nome informado com o nome configurado e só verifica a senha com bcrypt quando eles coincidem. Como essa verificação exige mais processamento, uma tentativa com o nome correto demora mais mesmo usando uma senha errada. Um atacante sem credenciais pode comparar as respostas para descobrir um nome de acesso válido.
Casos de uso afetados
Você mantém a autenticação básica habilitada e permite acesso externo ao servidor. Tentativas recusadas podem revelar o nome configurado pela diferença de duração, embora todas retornem uma falha de autenticação.
Confira na sua instância
Confira a versão em execução e a configuração da autenticação básica. Na implementação correspondente à sua instalação, examine BasicAuthService.isAuthenticated(): a comparação do nome não deve dispensar o processamento equivalente de senha para nomes inexistentes. Uma resposta 401, isoladamente, não confirma a correção dessa diferença de tempo.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
Kestra
< 2.0.0
2.0.0
A falha revela a existência do nome de acesso. O comunicado não demonstra descoberta da senha por esse mecanismo.
Gravidade moderadaCVSS: 5,3/10Correção disponível
Erros do webhook revelam quais workflows existem
O endpoint público de webhook procura o workflow antes de validar a chave do gatilho. Um workflow inexistente recebe a mensagem Flow not found, enquanto um existente com chave incorreta recebe Webhook not found. Essa diferença permite descobrir nomes de workflows e namespaces sem autenticação, além de selecionar workflows existentes para tentativas contra suas chaves.
Casos de uso afetados
Você publica webhooks para integrações externas e usa nomes de namespaces que identificam ambientes ou sistemas internos. Mesmo sem conhecer uma chave válida, um atacante pode confirmar a existência desses workflows pelas mensagens de erro.
Confira na sua instância
Examine o tratamento de erros do webhook na versão implantada e as respostas já registradas para chamadas com chave incorreta. A correção deve devolver 404 com Webhook not found também quando o workflow estiver ausente, desabilitado ou inválido. Compare o campo message, pois o código 404 aparece tanto nas respostas vulneráveis quanto nas corrigidas.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
io.kestra:kestra
<= 1.3.38, 2.0.0
1.3.39, 2.0.1
A enumeração não fornece a chave do webhook. O comunicado registra que uma pequena diferença de tempo permanece após a uniformização das mensagens, considerada impraticável para exploração remota com chave literal e variação normal da rede.
Gravidade moderadaCVSS: 4,3/10Correção disponível
Campo de ordenação inválido expõe consultas e estrutura do banco
Alguns endpoints de busca aceitam o campo sort sem conferir se a coluna pode ser usada para ordenar. Uma coluna inexistente provoca uma exceção do banco, cuja mensagem é incluída na resposta HTTP 500. Um participante autenticado pode receber a consulta SQL completa e identificar nomes de tabelas ou colunas pela diferença entre respostas de sucesso e erro.
Casos de uso afetados
Você permite consultas autenticadas aos logs ou aos gatilhos em uma instalação com repositório JDBC. Um campo de ordenação inválido pode revelar detalhes internos do banco mesmo para acessos limitados à leitura.
Você usa as buscas de workflows, as listagens de dashboards ou o armazenamento de chave e valor. O comunicado identifica caminhos equivalentes nessas consultas.
Confira na sua instância
Examine respostas de erro já registradas nas consultas a logs/search e triggers/search, procurando consultas SQL ou mensagens de coluna inexistente. Na versão instalada, confira a lista de campos aceitos por PageableUtils e o tratamento de exceções em ErrorController. O endpoint executions/search serve como referência no aviso: um campo inválido recebe 422 sem expor a consulta.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
io.kestra:kestra
<= 2.0.0
2.0.0
A API inclui 2.0.0 na faixa afetada e também a informa como versão corrigida. Essa sobreposição foi preservada e exige conferência do comportamento da instalação. O mecanismo demonstrado expõe informações por mensagens de erro, sem comprovar injeção SQL.
Gravidade moderadaCVSS: 4,3/10Correção disponível
Revisões de arquivos excluídos permanecem acessíveis
A exclusão de um arquivo de namespace remove sua referência das consultas, mas conserva os objetos no armazenamento. Ao receber revision, o caminho de leitura procura uma revisão cujo objeto ainda exista e pode devolver o conteúdo antigo. Um arquivo ausente da busca e da listagem pode, portanto, continuar acessível, incluindo credenciais removidas por você.
Casos de uso afetados
Você exclui um arquivo de namespace porque ele continha uma credencial. Um acesso com permissão de leitura pode recuperar o conteúdo de uma revisão anterior, apesar de a consulta normal retornar 404.
Você concede acesso a um namespace na edição Enterprise após a exclusão de um arquivo. O novo acesso pode permitir a leitura de conteúdo anterior à concessão da permissão.
Confira na sua instância
Confira a versão de io.kestra:core e o tratamento de exclusão em InternalNamespace. A remoção precisa alcançar os objetos armazenados, não somente os metadados. Em homologação, use um arquivo descartável com duas revisões e marcadores sem credenciais: após excluí-lo, compare a leitura normal com a leitura da primeira revisão. A correção deve recusar a recuperação do conteúdo excluído.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
io.kestra:core 1.3.x
>= 1.2.0
1.3.40
io.kestra:core 2.0.x
>= 1.2.0
2.0.3
A API repete a faixa >= 1.2.0 para as duas correções, sem informar limites superiores. A demonstração usou 2.1.0-SNAPSHOT. Excluir o arquivo não revoga uma credencial que já tenha sido exposta, portanto confira também sua substituição no serviço correspondente.
Gravidade moderadaCVSS: 4,2/10Correção disponível
Lista de hosts permitidos inclui subdomínios sem indicação explícita
Na versão 2.0.1, uma entrada em kestra.tasks.http.allowed-list autoriza o host configurado e seus subdomínios. Uma configuração destinada a permitir somente api.trusted.com também aceita foo.api.trusted.com. Um participante com capacidade de editar ou influenciar um workflow pode alcançar serviços nesses subdomínios, inclusive destinos sob controle de terceiros em domínios compartilhados.
Casos de uso afetados
Você configurou allowed-list para restringir as chamadas HTTP a hosts específicos. A falha amplia os destinos disponíveis às tarefas HTTP, ao gatilho de consulta HTTP e à função http() do Pebble.
Confira na sua instância
Leia o valor efetivo de kestra.tasks.http.allowed-list na configuração do servidor e confira se há hosts com subdomínios que você não pretendia autorizar. Na versão 2.0.2, uma entrada sem curinga deve corresponder somente ao host exato. A inclusão de subdomínios exige uma entrada explícita como *.api.trusted.com.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
io.kestra:core
2.0.1
2.0.2
Este aviso afeta instalações com allowed-list configurada. Confira individualmente os hosts e seus subdomínios aceitos pela configuração. Essa conferência permite localizar destinos aceitos indevidamente, mas não altera o comportamento permissivo da versão 2.0.1.
Gravidade baixaCVSS: 2,6/10Correção disponível
Nome de exportação permite inserir parâmetros no cabeçalho
A exportação de arquivos concatena o namespace diretamente ao nome do ZIP no cabeçalho Content-Disposition. Aspas recebidas nesse segmento da URL podem encerrar o nome original e inserir outro parâmetro filename. Um link preparado dessa forma pode induzir o navegador a gravar a exportação com um nome enganoso, conforme o tratamento de parâmetros duplicados pelo cliente.
Casos de uso afetados
Você abre um link de exportação de arquivos de namespace recebido de outro participante. O segmento usado no link pode alterar o nome sugerido para o download, embora o conteúdo retornado continue sendo uma exportação ZIP.
Confira na sua instância
Inspecione o cabeçalho Content-Disposition de uma exportação normal e confira a implementação de NamespaceFileController.export na versão instalada. O namespace deve receber validação e codificação apropriadas ao cabeçalho. Examine também as exportações de dashboards, pois o comunicado identifica a mesma concatenação para id e chartId.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
io.kestra:kestra
<= 2.0.0
2.0.1
O framework rejeita caracteres CR/LF no cabeçalho. A demonstração se limita à alteração de parâmetros do nome do download, sem divisão da resposta HTTP.
Programador há mais de 20 anos, fundador da Powertic e da Promovaweb. Embaixador do n8n no Brasil e da Baserow, Chatwoot, Miro e Kestra. Membro do Product Team do Mautic.
Canais oficiais
Nossos Links
Encontre a Promovaweb no canal que combina com o seu próximo passo.
