Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- Seis campanhas confirmadas contra a cadeia de suprimentos afetaram o npm, o PyPI, os módulos Go e o Packagist entre março e julho de 2026.
- Nenhum deles precisava de um bug no código do aplicativo de ninguém, bastava apenas uma etapa confiável na cadeia de distribuição.
- Três dos seis apareceram e desapareceram em questão de horas, o que é mais rápido do que a maioria dos cronogramas de varredura.
- A detecção pós-instalação foi desenvolvida para um ataque mais lento do que aquele que as equipes estão enfrentando atualmente.
Duas das campanhas mais rápidas deste ano mostram quão pouco tempo um invasor precisa. Duas versões adulteradas do Axios permaneceram no npm por cerca de três horas no dia 31 de março antes que alguém as retirasse. A invasão do Mastra foi ainda mais rápida, republicando mais de 140 pacotes em cerca de 88 minutos em 17 de junho. A Microsoft atribui ambos ao Sapphire Sleet, enquanto o Google associa o comprometimento do axios ao cluster norte-coreano que agora chama de Midnight Neptune, anteriormente conhecido como UNC1069. Nenhuma das invasões foi impedida antes que as versões maliciosas chegassem aos usuários e, em nenhum dos casos, alguém alterou o código-fonte do pacote. O invasor adicionou uma única dependência ao `package.json` e deixou que o `npm install` fizesse o resto.
SCA tradicional com foco em CVE e SBOM nunca foram criados para impedir nenhuma das duas coisas, pois, no momento em que isso importava, não havia nada com que comparar. Ambas as janelas se abriram e se fecharam em menos tempo do que muitas compilações noturnas levam para serem concluídas.
É assim que 2026 se apresenta até agora. Não se trata de uma única violação gigantesca sobre a qual todos ainda estejam discutindo meses depois, mas de uma sequência constante de campanhas curtas, rápidas e executadas com competência, que atingem os registros públicos uma após a outra, enquanto a maioria das defesas ainda permanece na extremidade do funil, aguardando para relatar o que já ocorreu.
O que mudou entre 2025 e 2026
Se analisarmos as datas, o padrão fica bem claro. Seis campanhas confirmadas ocorreram em um período de cinco meses, de março a julho de 2026, em quatro ecossistemas. Isso equivale a, aproximadamente, uma campanha de grande porte, confirmada de forma independente, por mês, sendo que várias delas estão associadas a agentes de ameaças identificados.
E os dados gerais sobre ameaças indicam que não se tratou apenas de um período excepcionalmente ruim. O relatório da Wiz sobre ameaças na nuvem do primeiro semestre de 2026 revelou que o volume de incidentes significativos sinalizados aos clientes aumentou 60% em relação ao segundo semestre de 2025, o maior índice já registrado em qualquer período monitorado, com os ataques à cadeia de suprimentos subindo de cerca de 10% para 25% desses incidentes. A Wiz contabiliza incidentes na nuvem em vez de analisar a higiene do registro, o que serve como uma avaliação independente da tendência, em vez de um fornecedor confirmando sua própria tese. O Grupo de Inteligência de Ameaças do Google avalia com alta confiança que o crescimento de campanhas de código aberto em grande escala na cadeia de suprimentos ao longo de 2025 e no início de 2026 representa uma expansão real da tática, e não uma melhor detecção; além disso, os números da OpenSSF citados por ele apontam um aumento de mais de 1.400% nos pacotes de código aberto maliciosos identificados entre 2024 e 2025.
O tempo de duração de cada campanha é o aspecto que merece atenção. A campanha “Mastra” durou cerca de 88 minutos. A campanha “axios” durou cerca de três horas. As cinco versões maliciosas do jscrambler foram distribuídas ao longo de um período aproximadamente igual. As outras campanhas, por outro lado, ocorreram de maneira discreta, durante semanas, o que pode ser considerado ainda pior. Qualquer um dos extremos desse intervalo representa um desafio para as ferramentas criadas para detectar ameaças em uma cadência noturna.
Análise da realidade: Uma campanha por mês não significa um aumento proporcional no número de invasores. A automação explica grande parte disso, e 2026 nos proporcionou um exemplo claro. A TeamPCP publicou o código-fonte completo do worm Mini Shai-Hulud no GitHub em 12 de maio, e campanhas derivadas que utilizavam essa cadeia de ferramentas surgiram em questão de semanas. Publicar um pacote pode ser automatizado, roubar uma credencial pode ser automatizado, e a falsificação de namespace já pode ser automatizada há anos.
Você também pode saber mais sobre o “slopsquatting” e as “alucinações” dos pacotes de IA em nossa visão geral detalhada.
As seis campanhas que estabeleceram o padrão
Os seis casos a seguir não constituem uma lista dos seis principais em termos de número de pacotes. São os seis que melhor abrangem o leque de eventos ocorridos este ano, desde invasões por meio de credenciais roubadas (axios, jscrambler) até um worm que se autopropaga, uma conta inativa reativada, injeção de prompt direcionada a revisores de IA e apropriação de contas impulsionada por engenharia social.
| Campanha | Data | Ecossistema de pacotes | O que fez com que desse certo |
| sequestro do Axios | 31 de março | npm | O computador do mantenedor principal foi comprometido por meio de engenharia social; em seguida, duas versões adulteradas foram enviadas diretamente para o npm, permanecendo ativas por cerca de três horas. O incidente foi atribuído ao Sapphire Sleet pela Microsoft e ao Midnight Neptune pelo Google. |
| Mini Shai-Hulud | A partir de 29 de abril | npm | Worm autopropagável que coletava credenciais do npm e de CI e, em seguida, se republicava em todos os pacotes que suas vítimas pudessem publicar. Atribuído ao TeamPCP. |
| Hades | 7 a 8 de junho | PyPI | Foram enviados 19 pacotes contendo 37 “wheels” maliciosos com ganchos de inicialização .pth, com texto de injeção de prompt voltado para revisão baseada em LLM. Fazem parte da linha Miasma, que por sua vez é derivada do Mini Shai-Hulud. |
| Aquisição da Mastra | 17 de junho | npm | Conta de colaborador inativa, sem atividade desde fevereiro de 2025, com acesso ao escopo nunca revogado, usada para republicar mais de 140 pacotes com uma dependência inserida. O mesmo agente responsável pelo axios. |
| jscrambler | 11 de julho | npm | Credenciais de publicação roubadas foram usadas para distribuir cinco versões contendo um programa de roubo de informações multiplataforma, sendo que as três primeiras foram distribuídas por meio de um gancho de pré-instalação. |
| PolinRider | A partir de março | npm, Go, Packagist | Contas de mantenedores foram comprometidas por meio de ferramentas de desenvolvimento maliciosas e processos de recuperação de conta, sendo depois utilizadas para inserir carregadores ofuscados em 108 pacotes e extensões. O caso foi registrado no início de julho e está relacionado ao cluster “Contagious Interview”. |
Se colocarmos esses seis casos lado a lado, há um ponto em comum entre todos eles. Nenhum deles precisou de uma vulnerabilidade no próprio código da vítima. Todos exploraram uma etapa confiável em algum ponto entre o teclado do mantenedor e o seu comando de instalação; e, em quatro dos seis casos, essa etapa foi uma conta legítima do mantenedor.
A semelhança entre o axios e o Mastra não é uma coincidência de estilo. A Microsoft colocou o mesmo criativo por trás das duas; portanto, pelo menos dois dos seis eram um único grupo refinando sua abordagem entre uma campanha e outra, em vez de duas equipes terem chegado à mesma ideia. Hades e Mini Shai-Hulud também compartilham uma árvore genealógica. Seis campanhas, portanto, mas mais próximas de quatro grupos distintos — o que vale a pena deixar claro antes que alguém interprete a contagem como seis grupos independentes.
Vale a pena dedicar um minuto para analisar o Hades. Seus pacotes continham injeção de prompt em texto simples com o objetivo de induzir um analisador baseado em LLM a classificá-los como seguros — o que os pesquisadores descreveram como uma técnica inovadora de evasão —, e isso só funciona como estratégia se os invasores partirem do princípio de que ferramentas de IA agora estão intercaladas entre o pacote e o engenheiro. Até meados de 2026, isso não será nada improvável. O caso do Maven Central, em dezembro, utilizou ruído semelhante contra análises de aprendizado de máquina, de modo que a técnica vinha amadurecendo discretamente há meses. O Hades também executava um monitor de tokens que ameaçava com ações destrutivas caso os tokens roubados do GitHub fossem revogados, o que reorganiza discretamente a ordem das operações para quem estiver fazendo a limpeza.
O PolinRider é aquele que deve causar preocupação, por um motivo diferente. Não se tratou de uma apropriação oportunista de nomes abandonados, e a via de acesso relatada é mais estranha do que um vazamento de credenciais. Os pesquisadores afirmam que as credenciais roubadas do GitHub não foram, de forma alguma, o vetor de ataque. As vítimas foram comprometidas inicialmente por meio de uma extensão maliciosa do VS Code ou de um pacote npm, com a invasão da conta do mantenedor ocorrendo posteriormente por meio de domínios expirados ou outras vias de recuperação de conta, tudo isso envolto em engenharia social pela qual a equipe do Contagious Interview é conhecida. Boas práticas de publicação não fazem esse risco desaparecer — o ponto fraco está nas ferramentas do mantenedor e na recuperação de conta, e não no processo de lançamento.
Mais duas campanhas de 2026 são mencionadas mais adiante neste artigo. O TrapDoor plantou 34 pacotes maliciosos no npm, no PyPI e no Crates.io, e o Laravel-Lang teve mais de 700 versões comprometidas por meio de tags do Git reescritas. O TeamPCP é um caso diferente. Ele não tem uma seção própria porque a seção do Mini Shai-Hulud já se refere ao TeamPCP. A operação mais ampla, que o Google rastreia como UNC6780, ocorreu de fevereiro a maio e encadeou violações de CI/CD contra ferramentas de segurança , incluindo Trivy, Checkmarx e suas imagens Docker do KICS, além do LiteLLM, em uma longa onda de coleta de credenciais. Maior do que uma linha de tabela – mesmo mecanismo.
A superfície de ataque passou a estar no momento da instalação
O tema que permeia todo o ano de 2026 é o momento certo.
Os invasores exploraram a mesma vulnerabilidade no npm, no PyPI e no Cargo a partir de três ângulos diferentes, e o TrapDoor é o exemplo mais claro porque uma campanha utilizou todos os três. Um gancho pós-instalação no npm, execução no momento da importação no PyPI e um script `build.rs` que é executado durante o `cargo build` no Crates.io. Gatilhos diferentes, mesma ideia. O código é executado durante a aquisição do pacote, e não durante seu uso. A parte em Go do PolinRider funciona de maneira diferente, já que a carga maliciosa fica nos arquivos de configuração das ferramentas de compilação e nas tarefas do VS Code em vez de um gancho de instalação; assim, ele é acionado quando as ferramentas do desenvolvedor abrem o projeto, e não durante o `go get`. O mesmo abuso de confiança, mas em um ponto diferente do pipeline.
As ferramentas padrão pressupõem que existe um intervalo de tempo entre o momento em que uma dependência é identificada e o momento em que ela é executada, tempo suficiente para que uma verificação consiga detectar algo primeiro. A execução no momento da instalação elimina esse intervalo para qualquer processo que apenas inspecione artefatos após a resolução.
Imagine uma equipe de engenharia de 40 pessoas com um pipeline razoavelmente maduro. O Dependabot abre PRs, uma ferramenta SCA verifica o lockfile, a CI bloqueia qualquer item de alta gravidade e um SBOM é gerado no momento da compilação. Essa configuração lida bem com dependências conhecidas como vulneráveis. No entanto, ela é muito menos eficaz contra uma versão publicada há uma hora, que parece ser apenas um aumento de versão comum, é executada durante a instalação e é retirada antes do almoço. Não havia nenhum aviso de segurança que correspondesse a nada nessa cadeia e, nos casos do axios e do Mastra, a carga maliciosa estava um nível abaixo, dentro de uma dependência que o scanner não tinha motivo para examinar duas vezes.
Atenção: O pinning exato faz mais do que as pessoas imaginam e menos do que esperam. Qualquer um que tenha feito o pinning em um axios limpo e não tenha feito uma instalação nova durante o intervalo de três horas saiu ileso. O que o pinning não vai te dizer é se a versão para a qual você deliberadamente atualizou é confiável, e ele não faz nada quando um intervalo aberto em uma dependência transitiva resolve isso por você. Foi exatamente assim que o Mastra foi afetado, já que a dependência `easy-day-js` injetada foi declarada como um intervalo com o símbolo de caret e o npm alegremente atualizou para a versão de patch comprometida. O pinning também pressupõe que o artefato por trás de uma versão não pode mudar, o que o Laravel-Lang refutou ao reescrever tags históricas para apontar para um novo commit.
A verificação de pacotes antes que eles cheguem ao computador de um desenvolvedor ou a um agente de compilação é um dos poucos pontos da cadeia em que o código durante a instalação pode ser bloqueado, em vez de ser apenas relatado posteriormente. Essa é a lacuna que o SecureChain for OSS foi desenvolvido para preencher, e é também por isso que ele atua no nível do registro, em vez de adicionar mais um verificador ao final do pipeline.
Por que seu scanner está sempre atrasado
A análise tradicional de composição de software com foco em CVE é eficaz em responder a uma pergunta: quais componentes com vulnerabilidades conhecidas foram incluídos nesta compilação. É realmente eficaz nisso e vale a pena mantê-la.
Por si só, porém, isso não responde a outra questão. Será que esse artefato, neste momento, é exatamente o que seu mantenedor publicou?
Esse é mais um problema de dados do que um problema de produto. A SCA focada em vulnerabilidades compara seu inventário de dependências com os dados dos alertas, e um alerta só existe depois que alguém encontra o pacote malicioso, o denuncia e faz com que o alerta seja publicado. A detecção costuma ser rápida. O Socket sinalizou a versão maliciosa do jscrambler seis minutos após a publicação, e os pacotes TrapDoor levaram, em média, menos de seis minutos desde a publicação até a detecção. O aviso que seu scanner consulta é a parte demorada, e muitos desses incidentes nunca geram um CVE, o que também explica por que nenhum deles jamais aparecerá no Catálogo de Vulnerabilidades Exploradas da CISA. Os feeds de alertas são, por natureza, um registro do que já foi descoberto.
Vale a pena saber: Várias campanhas de 2026 publicaram versões maliciosas que pareciam simples atualizações de patch, sem nenhum commit, pull request ou tag correspondente por trás delas. O jscrambler 8.14.0 é o caso mais evidente, já que os pesquisadores não encontraram nenhum commit, tag ou PR para ele no repositório do projeto no GitHub, onde a tag mais recente ainda era 8.13.0. Os atualizadores convencionais não verificam se um artefato corresponde a uma alteração na fonte. Eles veem um novo número de versão, abrem uma solicitação de pull e algumas equipes a mesclam automaticamente. Um aumento de versão e uma alteração verificada não são a mesma coisa.
Para onde apontam os próximos números do ecossistema
Ao longo de 2024 e da maior parte de 2025, o npm atraiu toda a atenção, graças aos seus números de adoção e aos scripts de ciclo de vida que são executados automaticamente durante a instalação. Esse período de destaque chegou ao fim.
O TrapDoor atingiu três ecossistemas na mesma semana de maio, com 34 pacotes maliciosos e mais de 384 versões no npm, PyPI e Crates.io. Tratava-se de ferramentas falsas, e não de ferramentas sequestradas, com nomes que soavam como utilitários que um desenvolvedor de criptografia ou IA instalaria sem pensar duas vezes, e cada repositório tinha seu próprio caminho de execução. O grupo também disseminou arquivos .cursorrules e CLAUDE.md para manipular assistentes de codificação de IA, o que dá uma boa ideia de para onde isso vai levar.
O Packagist também passou por um mês de maio difícil. Os invasores reescreveram todas as tags do Git em quatro repositórios de localização do Laravel-Lang em um intervalo de cerca de 90 minutos nos dias 22 e 23 de maio, e mais de 700 versões históricas acabaram apontando para um commit malicioso que o autoloader do Composer executou em todas as solicitações. O ponto de entrada foi um token do GitHub que vazou, e o código-fonte do projeto nunca foi alterado. Separadamente, uma campanha envolvendo oito pacotes ocultou sua carga maliciosa no arquivo package.json em vez de no composer.json, o que a colocou exatamente onde uma revisão focada em PHP teria menos chances de procurar.
Você também pode conhecer as melhores práticas para proteger seu ecossistema PHP em nosso guia completo sobre segurança no Laravel.
E em dezembro de 2025, pouco antes do período abordado neste artigo, um site com um nome semelhante ao de Jackson, criado por meio de typosquatting apareceu no Maven Central carregando um beacon do Cobalt Strike. O truque consistia na troca do prefixo: “org.fasterxml”, enquanto a biblioteca real usa “com.fasterxml” — algo que a convenção de domínio reverso do Java não consegue detectar. A Aikido, que o identificou, classificou-o como o primeiro malware sofisticado que sua equipe havia detectado no Maven Central; portanto, considere isso uma novidade para esses pesquisadores, e não para todo o ecossistema. A remoção foi rápida, pelo menos, cerca de 90 minutos após a denúncia.
Entenda isso como uma mudança no foco das principais campanhas, e não como uma divisão clara entre “antes” e “depois”, já que pacotes maliciosos já haviam aparecido na maioria desses registros anteriormente. Para uma empresa que trabalha com várias linguagens de programação, a lição prática é que as defesas específicas para cada ecossistema deixam de garantir uma cobertura real. Controles robustos no npm, práticas pouco rigorosas no PyPI e a ausência total de medidas para Go ou Rust resultam em uma porta da frente trancada e várias entradas laterais abertas — e os dados deste ano indicam que os invasores já estão tentando explorá-las.
O que fazer a respeito
Nada disso exige uma reformulação da arquitetura. Tudo isso pode ser feito neste trimestre.
Se você tiver um ecossistema principal
Primeiro, elimine essa lacuna na fase de instalação. Defina `ignore-scripts=true` no arquivo `.npmrc` sempre que sua compilação permitir, e encaminhe as instalações por meio de uma camada de registro que filtre os pacotes antes que eles sejam resolvidos. No entanto, não considere o bloqueio de scripts como a solução definitiva. Duas das cinco versões maliciosas do jscrambler transferiram o dropper do gancho de pré-instalação para o código principal do pacote e para a CLI, onde a opção `–ignore-scripts` não tem efeito algum.
Se você é poliglota
Identifique quais ecossistemas não possuem controles antes de se aprofundar naqueles que já contam com alguns. Nesse modelo de ameaça, as lacunas de cobertura são mais graves do que as lacunas de profundidade. Tanto o TrapDoor quanto o PolinRider demonstraram que basta um único ecossistema sem controles para comprometer todo o trabalho realizado nas demais áreas.
Se você depende de atualizações automatizadas de dependências
Adicionar um período de carência para novos lançamentos. As orientações de mitigação da Unit 42 sugere bloquear qualquer versão publicada nas últimas 24 a 72 horas, com base no fato de que a maioria dos pacotes maliciosos é identificada e removida dentro desse intervalo, e a Wiz adota uma abordagem semelhante com um período de espera de 24 horas. Uma quarentena curta transforma boa parte desses ataques em algo sem importância, ao custo de um pequeno atraso na aplicação dos patches.
É melhor antecipar um controle do que simplesmente acrescentar outro no final. Há dois aspectos que se destacam mais do que os demais neste contexto: interceptar um pacote antes que ele seja resolvido e verificar se o artefato recebido corresponde à fonte e à compilação das quais ele alega ter vindo.
Vale a pena ativar a proveniência, com uma ressalva. O Mastra gerava proveniência nas publicações de CI, mas não a exigia; assim, um token roubado ainda poderia publicar sem atestados, enquanto a onda de Mini Shai-Hulud do TanStack produziu pacotes com proveniência SLSA válida porque o próprio pipeline foi corrompido. Exigir atestados teria impedido o primeiro caso, mas não o segundo.
A eficácia também varia de acordo com o ecossistema. A invasão de contas no Go e os hooks de inicialização do PyPI são problemas distintos que exigem soluções diferentes; portanto, qualquer mecanismo de controle pelo qual valha a pena pagar precisa levar em conta como cada ecossistema realmente executa o código.
O que isso significa para você
Não há nada de exótico nisso. O 2026 não inventou uma nova classe de vulnerabilidade. Ele transferiu a batalha para um ponto em que a maioria das equipes não estava atenta: o momento em que um pacote é resolvido e executado, em vez do momento em que alguém finalmente o verifica. Todas as campanhas desta lista, desde um sequestro do npm que durou três horas até um módulo Go acessado por meio de uma conta de mantenedor sequestrada, funcionaram porque a confiança foi concedida antes que qualquer mecanismo de controle tivesse a chance de verificar, seja durante a resolução, a instalação, a compilação ou no momento em que um editor abriu o projeto.
Portanto, a verdadeira questão não é se devemos manter a detecção pós-instalação. É preciso mantê-la. A questão é se a prevenção pode ocorrer mais cedo, de modo que uma verificação executada depois que a carga maliciosa já tiver obtido os segredos da sua infraestrutura de infra (CI) não seja a primeira a alertá-lo sobre o problema. O SecureChain para OSS existe para equipes que desejam isso sem precisar desenvolvê-la por conta própria.
Perguntas frequentes
O que é um ataque à cadeia de suprimentos de software?
Um ataque que compromete um software por meio de uma dependência confiável, um sistema de compilação, um repositório ou um canal de distribuição, em vez de atacar diretamente o seu aplicativo. As campanhas de 2026 tiveram como alvo, em sua grande maioria, registros públicos de pacotes e as contas que publicam neles.
Quantos ataques à cadeia de suprimentos de software ocorreram em 2026?
Não há um total oficial. Este artigo aborda seis grandes campanhas confirmadas entre março e julho de 2026, e várias outras que ficam um pouco fora desse conjunto, incluindo TrapDoor, Laravel-Lang e a operação mais ampla TeamPCP.
Uma SBOM previne ataques à cadeia de suprimentos?
Não. Uma SBOM lista os componentes utilizados em uma compilação, o que é valioso para fins de resposta a incidentes e auditoria. Ela não garante que um artefato listado seja o mesmo que foi publicado por seu mantenedor, nem impede que o código seja executado durante a aquisição de dependências.
Quais ecossistemas de pacotes foram os mais afetados?
O npm foi palco da maioria dos incidentes de grande repercussão em 2026, enquanto o PyPI, os módulos Go, o Crates.io e o Packagist foram alvo de campanhas específicas envolvendo vários pacotes até meados do ano. O Maven Central teve seu próprio momento logo antes do início do ano.
