Gateways de IA viraram alvo: Microsoft viu roubo de chaves e mineração

Em 26 de agosto de 2026, a Microsoft publicou uma investigação sobre três comprometimentos distintos: um gateway LiteLLM, uma implantação RAGFlow e um ambiente de orquestração Kestra. O relatório da Microsoft Security Research documenta roubo de credenciais, mecanismos de persistência e abuso de capacidade computacional; a mineração apareceu nos casos LiteLLM e Kestra, não no RAGFlow.

Uma reportagem publicada no dia seguinte pela CISO Voice confirmou a divulgação dos três casos e destacou o ponto comum: essas plataformas concentram chaves de provedores, conexões de banco, configurações de locatários e privilégios de execução. Os incidentes não foram atribuídos a um único grupo, e nem todos os vetores de entrada foram determinados.

O alcance depende da função de cada superfície

Gateway, sistema de RAG e orquestrador não expõem exatamente os mesmos ativos. A contenção precisa partir do processo comprometido e mapear tudo o que ele podia ler, executar ou alcançar, em vez de se limitar à senha administrativa do produto.

• Gateway — LiteLLM: o ambiente podia expor chaves de provedores, chave mestra do proxy, chaves virtuais, credenciais da interface e a conexão do PostgreSQL. Os sinais observados incluíram leitura de /proc/1/environ, processos Python e shell iniciados pelo gateway, execução em diretórios temporários, alterações em chaves SSH e preparação para mineração.
• RAG — RAGFlow: um hook oculto foi inserido no fluxo de configuração de LLMs. Ele capturava chaves de API fornecidas após a infecção, além do tipo de provedor, nome do modelo e metadados de endpoint, enquanto a configuração continuava funcionando.
• Orquestrador — Kestra: workflows maliciosos abriram shells no worker. O acesso ao socket do Docker permitiu consultar ambientes de outros contêineres, e a execução do XMRig consumiu recursos do host.

Isso produz três prioridades diferentes: no LiteLLM, revogar segredos do gateway e do banco; no RAGFlow, considerar expostas também as credenciais inseridas depois da invasão; no Kestra, ampliar a investigação para contêineres e serviços visíveis ao worker.

LiteLLM virou origem de comandos e coleta

No LiteLLM, o acesso inicial foi avaliado com alta confiança como exploração da superfície exposta do gateway. A cadeia era compatível com a CVE-2026-42271, que fornece execução autenticada de comandos, combinada à CVE-2026-48710, uma falha do Starlette capaz de enfraquecer a barreira de autenticação em configurações vulneráveis. Essa combinação foi apontada como um caminho provável, não como prova definitiva do vetor usado.

O aviso revisado do GitHub classifica a CVE-2026-42271 como de alta severidade: entre as versões 1.74.2 e anteriores à 1.83.7, dois endpoints de teste MCP stdio podiam iniciar no host o comando fornecido por um usuário com chave válida do proxy. A correção passou a exigir permissão administrativa e a rejeitar configurações stdio nesses endpoints.

Depois da execução, o payload leu o ambiente do processo, recuperou a conexão do PostgreSQL e consultou registros de configuração de modelos e chaves virtuais. Também preparou mineração, usou nomes semelhantes aos de serviços Linux e criou persistência por meio de authorized_keys, cron, arquivos ocultos e atributos imutáveis.

Os indicadores mais úteis são comportamentais: filhos Python ou shell inesperados do processo LiteLLM, leitura de /proc/1/environ, execução em /tmp, acesso incomum às tabelas do proxy e conexões externas incompatíveis com os provedores autorizados. A rotação deve abranger chaves de modelos, chave mestra, chaves virtuais, credenciais da interface e do banco.

RAGFlow podia roubar chaves criadas depois da invasão

O caso RAGFlow exige cuidado especial porque o implante não se limitava a copiar segredos já armazenados. A telemetria mostrou uma alteração no caminho de inicialização ou importação da aplicação para carregar um hook oculto, ligado ao fluxo usado para adicionar ou modificar configurações de LLM.

Esse hook interceptava novas chaves de provedores e metadados de modelos, enviava o material para infraestrutura externa e suprimia erros para não interromper o funcionamento normal. Portanto, simplesmente trocar uma chave enquanto a aplicação continuava comprometida poderia entregar a nova credencial ao invasor.

Houve uma sondagem semelhante a SSRF antes da execução de código, mas a vulnerabilidade específica permanece incerta. Falhas públicas do RAGFlow oferecem caminhos tecnicamente plausíveis, porém nenhuma foi confirmada como causa do incidente. A contenção precisa retirar a instância de serviço, comparar seus arquivos com uma imagem confiável e examinar alterações no caminho de inicialização antes de emitir novas chaves.

Kestra converteu workflows em acesso ao host

No Kestra, a avaliação foi de alta confiança para um acesso inicial provavelmente relacionado à CVE-2026-49869, uma vulnerabilidade crítica de bypass de autenticação. O caminho permitia definir um workflow malicioso com o executor de processos e disparar scripts no worker sem uma sessão autenticada válida.

A partir do worker, os atacantes abriram shells, consultaram o socket do Docker e enumeraram variáveis de ambiente de contêineres alcançáveis. Esse acesso podia revelar tokens de nuvem, senhas de banco, chaves de API e endpoints internos, ampliando o incidente para além do próprio orquestrador.

A telemetria também mostrou download, renomeação e execução em segundo plano do XMRig, além de comunicação com um pool de mineração. Em uma etapa posterior, um script coletou dados e armazenou o resultado pela própria API de chave-valor do Kestra. Workflows desconhecidos, shells filhos do worker Java, consultas inesperadas ao Docker e uso persistente de CPU formam o conjunto prioritário de sinais.

Isolamento vem antes da rotação

A sequência defensiva começa pelo inventário das instâncias LiteLLM, RAGFlow e Kestra expostas à internet ou a redes excessivamente amplas. Cargas suspeitas devem ser isoladas e ter a saída de rede restringida, preservando processos, arquivos modificados, histórico de workflows e registros de conexão antes da reconstrução.

1. Delimitar o alcance: identificar quais segredos, bancos, identidades de nuvem, contêineres e serviços internos estavam acessíveis ao processo comprometido.
2. Remover a persistência: revisar chaves SSH, cron, arquivos imutáveis e temporários, inicialização do RAGFlow, workflows do Kestra e dados gravados em APIs internas.
3. Revogar os segredos: substituir chaves de modelos, chaves virtuais, tokens de nuvem e credenciais de banco somente depois de bloquear o mecanismo que poderia capturá-los novamente.
4. Reduzir a superfície: corrigir as aplicações, exigir autenticação nas interfaces, manter bancos em endpoints privados, restringir o socket do Docker e adotar saída de rede negada por padrão.

O estado confirmado da investigação é o de três comprometimentos separados, com objetivos sobrepostos, mas técnicas específicas para cada produto. O vetor do RAGFlow continua sem confirmação, e a cadeia de vulnerabilidades do LiteLLM foi considerada compatível com a atividade observada, não comprovada de forma conclusiva; por isso, a busca por persistência e uso indevido de credenciais não deve depender de uma única CVE.