A porta de entrada da IA da sua empresa aceitava a senha do manual — e 1 em cada 10 estava aberta

Quando uma empresa começa a usar inteligência artificial para valer, costuma instalar um intermediário: um programa que fica no meio do caminho, recebe os pedidos dos sistemas internos e os encaminha para os vários provedores de IA, controlando custo, permissão e limite de uso. Um dos mais populares desses intermediários é o LiteLLM, de código aberto.

O problema é que esse intermediário guarda, por definição, todas as chaves de acesso da empresa — às IAs e, muitas vezes, à própria nuvem. E pesquisadores da Wiz acabaram de mostrar que ele podia ser aberto com relativa facilidade.

As três falhas

• CVE-2026-59821 — comandos com poder máximo. O recurso que permite ao cliente cadastrar regras próprias de filtragem não checava o que estava sendo enviado. Na prática, dava para registrar código e executá-lo como administrador do servidor. Corrigida na versão 1.82.0.
• CVE-2026-59822 — a autenticação que não autenticava. Quando a validação do token falhava, em vez de recusar o pedido, o sistema devolvia uma sessão sem nenhuma restrição. Resultado: qualquer token servia, inclusive um de um único caractere. Nota 8.8. Corrigida na 1.84.0.
• CVE-2026-35029 — usuário comum virando administrador. A rota de configuração não verificava se quem pedia tinha permissão de administrador, permitindo alterar configurações e variáveis do ambiente. Corrigida na 1.83.0.

O número que constrange

De 3.074 instalações expostas à internet que os pesquisadores encontraram, 294 (9,6%) aceitavam a chave de exemplo da documentação — literalmente sk-1234 — ou não exigiam autenticação nenhuma. Nesses casos, a falha de execução de código deixa de exigir qualquer acesso prévio: basta encontrar o endereço.

A CISA, agência de cibersegurança dos Estados Unidos, incluiu a falha de autenticação no seu catálogo de vulnerabilidades comprovadamente exploradas em 2 de setembro. Os pesquisadores registraram tentativas contra seus próprios servidores-isca desde julho.

Por que isso é mais grave do que parece

Um intermediário de IA comprometido não entrega só o acesso ao chatbot. Ele entrega:

• as chaves dos provedores de IA, que podem ser revendidas ou usadas por conta da empresa (a conta chega no fim do mês);
• as credenciais da nuvem guardadas na configuração, que abrem bancos de dados, repositórios e sistemas conectados;
• e um ponto fixo dentro da rede, porque esse serviço costuma ficar num lugar privilegiado, conversando com tudo.

O que fazer hoje

1. Descubra se a empresa usa um intermediário de IA — LiteLLM ou similar. Muitas vezes ele foi instalado por uma equipe de desenvolvimento sem passar pela TI.
2. Atualize para a versão 1.84.0 ou superior, que é a que resolve as três falhas.
3. Troque a chave-mestra. Se ainda estiver a do exemplo, ou qualquer uma que tenha sido colocada “só para testar”, ela precisa sair hoje.
4. Tire da internet o que não precisa estar exposto. Esse tipo de serviço quase nunca precisa ser acessível de fora; o lugar dele é atrás da rede interna ou da VPN.
5. Revise as chaves que ele guarda: prazo de validade curto, permissão mínima, rotação periódica.

A lição maior não é sobre o LiteLLM. É sobre o padrão que se repete: a adoção de IA nas empresas anda mais rápido do que a segurança em volta dela. Ferramentas novas entram pela porta do time técnico, com credenciais poderosas e configuração de exemplo — e ficam anos assim. Vale perguntar hoje quais serviços de IA já estão rodando na sua empresa, quem os instalou e o que eles têm nas mãos.

Fontes

• Wiz — Off Guard: Breaking LiteLLM, from authentication bypass to cloud compromise: wiz.io
• CISA — catálogo de vulnerabilidades conhecidas exploradas (KEV): cisa.gov/known-exploited-vulnerabilities-catalog
• Foto de capa: corredor de racks em data center — PiDatacenters, CC BY-SA 4.0, via Wikimedia Commons
• Segunda imagem: selo da CISA (Cybersecurity and Infrastructure Security Agency) — governo dos EUA, domínio público, via Wikimedia Commons