Ataque à cadeia de abastecimento do LiteLLM, Zeabur, Gheist

Ilustração de um balão de fala com o texto «Cybersecurity News Weekly» e um raio amarelo, a abrir o resumo semanal de cibersegurança sobre o ataque à cadeia de abastecimento do LiteLLM.

Uma chave incluída num commit de um repositório público em maio ajudou, em outubro, a adulterar uma versão de um gateway de IA amplamente utilizado, num ataque à cadeia de abastecimento. Poucos dias depois, uma plataforma de alojamento admitiu que tokens de administração intocados desde janeiro de 2024 abriram os seus sistemas de produção.

Estes incidentes partilham uma falha: credenciais que continuaram válidas muito depois de deverem ter sido revogadas, restringidas ou rodadas. Seguem-se cinco incidentes, o que cada um revela e o que verificar primeiro.

LiteLLM: Uma chave mestra não revogada levou ao roubo de um token de proprietário do GitHub e a uma versão maliciosa, segundo o LiteLLM e a Microsoft.
Zeabur: Tokens de administração em texto em claro e sem prazo de validade expuseram 321 810 contas, afirma a Zeabur.
Gheist: Tokens do GitHub roubados instalam workflows que escrevem os segredos dos repositórios nos logs, noticia a Help Net Security.
PingCAP: Credenciais roubadas deram acesso aos atacantes durante um período reportado de 28 dias, segundo a PingCAP.
Aokigahara: Um infostealer recolhe credenciais de ferramentas de programação com IA e chaves da nuvem, escreve a Check Point Research.

LiteLLM 1.107.0: Da chave mestra exposta ao ataque à cadeia de abastecimento

O que aconteceu: A 27 de maio de 2026, uma chave mestra da LiteLLM Agent Platform foi incluída num commit de um repositório público do GitHub. A análise da cadeia de ataque publicada pelo LiteLLM indica que o commit foi sobrescrito, mas o The Hacker News noticia que a chave em si nunca foi revogada. A 10 de outubro, um atacante usou-a para ler um token OAuth da GitHub CLI pertencente a um proprietário da organização. Segundo o LiteLLM, o âmbito do token não tinha sido restringido, pelo que dava acesso a todos os repositórios da organização.

Em seguida, o atacante publicou workflows de curta duração que enviavam os segredos dos repositórios para um endpoint externo. A Socket contabiliza 20 nomes de segredos distintos nos workflows recuperados de 10 e 12 de outubro, desde tokens do GitHub a credenciais da Anthropic, da OpenAI e de bases de dados, e situa a janela de comprometimento em «pelo menos onze dias» antes da publicação da versão. A cronologia do próprio LiteLLM é mais restrita: a primeira execução de 10 de outubro enviou seis segredos, incluindo GH_TOKEN, a segunda enviou RELEASE_PLEASE_TOKEN, e execuções posteriores a 12 de outubro em repositórios privados enviaram mais.

A 21 de outubro, o atacante apontou o pipeline de publicação para um repositório de nome semelhante, Berri-AI em vez de BerriAI. Segundo o The Hacker News, uma regra de aprovação mais rigorosa tinha sido recentemente flexibilizada, de modo que quaisquer dois engenheiros podiam desencadear e aprovar uma publicação. Os tokens roubados fizeram o resto: o token do proprietário desencadeou a publicação, o token de um segundo responsável pela manutenção (guardado como GH_TOKEN) aprovou a passagem para produção e o de um terceiro (RELEASE_PLEASE_TOKEN) eliminou depois os registos da execução. Sete wheels maliciosas do LiteLLM 1.107.0 chegaram ao PyPI por volta das 11:40 UTC, e a análise da Microsoft mostra que o payload era executado no arranque do Python, mesmo que o LiteLLM nunca fosse importado. Às 13:23 UTC, o PyPI já tinha colocado a versão em quarentena, pelo que as wheels estiveram disponíveis durante cerca de 1 hora e 43 minutos.

Porque é importante: O malware visa credenciais da nuvem e de Kubernetes, tokens de Git e de registos de pacotes, chaves SSH, ficheiros dotenv, credenciais do browser e a configuração de ferramentas de IA. Quem instalou a versão 1.107.0 num host com acesso à internet deve assumir que tudo aquilo a que esse host tinha acesso está exposto. A Microsoft afirma que remover o pacote ou uma tag de versão não basta para a recuperação, porque os ficheiros de arranque ficam fora do diretório do LiteLLM.

Lição para a defesa: Não comece por pip install, porque qualquer arranque do Python volta a executar o payload. Fixe a versão 1.106.2, como o LiteLLM recomenda. Procure cook.pth e sitecustomize.py em todos os ambientes, bem como cook.py, os ficheiros pycache correspondentes e o loader desanexado que mantém /tmp/remote_code_loader.lock, e reconstrua a partir de imagens limpas em vez de limpar no próprio sistema. Rode tudo aquilo a que o host tinha acesso a partir de uma máquina limpa e verifique no CloudTrail se a função da instância foi usada a partir de fora da sua infraestrutura. As conclusões da Microsoft sobre material de sessão roubado tornam sensato revogar também as sessões, e não apenas as chaves. Depois, faça a pergunta mais difícil: se um segredo for exposto num repositório, quem o revoga e como se confirma que deixou de funcionar?

Fontes: LiteLLM; Microsoft Security; Socket; The Hacker News; Publicação do LiteLLM sobre o incidente

Zeabur: Tokens de administração sem rotação desde janeiro de 2024 expõem 321 810 contas

O que aconteceu: A 14 e 15 de outubro de 2026 (UTC), um atacante usou credenciais internas que, segundo a Zeabur, estavam guardadas em texto em claro num repositório de configuração privado, com palavras-passe de root da GCP mantidas nas definições de inicialização dos servidores. Os tokens de administração do cluster partilhado não tinham prazo de validade, a interface de administração estava acessível a partir da internet pública e a Zeabur não confirmou como o atacante as obteve inicialmente, tratando uma ligação ao incidente de agosto como hipótese. O atacante leu variáveis de ambiente em clusters partilhados, iniciou sessão como root em 101 servidores dedicados na GCP, afetando 92 utilizadores, e leu a base de dados da plataforma: 3 218 965 registos de variáveis de ambiente e 321 810 contas, segundo o relatório da Zeabur.

O BleepingComputer noticia que esta foi a segunda violação de segurança da plataforma em menos de dois meses. O aviso de encerramento da Zeabur indica que as renovações de servidores dedicados estão desativadas e os clusters partilhados suspensos a partir de 1 de dezembro, que cada servidor dedicado expira entre 1 e 31 de dezembro e que tudo é desligado até 31 de dezembro. A Zeabur afirma que a rotação de agosto não abrangeu as credenciais usadas desta vez. Os números acima mostram o que estava ao alcance do atacante, não provam que cada valor tenha sido descarregado, e a Zeabur admite que os seus logs estão incompletos em alguns pontos.

Porque é importante: O incidente de agosto foi o aviso, e a rotação que se lhe seguiu ficou incompleta. A Zeabur reporta ainda mais de 16 horas de atividade do atacante a 14 de outubro sem qualquer alerta. Cada variável de ambiente da plataforma guardava segredos dos próprios clientes, pelo que uma única violação de segurança da plataforma se transformou em milhares de fugas de credenciais a jusante.

Lição para a defesa: Os passos seguintes são recomendação da Passwork e não da Zeabur: faça um inventário completo dos tokens de administração e das chaves da nuvem antes de precisar de os rodar. Defina um prazo de validade para cada token de longa duração, mantenha as interfaces de administração fora da internet pública e mantenha as credenciais fora dos repositórios e das definições de inicialização dos servidores. Se aloja serviços numa plataforma deste tipo, trate cada variável que lá guardou como exposta e substitua-a.

Fontes: Zeabur; BleepingComputer; Aviso de encerramento da Zeabur

Gheist: Tokens do GitHub roubados põem workflows de CI a recolher segredos

O que aconteceu: A Wiz Research recuperou mais de 13 500 branches plantados a partir de mais de 850 contas do GitHub comprometidas e deu à campanha o nome Gheist, a partir do user agent que utiliza. A Wiz começou a acompanhá-la a 15 de setembro e publicou a 25 de outubro, como noticia a Help Net Security. A ferramenta pega num token roubado, encontra todos os repositórios a que consegue aceder e publica um branch chamado «ci-sync-» seguido de seis caracteres, com um workflow chamado «sync-check». O workflow escreve os segredos do repositório no log da execução, codificados em Base32, uma forma que o mascaramento de logs do GitHub não deteta. A ferramenta descarrega o log através da API e elimina a execução segundos depois, pelo que a Wiz não encontrou nenhum domínio do atacante nem ligação de saída para bloquear. O GitHub só mascara os segredos quando aparecem literalmente, e é por isso que os valores codificados são apresentados na íntegra.

Desde 28 de julho, o GitHub retém para aprovação certas execuções de workflows potencialmente maliciosas, mas apenas em repositórios públicos no github.com. A Wiz afirma que essa retenção não abrange repositórios privados nem o GitHub Enterprise Server, e que observou exploração nesses casos. Em organizações empresariais, a Wiz viu a ferramenta percorrer os tokens de vários utilizadores e contas de automação em poucos minutos e, horas depois, credenciais da nuvem da mesma organização foram usadas para enumerar o AWS Secrets Manager. A Wiz não identifica as organizações nem indica quantas foram afetadas.

Porque é importante: Um único token pessoal roubado pode expor todos os segredos de todos os repositórios a que o seu titular tem acesso, incluindo credenciais de produção com âmbito de ambiente. Eliminar a execução não anula a exposição.

Lição para a defesa: Analise o registo de auditoria do GitHub à procura do user agent «gheist» e os logs da nuvem à procura de assunções de funções via OIDC associadas a branches «ci-sync-». A Wiz recomenda rodar todos os segredos de repositório, de organização e de ambiente a que um token comprometido pudesse aceder, e revogar os próprios tokens. O sinal do branch só funciona se o subject do OIDC incluir o branch. Limite os tokens que podem publicar workflows e configure alertas para novos ficheiros de workflow em branches novos.

Fontes: Help Net Security; Wiz; Registo de alterações do GitHub

PingCAP: Credenciais roubadas, 28 dias de acesso reportado

O que aconteceu: A PingCAP reporta que, de 9 de setembro a 7 de outubro de 2026, uma parte não autorizada usou credenciais de contas de serviço roubadas para aceder a sistemas internos, copiar dados e obter código-fonte. A empresa tomou conhecimento a 7 de outubro e começou nesse dia a desativar as credenciais. Os dados expostos incluem dados de contas e de utilização de produtos do TiDB Cloud, detalhes de contratos e faturação e valores de chaves de API encriptados. A PingCAP afirma que não há indícios de que os dados armazenados nas bases de dados TiDB dos clientes tenham sido acedidos ou afetados, mas foram copiados registos relacionados com clientes dos seus sistemas internos de análise, armazenamento e suporte, e a empresa ainda está a apurar se foram expostas outras credenciais utilizáveis. O relatório de 19 de outubro não diz como as credenciais foram roubadas. A nota do CEO da PingCAP de 23 de outubro e a análise posterior da NebuSec descrevem a entrada inicial como uma conta do GitHub comprometida e credenciais expostas, e indicam que a chave de encriptação dos valores de chaves de API exportados não foi exposta, pelo que não foi possível decifrá-los em chaves utilizáveis. Isso não abrange as credenciais que os clientes partilharam em materiais de suporte.

Porque é importante: As contas de serviço raramente têm um responsável, um prazo de validade ou alguém que repare em comportamentos anómalos. O período de acesso reportado foi de 28 dias, embora não necessariamente numa única sessão ininterrupta.

Lição para a defesa: Atribua a cada conta de serviço um responsável identificado, as permissões mínimas que funcionem e uma data de rotação. Configure alertas para exportações grandes e invulgares. A PingCAP descreve como trabalho em curso uma rotação de credenciais mais alargada, revisões de acessos e uma análise de segredos mais abrangente, o que constitui um modelo razoável para a sua própria lista.

Fontes: PingCAP; Nota do CEO da PingCAP; NebuSec

Aokigahara: Um infostealer que visa credenciais de ferramentas de programação com IA

O que aconteceu: A Check Point Research documenta (23 de outubro) um infostealer para Windows a que chama Aokigahara, com um módulo dedicado às sessões de ferramentas de IA. Procura ficheiros usados pelo Claude, Codex, Cursor, Windsurf, GitHub Copilot, Gemini CLI, Amazon Q, Kiro e JetBrains AI Assistant, bem como credenciais da AWS e caches de SSO. O seu módulo para IDE recolhe também ficheiros de credenciais do Git, ficheiros SSH que podem conter chaves privadas e credenciais do Azure e do Google Cloud. Mantêm-se funções mais antigas: palavras-passe e cookies do browser, carteiras de criptomoedas e dados de aplicações de gestão de palavras-passe. O relatório da Symantec de 15 de outubro, noticiado pela Infosecurity Magazine, identifica o malware como Aoki (também conhecido como Aokigahara), detetado pela primeira vez no início de 2026, e indica que as chaves de IA roubadas podem ser revendidas ou usadas para acumular custos na conta da vítima, uma prática por vezes designada LLMjacking.

Porque é importante: Um portátil de um programador contém as mesmas credenciais que os atacantes usaram contra o LiteLLM: tokens, chaves da nuvem e chaves SSH. A Check Point afirma que não conseguiu confirmar como os operadores rentabilizam os dados e aponta como possibilidades a revenda, o abuso de serviços pagos e a extorsão. As listas acima indicam o que o stealer recolhe, não provam que os dados de todas as vítimas tenham sido exfiltrados.

Lição para a defesa: Trate as credenciais e os ficheiros de sessão das ferramentas de IA como tão sensíveis quanto as sessões do browser, as credenciais da nuvem e as chaves dos programadores, como recomenda a Check Point. Sempre que possível, mantenha as chaves de longa duração fora das máquinas dos programadores, use tokens de curta duração e rode as credenciais rapidamente quando um posto de trabalho for sinalizado.

Fontes: Check Point Research; Symantec; Infosecurity Magazine

O que isto significa para a sua equipa

Todas as histórias acima terminam da mesma forma: uma credencial que alguém julgava morta continuava a funcionar. Seis verificações a fazer já:

Revogar em caso de exposição. Sobrescrever um commit não invalida uma chave. Trate qualquer segredo que tenha passado por um repositório, log ou chat como comprometido e confirme que o valor antigo deixou de funcionar.
Restringir o âmbito e definir a validade de cada token. Substitua os tokens de proprietário da organização por tokens restritos e de curta duração. Defina um prazo de validade para os tokens de administração e de serviço, para que um token de janeiro de 2024 não consiga abrir nada em outubro de 2026.
Manter barreiras de aprovação que dois tokens roubados não consigam ultrapassar. A aprovação de versões deve depender de identidades e dispositivos que um token de CI não consiga falsificar, e qualquer flexibilização de uma regra deve desencadear uma revisão.
Proteger os segredos de CI. Prefira o acesso de curta duração à nuvem a chaves armazenadas, restrinja quem pode publicar workflows e configure alertas para novos ficheiros de workflow em branches novos, incluindo em repositórios privados.
Tratar as máquinas dos programadores e as configurações das ferramentas de IA como locais de armazenamento de segredos. Faça o inventário do que está guardado em ficheiros dotenv, diretórios SSH e sessões de assistentes de IA, e rode as credenciais a partir de uma máquina limpa após um comprometimento.
Rodar por completo, não parcialmente. Mantenha um inventário de todos os tokens de administração e chaves da nuvem, para que a rotação após um incidente os abranja a todos.

Se as chaves de API, os tokens e as credenciais de serviço continuam em ficheiros de configuração e conversas de chat, reuni-los num único local é o primeiro passo para os revogar de forma programada. O Passwork guarda-os em cofres encriptados, com acesso baseado em funções e um registo de atividade, para que se veja quem acede a cada segredo e se possa rodá-lo uma única vez. Experimentar o Passwork grátis.