Durante os primeiros meses de 2026, o ecossistema open source foi palco de uma série de ataques à cadeia de suprimentos que deixaram de ser episódios isolados para se tornar uma tendência clara. Em poucas semanas, foram registrados ataques de alto impacto que afetaram projetos amplamente utilizados, como Axios, Trivy e LiteLLM, além de outros casos relacionados ao Checkmarx KICS e a SDKs como o Telnyx.
Diversos relatórios apontam que, entre meados e o fim de março, houve um pico de atividade maliciosa, com vários ataques concentrados em poucos dias. Isso permitiu identificar padrões em comum e confirmar que esse tipo de incidente já não se trata de casos pontuais, mas de campanhas ativas contra o ecossistema open source.
Zero Trust… cadê?
Mais do que as diferenças entre os projetos afetados, todos desempenham funções críticas em processos ou pipelines de desenvolvimento, automação, segurança ou inteligência artificial. Além disso, todos compartilham uma característica-chave: são executados em ambientes onde a confiança é a regra e os privilégios costumam ser elevados. Justamente por isso se tornam tão interessantes para os cibercriminosos.
Duas campanhas distintas, um mesmo objetivo
A análise dos incidentes mais relevantes de 2026 permite identificar pelo menos duas campanhas principais, com grupos criminosos e motivações diferentes, mas com uma lógica operacional em comum: comprometer softwares confiáveis para atingir o maior número possível de vítimas por meio da cadeia de suprimentos.
O caso do Axios foi atribuído ao UNC1069, também conhecido como Sapphire Sleet, um grupo APT vinculado aos interesses da Coreia do Norte e cuja principal motivação é o ganho financeiro. Nesse ataque, houve o sequestro da conta do principal mantenedor do Axios por meio de técnicas de engenharia social, o que permitiu a publicação de versões maliciosas do pacote no npm, incluindo um trojan de acesso remoto multiplataforma.
O código malicioso era executado durante uma instalação aparentemente normal, sem alterar de forma visível o comportamento principal da biblioteca, o que facilitou que passasse despercebido em um primeiro momento.
Em paralelo, outros incidentes que afetaram o LiteLLM, o Checkmarx KICS e o Telnyx foram associados a uma campanha diferente, atribuída ao grupo TeamPCP. Nesses casos, o foco não esteve em um único pacote de alto impacto, mas sim em uma propagação em cascata.
O TeamPCP inicialmente explorou uma vulnerabilidade de configuração em um workflow do repositório de código do Trivy (um scanner de segurança open source amplamente adotado, desenvolvido pela empresa Aqua). A exploração dessa vulnerabilidade, somada a uma rotação incompleta de credenciais e segredos por parte do desenvolvedor, resultou no roubo de credenciais e tokens de ambientes de desenvolvimento e pipelines de CI/CD das empresas que utilizaram a versão comprometida do Trivy.
Isso desencadeou um efeito “trampolim”, com propagação para outros projetos, gerando um padrão de expansão automática semelhante ao de um worm.
Embora ambos os grupos criminosos tenham objetivos semelhantes, suas motivações não são idênticas. O UNC1069 mantém um perfil alinhado a interesses estatais e a objetivos financeiros sustentados, enquanto o TeamPCP segue uma lógica mais criminosa e oportunista, voltada para a monetização rápida e a reutilização de acessos.
Quais tecnologias foram afetadas e quem as utiliza
Um dos aspectos mais relevantes desses ataques é a diversidade de tecnologias comprometidas. Não se trata de softwares marginais ou de projetos pouco conhecidos, mas de ferramentas amplamente utilizadas.
O Axios é uma biblioteca HTTP onipresente em aplicações web, serviços em nuvem e APIs corporativas, com dezenas de milhões de downloads semanais. O Trivy é um scanner de vulnerabilidades amplamente integrado a pipelines de DevSecOps e ambientes de CI/CD, o que o torna um alvo valioso para o roubo de credenciais e segredos de infraestrutura. Já o LiteLLM funciona como uma camada de integração essencial para equipes que desenvolvem soluções baseadas em modelos de linguagem, pois permite direcionar requisições para múltiplos provedores de IA.
Nos ataques atribuídos ao TeamPCP, esses comprometimentos foram utilizados como vetor para expandir o ataque para outros projetos. Já o Checkmarx KICS é uma ferramenta usada para analisar configurações de infraestrutura como código, o que reforça a ideia de que os ataques miram tudo aquilo que faz parte “confiável” do processo de construção, teste e implantação de software.
As consequências silenciosas de instalar uma dependência comprometida
A instalação de uma dependência comprometida nem sempre se traduz em uma falha visível ou imediata. Em muitos dos ataques detectados em 2026, uma característica comum foi o baixo nível de ruído: o software continuava funcionando como esperado, enquanto o código malicioso operava em segundo plano.
As consequências podem incluir a instalação de trojans de acesso remoto, como no caso do Axios, ou o roubo em larga escala de segredos críticos, como tokens do GitHub, npm ou PyPI, credenciais de provedores de nuvem, chaves SSH ou configurações completas de CI/CD, como observado na campanha atribuída ao TeamPCP.
No contexto de cadeia de suprimentos, o tempo joga a favor dos cibercriminosos: cada hora adicional aumenta as chances de propagação, reutilização de acessos e ampliação do impacto.
Olhando além da detecção
Quando um alerta chega às mãos das equipes de cibersegurança, o pacote já foi executado e o prejuízo inicial, em muitos casos, já aconteceu. Em ataques à cadeia de suprimentos, uma detecção tardia não significa apenas reagir depois do fato, mas fazê-lo quando os cibercriminosos já ganharam vantagem.
Essa realidade expõe os limites de abordagens baseadas exclusivamente na prevenção. Por isso, fica cada vez mais evidente que a estratégia não pode se limitar a “instalar software apenas de fontes confiáveis”, mas deve incluir a capacidade de identificar rapidamente ações suspeitas executadas por softwares legítimos.
Detectando anomalias
Um dos aprendizados mais claros desses comprometimentos recentes é a necessidade de mudar o foco. Em vez de se concentrar apenas em qual dependência foi instalada e sua origem, é indispensável verificar e observar como esse componente se comporta em tempo real.
Em alguns dos ciberataques mencionados, os primeiros indícios surgiram a partir de comportamentos anômalos, como a execução de scripts suspeitos durante a instalação, conexões de saída para infraestruturas suspeitas ou acessos a arquivos sensíveis que não fazem parte do fluxo normal. Esse enfoque não exige conhecer previamente a assinatura exata do ataque, mas sim entender o que é esperado em um ambiente e detectar rapidamente aquilo que foge desse padrão.
Um cenário real: detecção e resposta gerenciada com serviços de MDR
A seguir, um exemplo de como os serviços de Managed Detection & Response (MDR) podem trazer visibilidade e resposta precoce diante desse tipo de ataque.
Nesse caso, uma organização foi afetada pelo ataque à cadeia de suprimentos do Axios quando um dos desenvolvedores da empresa tentou instalar a biblioteca comprometida durante o período em que o pacote estava disponível no repositório oficial do npm.
Ao contar com soluções de segurança da ESET, foi possível identificar o comportamento malicioso ainda nas etapas iniciais e bloquear a tentativa de acesso não autorizado aos sistemas da organização antes que o ataque se concretizasse.
Além disso, houve visibilidade imediata de toda a cadeia do ataque, o que permitiu confirmar o real alcance do incidente, contê-lo rapidamente e evitar impactos operacionais.
Evidências da tentativa de ataque detectada
Indicadores da proteção antivírus:
- Malware: JS/Agent.UHP
Indicadores de regras de EDR:
- Suspicious script interpreter started - cscript [F0447b]
- Script started from %TEMP% [F0443a]
- Suspicious script interpreter started - cmd [F0447d]
- Script interpreter saved default script file [A0317]
- Curl uploaded file [A0521]
- Renamed PowerShell Execution [D0411]
- PowerShell Suspicious Activity Executed [D0413]
- PowerShell Engine Loaded in Non-PowerShell Process [D1206]
Além disso, os analistas de segurança da equipe de MDR da ESET criaram um incidente para notificar a empresa afetada de que haviam sido detectados eventos de segurança suspeitos:
Como medida preventiva, e com o objetivo de evitar um comprometimento maior, a equipe de MDR isolou o equipamento da rede até identificar a causa raiz do incidente:
Ações específicas para se proteger contra ataques à cadeia de suprimentos
- Identificar e documentar riscos associados à cadeia de suprimentos.
- Implementar soluções de segurança robustas e monitorar ativamente os dispositivos de desenvolvedores, repositórios de código e pipelines de CI/CD.
- Implementar políticas baseadas no princípio do menor privilégio possível e no conceito de Zero Trust .
- Adotar soluções como Socket Firewall ou Aikido Safe Chain, que funcionam como “proxy”. Dessa forma, os pacotes são interceptados e inspecionados antes da instalação, em busca de anomalias e possíveis ameaças conhecidas.
- Adotar gerenciadores de pacotes como o pnpm, que podem bloquear scripts de pós-instalação.
- Aplicar políticas que impeçam a instalação de pacotes publicados nas últimas 24 a 72 horas (software pinning). Na maioria dos ataques à cadeia de suprimentos, o software comprometido permanece disponível por pouco tempo antes de ser identificado.
- Criar e manter uma lista de SBOM (Software Bill of Materials), que reúne os “ingredientes” que compõem um software, como bibliotecas, dependências e suas versões. Essa lista permite validar rapidamente se há algum componente comprometido com código malicioso, vulnerabilidades e até identificar possíveis violações de propriedade intelectual.
