Wiz: quase 1 em cada 10 gateways LiteLLM expostos aceita a chave de administrador de exemplo sk-1234

Em 9 de setembro de 2026, a Wiz Research publicou um estudo sobre o LiteLLM, o gateway de IA de código aberto que se interpõe entre as aplicações e os fornecedores de modelos a quem estas pagam, e relatou que 294 das 3.074 implementações do LiteLLM que conseguia alcançar na internet pública — 9,6%, quase uma em cada dez — aceitavam sk-1234, a chave mestra de exemplo impressa na própria documentação de configuração do projeto, ou não exigiam qualquer credencial. Essa cadeia de caracteres não é uma chave de API comum: no LiteLLM, é simultaneamente a credencial de administrador e o interruptor que ativa a autenticação, pelo que quem a apresentar pode ler todas as chaves de fornecedores de modelos armazenadas no gateway, observar todos os prompts e respostas que por ele passam e chegar a todos os servidores de ferramentas ligados através do Model Context Protocol. Os coautores da Wiz, Amitai Cohen e Yaara Shriki, encadearam esse acesso à execução de código ao nível de root e ao roubo das credenciais IAM da cloud do anfitrião. Este relato baseia-se no relatório da Wiz, nos próprios avisos de segurança do LiteLLM e na listagem Known Exploited Vulnerabilities da CISA que se seguiu, e o arquivo de incidentes de IA mantém este registo a par dos seus vizinhos, cada um com as suas próprias fontes, gravidade e grau de confiança.

A data de publicação é a única data que o registro traz, e é uma data de publicação. A varredura por trás da manchete foi executada em fevereiro de 2026; as duas falhas de código que a Wiz descreve já tinham correções enviadas até meados de maio, no mais tardar, em versões que os próprios registros do projeto datam de março e maio; os identificadores CVE foram emitidos em julho; e a listagem no catálogo surgiu em setembro. Quase tudo no relatório já estava desatualizado quando ele foi impresso, o que é grande parte do que o relatório argumenta.

Os 9,6% correspondem a uma única varredura, e a Wiz afirma que seu próprio acompanhamento de agosto não pode ser comparado a ela.

A medição é simples, e a Wiz declara seu método sem rodeios: 3.074 proxies LiteLLM expostos à internet encontrados via Shodan em fevereiro de 2026, cada um testado para verificar se autenticaria com a chave de exemplo documentada. Desses, 294 autenticaram. Dentro desse grupo, 191 não tinham nenhuma chave mestra configurada e teriam aceitado qualquer string oferecida; os demais tinham deixado o placeholder do guia de configuração no lugar. Nenhum dos dois modos de falha exige um bug de software. Ambos precisam apenas do endereço do gateway e do valor impresso no README do próprio projeto.

Trata-se também de um scan de um único fornecedor. O número da Wiz foi repetido pela AI Safety Initiative da Cloud Security Alliance em 10 de setembro e pelo The Hacker News no mesmo dia, mas ambos o repetem com atribuição, e nenhuma replicação independente do número de 3.074 foi localizada para este artigo. A Wiz realizou um segundo scan em agosto de 2026 e encontrou mais de 85.000 instâncias, cerca de vinte e sete vezes a contagem de fevereiro. A empresa afirma que a maioria delas parece ser honeypots ou implantações de teste, e que as duas contagens não podem ser comparadas. Não há um número atual de exposição, e qualquer artigo que cite um está citando fevereiro.

Mais um número no relatório é a telemetria própria da Wiz, em vez de uma varredura: a empresa diz que o LiteLLM está presente em cerca de um terço dos ambientes de nuvem que observa. Essa é a visão de um fornecedor sobre sua própria base de clientes e deve ser encarada com cautela, mas explica por que os pesquisadores trataram uma configuração incorreta de gateway como um problema de nuvem, e não de aplicação.

A chave mestra é tanto a credencial de administrador quanto o interruptor que ativa a autenticação.

O design do LiteLLM atribui duas funções a um único segredo. A chave mestra autentica solicitações administrativas, e sua presença é o que permite a autenticação de modo geral: sem chave mestra e sem configuração de JWT ou OAuth2, o proxy é executado aberto e aceita todas as solicitações. A Wiz analisou a base de código com o Claude Code, da Anthropic, em busca de recursos que recebem entrada controlada pelo usuário e a passam para um contexto de execução, e o manipulador de autenticação foi uma das três superfícies sinalizadas por ela.

Antes da v1.82.0-stable, a consequência desse segundo job era pior do que a de um proxy aberto. A Wiz descobriu que, quando nenhuma chave mestra era definida, o handler de autenticação atribuía a função PROXY_ADMIN a todas as requisições recebidas, de modo que um chamador não autenticado não era apenas admitido, mas admitido como administrador. O pull request #22095, citado no relatório, alterou a função padrão para INTERNAL_USER e adicionou uma verificação de administrador aos endpoints de guardrail.

O acesso administrativo a um gateway não é um privilégio restrito. A instância detém uma chave de API para cada provedor para o qual encaminha tráfego, e é isso que a torna um alvo para o LLMjacking — executar cargas de trabalho de modelos na conta da vítima. Ela vê os prompts e as conclusões. Ela se conecta externamente a servidores de ferramentas MCP, que, em uma implantação interna, provavelmente incluirão rastreadores de issues, chat, bancos de dados e pipelines de implantação.

A Wiz também demonstrou um caminho dessa posição administrativa até a identidade na nuvem do host. O LiteLLM permite que um administrador registre uma rota de passagem para qualquer URL de destino, e o destino não é verificado em relação a faixas de endereços privados, localhost ou ao endereço de metadados da nuvem. Apontar uma rota para o serviço de metadados da instância retorna as credenciais IAM sob as quais a carga de trabalho é executada. Mudar o serviço de metadados para o IMDSv2, que normalmente impede essa classe de falsificação de requisição ao exigir um token de sessão obtido separadamente, não ajuda: o LiteLLM encaminha qualquer cabeçalho prefixado com x-pass- para o destino com o prefixo removido, de modo que o cabeçalho do token pode ser contrabandeado. A Wiz diz que o recurso, possivelmente, funciona como pretendido sob um modelo de ameaça que confia nos administradores e que, portanto, não tem CVE nem correção.

Esse último parágrafo é uma demonstração, não um ataque observado. O The Hacker News, ao reportar a pesquisa em 10 de setembro, afirma que nenhuma fonte relata que alguém tenha feito isso contra uma implantação real, e que isso exige primeiro acesso de administrador. O enquadramento da Wiz é o mesmo: o pass-through é uma propriedade de design que só se torna uma vulnerabilidade quando a credencial de administrador é uma string da documentação.

8.8 e 2.1 estão avaliando a mesma cadeia a partir de posições iniciais diferentes

Dois CVEs trazem as descobertas técnicas, e as pontuações publicadas de ambos dificilmente poderiam ser mais discrepantes.

A CVE-2026-59822 é o bypass de autenticação do MCP, e o aviso da LiteLLM a classifica como Alta, 8,8 no CVSS 4.0, sem privilégios exigidos, sem interação do usuário e sem requisitos de ataque. O endpoint MCP tem seu próprio manipulador de autenticação, criado para aceitar uma chave LiteLLM ou um token OAuth2 destinado a um servidor de ferramentas upstream. Quando um token falhava na validação da LiteLLM, o manipulador capturava o 401 e substituía por um objeto de autenticação vazio em vez de rejeitar a solicitação. Qualquer token Bearer, portanto, produzia uma sessão MCP válida, incluindo um único caractere: a prova de conceito da Wiz envia um token bearer de uma letra e recebe um identificador de sessão de volta. A falha foi corrigida na 1.84.0.

A CVE-2026-59821 é a falha de guardrail, e o aviso do mesmo projeto classifica-a como Baixa, 2.1, exigindo privilégios elevados e com requisitos de ataque presentes. O recurso de guardrail de código personalizado permite que um administrador envie código Python que o servidor compila e executa. O endpoint de teste da Web UI validava o código em relação a uma lista de padrões proibidos e removia os builtins antes de executá-lo; os endpoints de criação e atualização em produção não faziam nenhuma das duas coisas. O Python repopula os builtins quando eles estão ausentes, de modo que o código enviado alcançou a biblioteca padrão. A prova de conceito da Wiz registra um guardrail que executa um comando de shell no momento do registro — antes de qualquer requisição ao modelo — e retorna a saída do comando como motivo do bloqueio, a qual, em seu teste, voltou como root. A falha foi corrigida na v1.82.0-stable.

As duas descrições são compatíveis, e a frase conciliadora está no próprio aviso: a LiteLLM observa que, em implantações sem uma chave mestra configurada, os chamadores podiam ser tratados como administradores do proxy, e foi isso que colocou os endpoints de guardrail ao alcance. A 2.1 presume um usuário privilegiado. A cadeia da Wiz é o que acontece quando a chave padrão torna todo chamador privilegiado. Nenhuma das pontuações está errada quanto à sua própria posição inicial; elas discordam sobre com que frequência essa posição fica livre.

Uma ressalva acompanha a afirmação da Wiz de que, após a 1.82.0, um atacante que detivesse a chave padrão só poderia executar código dentro de um sandbox. O Hacker News aponta para um aviso separado de maio de 2026, CVE-2026-40217, que descreve como escapar desse sandbox por meio de técnicas de bytecode em versões da 1.81.8 até, mas não incluindo, a 1.83.10, dentro de um processo de proxy que, segundo o aviso, é executado como root na imagem de contêiner padrão. Alcançar esse endpoint requer uma credencial de administrador de proxy, que é precisamente o que a chave mestra é.

A pontuação 8,8 também não é universal. A nota de pesquisa da Cloud Security Alliance observa que o aviso do GitLab lista uma pontuação base de 8,2 para a mesma falha e se recusa a julgar entre as duas metodologias, observando apenas que ambas estão na faixa alta. A severidade alta do registro não depende de qual número é usado.

Uma CVE foi explorada em ambiente real; a exposição da chave padrão não tem vítima identificada.

A CISA adicionou a CVE-2026-59822 ao catálogo Known Exploited Vulnerabilities em 2 de setembro de 2026 e definiu um prazo de remediação de 16 de setembro de 2026 para agências civis federais; a entrada do catálogo traz CWE-287 e CWE-306, autenticação imprópria e autenticação ausente. A nota da Cloud Security Alliance relata que rastreadores do setor a descreveram como a primeira falha específica de MCP nessa lista. A Wiz publicou a exploração que observou: desde 7 de julho de 2026, seus honeypots registraram solicitações com tokens bearer de um único caractere sondando endpoints de listagem de modelos, e a Wiz não descreve nenhum outro uso da falha.

Nada comparável existe para a chave padrão. Nenhuma vítima é nomeada, nenhum gateway é identificado como tendo sido tomado por meio de sk-1234, e nenhuma telemetria mostra os 294 hosts sendo usados. O registro no arquivo não registra nenhum dano real, o que é uma afirmação sobre evidências, e não sobre o mecanismo: a exposição foi medida, não testemunhada em uso.

Dois outros itens costumam ser registrados ao lado destes e não são a mesma coisa. CVE-2026-42271, execução de comandos por meio de dois endpoints de teste MCP, é a falha do LiteLLM que os atacantes realmente usaram para executar código; os honeypots da Wiz registraram a instalação de um minerador de criptomoedas. O caso de agosto de 2026 publicado pela Microsoft, no qual um invasor leu as variáveis de ambiente de um contêiner de gateway, recuperou a chave mestra, as chaves dos provedores e uma string de conexão de banco de dados, e então copiou registros das tabelas de modelos e de chaves virtuais do LiteLLM, ilustra o quanto vale um gateway comprometido, e não uma nova forma de entrada; o The Hacker News relata que a Microsoft avalia o ponto de entrada como a cadeia CVE-2026-42271.

A posição dos mantenedores é que a ausência de uma chave mestra é um erro de configuração, não uma vulnerabilidade

A política de segurança da LiteLLM é explícita. Ela inclui entre as questões fora de escopo "ataques que exigem uma configuração incorreta na instalação (por exemplo, não definir uma master_key na configuração do proxy)" e afirma que estas estão explicitamente fora de escopo e não são consideradas vulneráveis. A Wiz chega a uma conclusão compatível pela direção oposta quando afirma que o comportamento de pass-through, possivelmente, funciona como pretendido.

Essa posição foi testada em público. Em 15 de agosto de 2026, um pesquisador abriu a issue #37054 no GitHub, relatando que um proxy com a LITELLM_MASTER_KEY não definida autentica qualquer valor de chave e que o arquivo docker-compose distribuído não define uma. A issue foi fechada 30 minutos depois, e o único comentário nela é da mesma conta: ele cita a instrução da política de segurança de que os relatos devem ser encaminhados por meio de relatórios privados de vulnerabilidade em vez de issues públicas, pede desculpas por ter relatado publicamente e diz que o relatório completo estava sendo enviado pelo caminho de advisory. Nenhuma resposta de mantenedor aparece na thread, então o registro mostra o repórter retirando o relato público, e não uma resposta do projeto a ele. Nada público registra o que aconteceu com o envio privado.

Não foi localizada, para este artigo, nenhuma declaração pública da BerriAI defendendo ou revisando essa posição sobre o relatório de setembro. A resposta visível da empresa está nas suas notas de lançamento e nos seus arquivos de configuração, e não em prosa.

A execução chegou em 3 de outubro, vinte e quatro dias após o relatório.

As duas falhas de código foram corrigidas muito antes do relatório. A linha do tempo de divulgação da Wiz registra a execução de código do guardrail reportada em 18 de fevereiro de 2026 e corrigida em 25 de fevereiro na v1.82.0, o bypass de MCP corrigido em 25 de abril na v1.84.0, a exploração observada em 7 de julho, os identificadores CVE publicados em 8 de julho e a listagem no catálogo em 2 de setembro. Os artefatos de lançamento têm datas posteriores às das correções: o índice de pacotes mostra a v1.82.0 em 1 de março de 2026 e a v1.84.0 em 14 de maio, o que marca quando cada correção se tornou instalável, e não quando foi implementada. Dois registros de lançamento primários datam as mesmas correções depois dessa linha do tempo. O lançamento v1.82.0-stable no GitHub traz 11 de março de 2026, e o pacote 1.82.0 no PyPI, 1 de março; a v1.84.0 está datada de 14 de maio de 2026 em ambos. Nada publicado explica a diferença, e isso não importa para o argumento, já que todas essas datas ficam meses antes do relatório de setembro. Os dois avisos do GitHub acrescentam ainda uma terceira data: foram publicados em 30 de junho de 2026, três semanas antes dos identificadores CVE que a Wiz diz terem sido divulgados em 8 de julho.

O que nenhuma dessas versões corrigiu foi o padrão. A Wiz relatou que, em 9 de setembro, a chave mestra ainda estava definida como sk-1234 ao instalar o LiteLLM via Docker Compose ou pip install, e o The Hacker News confirmou que o guia de configuração ainda usava o valor naquele dia. A mudança veio com a v1.104.0, enviada ao Python Package Index em 3 de outubro de 2026, cujas notas de versão a listam como uma alteração incompatível: o proxy agora se recusa a iniciar com uma chave mestra não definida, vazia ou publicamente conhecida, nomeando a origem do valor inválido no erro de inicialização e exibindo um comando que gera uma chave segura. Um registro complementar documenta uma mudança para deixar de divulgar um valor de chave mestra fraco e publicamente conhecido nas configurações e nos exemplos distribuídos, e o arquivo docker-compose no branch principal do projeto não define mais nenhuma chave.

Essa é a sequência que vale a pena manter. O código recebeu patches na primavera. O valor que tornava esses patches insuficientes permaneceu nas instruções de instalação até outubro, e só então o software passou a recusá-lo. Nada em nenhuma das duas correções exigia que a outra esperasse.

O que não mudou é a rota de passagem direta para o serviço de metadados de instância. Ela ainda não tem CVE nem correção, porque o projeto trata os administradores como confiáveis. A lista de remediação da Wiz, portanto, é majoritariamente trabalho do operador: uma chave mestra forte e exclusiva, uma revisão das guardrails registradas seguida de uma reinicialização do processo para limpar o código mantido em memória, uma auditoria dos endpoints de passagem direta com saída de contêineres restrita, e funções do IAM com privilégio mínimo. Nenhum desses quatro itens chega apenas com a atualização.

O que o registro não estabelece

• Não foi localizada nenhuma replicação independente da varredura de 3.074 hosts. Os 9,6% correspondem à medição da Wiz, e todos os outros relatos desse dado repetem o número de forma atributiva.

• Não existe um número atual de exposição. O acompanhamento de agosto encontrou mais de 85.000 instâncias, que a Wiz afirma serem principalmente honeypots ou implantações de teste e não podem ser comparadas com a contagem de fevereiro.

• Nenhuma vítima. Nada no registro identifica um gateway, um operador ou uma conta de nuvem comprometidos por meio da chave padrão, e a exploração documentada pela Wiz é do bypass do MCP, e não do sk-1234.

• Não há evidências de que os 294 hosts tenham sido usados. A varredura testou se eles autenticariam, o que é uma afirmação mais fraca do que demonstrar que alguém o fez.

• Nenhuma gravidade estabelecida para a falha do guardrail. A Wiz e os mantenedores descrevem o mesmo comportamento e classificam-no de forma muito diferente, e a diferença está nos privilégios que cada um assume que o atacante já detém.

A Wiz também é uma fornecedora de segurança em nuvem que vende detecção para essa classe de exposição, e o relatório termina com uma seção sobre como seus próprios produtos identificam implantações do LiteLLM, versões vulneráveis e instâncias shadow. Isso é contexto para ler a seção de remediação, não um motivo para desconsiderar uma medição cujos detalhes técnicos os próprios avisos dos mantenedores corroboram.

A parte do registro que vai além do LiteLLM é o intervalo entre duas datas. A vulnerabilidade foi corrigida na primavera. O padrão que tornava a vulnerabilidade relevante para um desconhecido ainda estava sendo impresso nas instruções de instalação em setembro, e o software só começou a recusá-lo em outubro. Os operadores que alteraram a string nunca precisaram esperar por nada disso.