A CISA acendeu o sinal vermelho ao adicionar sete novas vulnerabilidades CISA KEV ao catálogo de Vulnerabilidades Conhecidas e Exploradas. A lista, atualizada em 2 de setembro de 2026, reúne falhas em componentes e plataformas que podem aparecer em ambientes Linux, infraestrutura de automação, gateways de inteligência artificial, repositórios de software e appliances de acesso remoto.
O alerta ganha ainda mais peso porque as vulnerabilidades já estão associadas a exploração ativa, e não apenas a possíveis ataques futuros. Entre os problemas estão falhas com CVSS 10,0, execução remota de comandos, injeção SQL, bypass de autenticação e problemas de processamento HTTP. Em ambientes comprometidos, pesquisadores observaram shells reversos, roubo de credenciais, acesso a contêineres Docker e implantação de mineradores de criptomoedas.
As vulnerabilidades CISA KEV que exigem atenção imediata
As sete entradas envolvem seis produtos diferentes. O ponto em comum é a possibilidade de transformar uma vulnerabilidade aparentemente específica em uma porta de entrada para comprometimento de infraestrutura.
| Produto | CVE | CVSS | Problema |
|---|---|---|---|
| Kestra OSS | CVE-2026-49869 | 10,0 | Injeção de comandos/execução de workflows |
| SonicWall SMA1000 | CVE-2026-83548 | 10,0 | SSRF pré-autenticação |
| SonicWall SMA1000 | CVE-2026-83549 | 7,8 | Injeção de comandos no SO |
| Sangoma Switchvox | CVE-2026-9586 | 9,3 | Injeção SQL |
| JFrog Artifactory | CVE-2026-82329 | 9,8 | Autenticação inadequada |
| Kludex Starlette | CVE-2026-48710 | 6,5 | Validação HTTP inadequada |
| BerriAI LiteLLM | CVE-2026-59822 | 8,8 | Bypass de autenticação |
Kestra OSS: CVE-2026-49869
A CVE-2026-49869 é uma das falhas mais preocupantes da lista. Com CVSS 10,0, o problema afeta o Kestra OSS, plataforma open source de orquestração de workflows.
A falha está relacionada à forma como o componente de autenticação verifica determinados caminhos da API. Um atacante remoto não autenticado pode explorar essa inconsistência para burlar a autenticação, criar workflows arbitrários e executá-los. Como o Kestra possui mecanismos capazes de executar scripts, o resultado pode ser execução remota de código no ambiente do worker. A correção está disponível nas versões 1.0.45 e 1.3.21.
O risco deixou de ser teórico. A Microsoft observou uma cadeia de ataque na qual a exploração do Kestra foi seguida por execução de shell, descoberta do ambiente Docker, acesso ao socket do Docker e implantação de mineradores XMRig.
SonicWall SMA1000: duas falhas em uma mesma superfície
O SonicWall SMA1000 aparece duas vezes no catálogo.
A CVE-2026-83548, com CVSS 10,0, permite SSRF pré-autenticação por meio de um comportamento de proxy não intencional. Já a CVE-2026-83549, com CVSS 7,8, permite injeção de comandos no sistema operacional, exigindo autenticação administrativa para exploração dessa segunda etapa.
A própria SonicWall confirmou que as duas vulnerabilidades estão sendo exploradas ativamente na internet e afetam determinadas versões de firmware da série SMA 1000.
Para administradores, isso significa que simplesmente verificar se existe uma interface SMA exposta não é suficiente. É necessário identificar a versão, aplicar as correções do fabricante e investigar sinais de comprometimento caso o equipamento estivesse acessível externamente.
Sangoma Switchvox: SQL Injection com potencial para RCE
A CVE-2026-9586, no Sangoma Switchvox, possui CVSS 9,3 e está relacionada a uma injeção SQL não autenticada.
O problema está no processamento de determinados dados enviados ao endpoint /pa. A entrada controlada pelo atacante pode acabar sendo incorporada diretamente a consultas PostgreSQL sem sanitização adequada. Em determinadas condições, isso permite manipular o banco de dados e potencialmente chegar à execução de código no sistema operacional.
O risco é particularmente elevado em instalações nas quais o serviço de provisionamento está acessível pela internet.
JFrog Artifactory: autenticação pode abrir caminho para administração
A CVE-2026-82329 recebeu classificação CVSS 9,8 e afeta o JFrog Artifactory.
A falha está relacionada a uma fraqueza de autenticação que, sob determinadas configurações padrão, pode permitir que um atacante com acesso à rede obtenha privilégios administrativos sem autenticação adequada.
O problema é especialmente sensível para ambientes DevOps. O Artifactory frequentemente armazena pacotes, imagens de contêineres, artefatos de CI/CD e componentes usados por aplicações corporativas. Um comprometimento administrativo, portanto, pode ultrapassar os limites de um único servidor e atingir toda a cadeia de desenvolvimento e distribuição.
Starlette: falha HTTP pode enfraquecer controles de segurança
A CVE-2026-48710 possui CVSS 6,5 e afeta versões do framework Starlette anteriores à 1.0.1.
O problema envolve a validação do cabeçalho HTTP Host e a reconstrução de request.url. Um cabeçalho manipulado pode fazer com que determinadas aplicações interpretem de maneira incorreta o caminho solicitado. Isso pode permitir o contorno de mecanismos de segurança que dependam dessas informações.
Apesar da pontuação inferior às demais falhas do alerta, o caso é importante para desenvolvedores porque Starlette é uma dependência de aplicações Python baseadas em ASGI. Uma vulnerabilidade em uma biblioteca aparentemente secundária pode alcançar serviços muito maiores.
LiteLLM: bypass de autenticação coloca credenciais de IA em risco
A CVE-2026-59822 afeta o LiteLLM, gateway utilizado para conectar aplicações a diferentes provedores de modelos de linguagem.
Com CVSS 8,8, a falha permite que um atacante não autenticado utilize um token Bearer arbitrário para explorar uma rota de fallback de autenticação no endpoint MCP Streamable HTTP. O resultado pode ser acesso a ferramentas MCP configuradas sem uma chave LiteLLM válida. A vulnerabilidade foi corrigida na versão 1.84.0.
O problema é maior do que simplesmente perder acesso a uma API. Um gateway de IA pode concentrar chaves de provedores, tokens, configurações de modelos, credenciais de banco de dados e chaves virtuais.
Como os atacantes estão explorando infraestrutura de IA e contêineres
A pesquisa da Microsoft ajuda a explicar por que essas vulnerabilidades são tão relevantes. Em investigações recentes, a empresa observou ataques contra diferentes workloads de IA, incluindo LiteLLM, RAGFlow e Kestra.
O padrão observado foi bastante consistente: obter acesso inicial, roubar credenciais, estabelecer persistência e transformar recursos computacionais comprometidos em fonte de lucro.
No caso do Kestra, a exploração permitiu que o invasor executasse comandos a partir do contexto do worker. Em seguida, houve descoberta do ambiente de contêineres e interação com o socket do Docker.
Esse detalhe é crítico. Quando um contêiner possui acesso ao socket do Docker, o comprometimento da aplicação pode proporcionar uma ponte para consultar outros contêineres e seus ambientes. Variáveis de ambiente podem conter senhas, tokens, chaves de API e credenciais de serviços internos.
A cadeia observada pela Microsoft também incluiu a implantação do XMRig, utilizado para mineração de Monero. O atacante transforma CPU roubada em receita, enquanto a organização afetada assume o custo computacional.
Roubo de chaves transforma o gateway de IA em alvo estratégico
No caso do LiteLLM, os pesquisadores observaram comportamento ainda mais preocupante.
Após o comprometimento, os atacantes procuraram informações no ambiente do processo, incluindo valores relacionados a API keys, tokens, senhas e conexões de banco de dados. Em ambientes conteinerizados, informações presentes no ambiente do processo principal podem ser especialmente valiosas.
Também houve acesso a dados armazenados no PostgreSQL utilizado pelo LiteLLM, incluindo registros relacionados à configuração de modelos e tokens virtuais.
Isso cria uma segunda camada de risco. Mesmo que o servidor comprometido seja posteriormente reconstruído, as credenciais roubadas podem continuar válidas em provedores externos.
Por isso, uma resposta adequada não termina com a instalação do patch. É necessário considerar rotação de chaves, revogação de tokens, revisão de acessos e investigação dos registros de uso das APIs.
Por que a infraestrutura de IA virou um alvo tão valioso
A expansão de ferramentas como LiteLLM, Flowise, LangChain, ChromaDB, Ollama e plataformas de orquestração criou uma nova camada de infraestrutura dentro das empresas.
Esses componentes podem ficar próximos de bancos de dados, modelos, APIs externas, contêineres, sistemas de armazenamento e credenciais de produção.
Na prática, isso transforma uma aplicação de IA em um possível ponto de concentração de privilégios.
O atacante não precisa necessariamente roubar o modelo de linguagem. Pode ser muito mais lucrativo obter a chave da API, acessar uma conta corporativa de alto consumo ou utilizar servidores comprometidos para mineração.
A exploração também demonstra uma mudança importante no cenário de ameaças: infraestrutura de IA deve ser tratada como infraestrutura crítica, com inventário, segmentação, gerenciamento de segredos, autenticação forte, controle de saída de rede e monitoramento de processos.
Prazos de correção das vulnerabilidades CISA KEV
As sete vulnerabilidades foram adicionadas ao catálogo em 2 de setembro de 2026. Para a maior parte das entradas, o prazo estabelecido é 5 de setembro, enquanto a CVE-2026-59822 do LiteLLM possui prazo até 16 de setembro de 2026.
O prazo de 5 de setembro é especialmente urgente para Kestra, SonicWall SMA1000, Switchvox e Artifactory, que aparecem entre os casos mais críticos da lista. A classificação KEV indica que a prioridade não deve ser determinada apenas pelo número do CVSS, mas pela evidência de que a vulnerabilidade está sendo explorada.
Para administradores Linux, DevSecOps e equipes de infraestrutura de IA, a recomendação é direta:
1. Inventarie imediatamente instâncias de Kestra, LiteLLM, Starlette, Artifactory, Switchvox e SonicWall SMA1000.
2. Atualize os componentes vulneráveis para versões corrigidas ou aplique as mitigações oficiais quando uma atualização imediata não for possível.
3. Revise a exposição à internet, principalmente interfaces administrativas, gateways de IA, APIs e serviços de orquestração.
4. Audite contêineres Docker, procurando processos desconhecidos, binários ELF recentes, consumo anormal de CPU, alterações em authorized_keys e conexões inesperadas para serviços externos.
5. Faça rotação das credenciais, especialmente chaves de provedores de IA, tokens virtuais, credenciais PostgreSQL e segredos armazenados em variáveis de ambiente.
6. Procure sinais de persistência, incluindo tarefas cron, chaves SSH adicionadas, arquivos ocultos e alterações inesperadas em serviços.
7. Monitore mineração de criptomoedas, conexões com pools de mineração e execução de processos como XMRig.
O alerta da CISA deixa uma mensagem importante para o ecossistema open source: uma biblioteca ou ferramenta de infraestrutura aparentemente isolada pode se transformar no ponto de entrada para toda uma cadeia de ataque.
No caso da IA, o risco é ainda maior porque gateways e plataformas de automação podem reunir credenciais, dados, execução de código e acesso a outros serviços no mesmo ambiente.
Para quem administra Linux, Docker ou infraestrutura de IA, portanto, este não é um alerta para acompanhar depois. As vulnerabilidades CISA KEV já estão sendo exploradas, e os prazos de correção estão próximos. A prioridade agora deve ser identificar ativos vulneráveis, aplicar as correções e, principalmente, verificar se algum sistema já foi comprometido.
