Uma vulnerabilidade de severidade máxima no Kestra, plataforma open source utilizada para orquestração de workflows e pipelines, colocou administradores de infraestrutura em alerta. A falha permite que um atacante remoto ignore completamente a autenticação e execute comandos arbitrários como root dentro do worker do Kestra.
Identificada como CVE-2026-49869, a vulnerabilidade recebeu pontuação CVSS 10.0, o nível máximo da escala.
A situação ganhou urgência depois que a Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos, a CISA, adicionou a falha ao catálogo Known Exploited Vulnerabilities (KEV) em 2 de setembro, indicando evidências de exploração no mundo real.
A informação apresentada na imagem está, portanto, correta.
Há apenas uma precisão importante: o prazo de 5 de setembro de 2026 estabelecido pela CISA é obrigatório para órgãos federais civis dos Estados Unidos sujeitos às diretrizes da agência. Para empresas privadas, não é um prazo legal geral, embora a inclusão no KEV seja um forte indicativo de que a atualização deve receber prioridade máxima.
Kestra automatiza processos críticos
O Kestra é uma plataforma de orquestração orientada a eventos utilizada para construir e executar workflows.
Empresas podem utilizá-la para conectar bancos de dados, APIs, aplicações, scripts, pipelines de dados e diferentes componentes de infraestrutura.
Um workflow pode executar Python.
Outro pode iniciar comandos de shell.
Outro pode consultar sistemas internos.
Essa flexibilidade é justamente o que torna a CVE-2026-49869 particularmente perigosa.
Ao conseguir criar um fluxo malicioso, um invasor pode transformar funcionalidades legítimas da própria plataforma em mecanismos para executar comandos.
O erro estava em uma simples verificação de URL
A origem da vulnerabilidade chama atenção pela simplicidade.
O Kestra possui um endpoint público de configuração que precisa funcionar sem autenticação em determinados cenários.
Para identificar esse endpoint, o filtro de autenticação verificava se o caminho solicitado terminava com /configs.
O problema é que a aplicação não verificava se a requisição correspondia exatamente ao endpoint público esperado.
Na prática, diferentes rotas que terminassem em /configs também poderiam ser interpretadas como públicas.
O resultado era um bypass de autenticação.
Um invasor não precisava descobrir senha, roubar sessão ou comprometer previamente uma conta legítima.
Atacante pode criar workflow sem autenticação
O impacto aumenta porque identificadores utilizados pelo Kestra podem ser controlados dentro das próprias rotas da API.
Assim, um atacante poderia criar um fluxo com um identificador que explorasse a lógica vulnerável e fazer com que a requisição terminasse justamente em /configs.
O filtro então classificaria a operação incorretamente como autorizada.
A partir daí, seria possível criar ou alterar um workflow.
E é nesse ponto que um simples erro de autenticação se transforma em execução remota de código.
Plugins permitem executar comandos do sistema
O Kestra oferece plugins para execução de scripts e comandos.
Entre eles existem componentes para Shell, Python, Node.js e outras linguagens.
Essas funcionalidades são legítimas e fundamentais para uma plataforma de automação.
O problema ocorre quando um invasor consegue controlá-las.
Depois de criar um workflow malicioso por meio do bypass, o atacante pode solicitar sua execução e utilizar esses plugins para rodar comandos arbitrários.
Segundo o alerta de segurança do próprio projeto, a cadeia permite Remote Code Execution (RCE) sem autenticação.
Código pode ser executado como root
A gravidade chega ao máximo porque, nas configurações analisadas, o worker responsável por executar esses scripts opera como:
uid=0 — root.
Isso significa que o código do atacante pode possuir privilégios máximos dentro do contêiner do worker.
Essa distinção é importante.
“Root” não significa automaticamente que o invasor assumiu controle irrestrito do servidor físico ou de todo o cluster.
O advisory informa, por exemplo, que não foi confirmada uma fuga direta do contêiner por meio do socket do Docker.
Mesmo assim, controlar um worker como root é extremamente grave.
Dependendo da configuração do ambiente, o atacante pode encontrar credenciais, arquivos, tokens, volumes montados e conexões com outros serviços.
Ataque também pode alcançar a rede interna
A vulnerabilidade possui ainda um segundo impacto.
O Kestra expõe uma função HTTP em seu mecanismo de templates que pode realizar requisições sem filtragem adequada de destinos.
Combinada ao bypass de autenticação, essa característica permite ataques de Server-Side Request Forgery (SSRF).
Isso significa que o servidor comprometido pode ser induzido a realizar requisições para recursos que não estão diretamente acessíveis pela internet.
Um atacante pode tentar alcançar APIs internas, bancos de dados, outros serviços corporativos ou endpoints de metadados utilizados por provedores de nuvem.
Credenciais de nuvem podem entrar na mira
Esse cenário merece atenção especial em ambientes AWS, Azure e Google Cloud.
Máquinas virtuais e workloads em nuvem podem utilizar serviços internos de metadados para obter informações sobre a instância e, dependendo da configuração, credenciais temporárias associadas à identidade daquela carga.
Se um SSRF conseguir alcançar esses recursos e as proteções adicionais forem insuficientes, a invasão pode ultrapassar o próprio Kestra.
Em determinadas arquiteturas, isso poderia abrir caminho para acesso a outros recursos da conta de nuvem.
O impacto real depende da configuração e das permissões concedidas ao ambiente comprometido.
Atacante também pode apagar rastros
O problema não está limitado à execução de comandos.
O mesmo erro de autenticação pode atingir outros recursos cujas rotas terminem em configs.
O advisory descreve possibilidades de criar, modificar e excluir determinados recursos.
Entre os impactos possíveis está inclusive a remoção de logs relacionados a workflows específicos, dificultando a investigação posterior.
Isso adiciona uma dimensão importante ao incidente: além de obter acesso, um invasor pode tentar reduzir parte das evidências deixadas pelo ataque.
Falha recebeu CVSS 10.0
A combinação explica a classificação máxima.
O vetor CVSS indica:
ataque remoto pela rede;
baixa complexidade;
nenhuma credencial necessária;
nenhuma interação da vítima;
alto impacto sobre confidencialidade;
alto impacto sobre integridade;
alto impacto sobre disponibilidade.
O resultado é 10.0 de 10.
Para equipes de segurança, vulnerabilidades com esse perfil representam uma das situações mais críticas possíveis: um serviço acessível pela rede pode ser comprometido sem autenticação e sem participação do usuário.
Versões vulneráveis já possuem correção
A falha afeta versões anteriores às correções disponibilizadas pelo projeto.
No ramo 1.0, a atualização está disponível a partir da versão 1.0.45.
Na linha mais recente afetada, a correção foi incluída na 1.3.21.
Instalações executando versões vulneráveis devem atualizar para uma versão corrigida ou superior compatível com seu ambiente.
A correção altera a lógica responsável por identificar o endpoint público, impedindo que uma correspondência genérica baseada apenas no final da URL libere outras rotas.
CISA confirma exploração
O fator que transforma o problema de “vulnerabilidade crítica” em uma emergência operacional é sua entrada no Known Exploited Vulnerabilities Catalog.
A CISA adicionou a CVE-2026-49869 ao KEV em 2 de setembro de 2026.
O catálogo não reúne simplesmente vulnerabilidades teoricamente exploráveis.
Ele é destinado a falhas para as quais a agência possui evidências de exploração.
Isso significa que administradores não devem avaliar o problema apenas com base na pontuação CVSS.
Existe risco concreto de ataques.
Prazo excepcionalmente curto chama atenção
A CISA estabeleceu 5 de setembro de 2026 como data limite de remediação para as agências federais abrangidas pela determinação.
São apenas três dias desde a entrada da vulnerabilidade no catálogo.
Esse intervalo extremamente curto reflete a prioridade atribuída ao problema.
Além da atualização, a orientação inclui requisitos de triagem forense, justamente porque sistemas vulneráveis podem já ter sido comprometidos antes da aplicação do patch.
Para organizações privadas, a mensagem operacional também é clara: simplesmente atualizar pode não ser suficiente se uma instância vulnerável ficou exposta durante o período em que a exploração já estava ocorrendo.
Patch não apaga uma invasão anterior
Esse é um ponto frequentemente ignorado em vulnerabilidades exploradas ativamente.
Instalar a atualização impede novas explorações daquela falha.
Mas não remove necessariamente um invasor que já tenha conseguido entrar.
Se credenciais foram roubadas, contas foram criadas ou mecanismos de persistência foram implantados, eles podem continuar funcionando depois da atualização.
Por isso, organizações potencialmente expostas precisam considerar não apenas patch management, mas também investigação.
Logs de execução, alterações de workflows, contas, credenciais, conexões de saída e atividades incomuns nos workers merecem atenção.
Instâncias internas também podem estar vulneráveis
Outro detalhe importante é que a exploração não depende necessariamente de exposição direta à internet.
Uma instância acessível somente na rede corporativa pode continuar vulnerável a um atacante que já tenha obtido acesso interno.
Isso também amplia o risco de movimentação lateral.
Um invasor que comprometa inicialmente outro sistema pode procurar serviços Kestra dentro da infraestrutura e utilizar a CVE-2026-49869 para ampliar seus privilégios e alcance.
Kestra teve outras falhas relevantes em 2026
A CVE-2026-49869 também surge em um período de intensa pesquisa de segurança sobre a plataforma.
Outras vulnerabilidades divulgadas ao longo de 2026 envolveram problemas como leitura arbitrária de arquivos por path traversal, injeção SQL com possibilidade de execução de código, exposição de endpoints de gerenciamento e fragilidades relacionadas ao armazenamento de senhas.
Isso não significa necessariamente que o Kestra seja intrinsecamente inseguro.
Projetos open source amplamente analisados frequentemente acumulam CVEs justamente porque pesquisadores conseguem estudar seu código e reportar problemas.
Mas reforça a importância de manter a plataforma atualizada e evitar exposição desnecessária de interfaces administrativas.
Uma palavra errada abriu caminho até o root
A CVE-2026-49869 também oferece uma demonstração impressionante de como pequenas decisões de programação podem produzir consequências enormes.
O problema nasceu essencialmente da diferença entre perguntar:
“Esta é exatamente a rota pública autorizada?”
e perguntar:
“Esta rota termina com o mesmo texto da rota autorizada?”
Essa pequena diferença permitiu atravessar a barreira de autenticação.
A partir dela, funcionalidades legítimas de automação fizeram o restante.
O atacante poderia criar um workflow, acionar plugins de scripts e chegar à execução de código como root dentro do worker.
Agora que a CISA confirma exploração e estabeleceu prazo emergencial para órgãos federais americanos, a CVE-2026-49869 deixa de ser apenas mais uma falha crítica publicada em um banco de vulnerabilidades.
Para qualquer organização que utilize Kestra OSS em versões afetadas, ela deve ser tratada como prioridade imediata de correção e investigação de possível comprometimento.
