Como respondemos a um ataque à cadeia de suprimentos do npm

Em 12 de maio de 2026, analisamos nossa exposição à campanha Mini Shai-Hulud, um ataque à cadeia de suprimentos que estava em andamento, após relatos públicos descreverem pacotes comprometidos nos ecossistemas npm e PyPI. Entre eles estavam pacotes do TanStack e intercom-client.

Não encontramos evidências de que os sistemas de produção da Transloadit, os dados de clientes ou os pacotes publicados pela Transloadit tenham sido afetados. Ainda assim, usamos o incidente como um impulso para reforçar as instalações de dependências e os fluxos de lançamento no GitHub Actions em nossos repositórios.

O que aconteceu

Em resumo, os invasores já não dependem apenas de tokens roubados de gerenciadores de pacotes ou de nomes de pacotes que imitam outros com pequenos erros de digitação. No incidente do TanStack, a retrospectiva⁠ dos mantenedores descreve uma cadeia que combinou um fluxo de trabalho pull_request_target, envenenamento do cache do GitHub Actions e acesso a tokens de publicação confiável/OIDC. Como resultado, pacotes maliciosos puderam ser publicados pela infraestrutura oficial de lançamento.

O rastreador do Mini Shai-Hulud⁠ da Socket também associa a campanha a pacotes comprometidos, como intercom-client@7.0.4 no npm e lightning 2.6.2/2.6.3 no PyPI. As cargas maliciosas relatadas têm como alvo ambientes de desenvolvimento e CI, buscando credenciais como tokens do GitHub, tokens do npm, chaves de serviços de nuvem, chaves SSH e configurações de ferramentas de IA.

Isso é relevante porque os sistemas de CI costumam estar estreitamente ligados ao código-fonte, às credenciais de implantação, às permissões de publicação de pacotes e à infraestrutura de nuvem. A instalação de uma dependência maliciosa no lugar errado pode se tornar muito mais do que um problema no ambiente de desenvolvimento local.

Impacto na Transloadit

Não encontramos evidências de impacto nos serviços da Transloadit ou nos dados de clientes.

Nossa análise incluiu:

• Verificar repositórios que usam intercom-client. Encontramos ocorrências no repositório Website, na API e em outros repositórios internos. Em cada caso, porém, a versão estava fixada e era resolvida para intercom-client@5.0.0, e não para as versões 7.0.4 ou 7.0.5 relatadas como maliciosas.
• Verificar arquivos suspeitos e indicadores conhecidos da campanha, incluindo router_init.js, router_runtime.js, execution.js, arquivos suspeitos de fluxos de trabalho shai-hulud e a referência Git maliciosa relatada no incidente do TanStack.
• Verificar a presença do mecanismo de persistência relatado, que monitora tokens do GitHub, nas máquinas de desenvolvimento usadas nesta análise.
• Analisar nossos fluxos de trabalho do GitHub Actions em busca do padrão de risco específico destacado pela retrospectiva do TanStack: código não confiável de pull requests passando para um cache ou fluxo de lançamento confiável.

As versões afetadas dos pacotes que verificamos não estavam presentes nos arquivos de lock nem nas cópias instaladas que analisamos. Também não encontramos os indicadores conhecidos de persistência ou de cargas maliciosas nas árvores de trabalho analisadas.

O que mudamos

Abrimos e atualizamos um conjunto de pull requests de reforço de segurança em nossos repositórios. Essas mudanças são pequenas de propósito: reduzem a exposição a ataques à cadeia de suprimentos, sem alterar o comportamento do produto.

As principais mudanças são:

• Restrições por idade das dependências. Nos repositórios Yarn que ainda não tinham essa proteção, adicionamos npmMinimalAgeGate: 2880, que impede a instalação de versões de pacotes recém-publicadas por 48 horas. Isso dá ao ecossistema tempo para detectar e remover muitas versões comprometidas antes que elas possam entrar em nossas compilações.
• Instalações imutáveis. Alteramos as instalações de CI elegíveis para usar um comportamento imutável ou com arquivo de lock congelado, para que a CI não resolva novas versões de dependências de forma oportunista.
• Limites de confiança dos caches de lançamento. Removemos a restauração de caches compartilhados de dependências dos fluxos de lançamento ou com capacidade de publicação nos quais ela poderia atravessar limites de confiança. Em particular, atualizamos os fluxos de lançamento ou de upload para CDN em monolib, locutus e uppy.
• Análise de CI em repositórios públicos. Analisamos os repositórios públicos em busca de pull_request_target e de fluxos de trabalho com acesso a segredos. Quando repositórios públicos precisam de segredos para a CI, nosso padrão preferido é a aprovação por meio de um ambiente protegido, vinculada ao código específico em teste, em vez de um fluxo baseado apenas em um rótulo de “seguro para testar”.
• Histórico Git verificado, somente com acréscimos. Habilitamos regras do GitHub para toda a organização que exigem commits verificados e bloqueiam envios forçados nos repositórios da Transloadit. A investigação posterior reforçou que branches que não são o padrão e referências antigas fazem parte da superfície de ataque: se um invasor puder reescrever um branch compartilhado com metadados de autoria falsificados, o histórico malicioso pode parecer mais familiar do que realmente é.

Por que isso ajuda

Nenhuma configuração isolada impede todos os ataques à cadeia de suprimentos. O objetivo é criar obstáculos em camadas:

• Uma restrição por idade dos pacotes reduz a chance de instalarmos uma versão recém-comprometida nas primeiras horas de um ataque.
• Instalações imutáveis fazem com que a CI e as implantações reproduzam o arquivo de lock revisado, em vez de descobrir novas versões durante a execução.
• Evitar caches compartilhados nos fluxos de lançamento reduz a chance de tarefas não confiáveis ou com menor nível de confiança deixarem artefatos que uma tarefa confiável de publicação restaure mais tarde.
• Permissões explícitas do GitHub Actions e aprovações de ambiente impedem que tarefas com acesso a segredos sejam executadas com código não revisado de forks.
• Commits verificados dificultam a falsificação de identidade, e o bloqueio de atualizações que não sejam fast-forward preserva o histórico dos branches compartilhados para revisão.

O incidente do TanStack foi um lembrete útil de que caches de compilação e tarefas de lançamento fazem parte do limite de segurança. Agora tratamos esses elementos dessa forma com mais consistência.

O que os clientes devem fazer

Esta análise não exige dos clientes nenhuma ação específica em relação à Transloadit.

Se você instalou algum pacote listado publicamente como afetado pelo Mini Shai-Hulud em 29 de abril de 2026 ou depois, recomendamos seguir as orientações dos mantenedores do respectivo pacote. Em geral, isso significa verificar arquivos de lock e logs de CI, remover as versões afetadas e substituir quaisquer credenciais que estivessem acessíveis nos ambientes em que os pacotes maliciosos possam ter sido executados.

Para seus próprios sistemas de CI, recomendamos os mesmos controles que estamos aplicando:

• Use instalações baseadas exclusivamente no arquivo de lock nos fluxos de CI e implantação.
• Adicione restrições por idade das versões de dependências quando seu gerenciador de pacotes oferecer suporte a elas.
• Evite caches de dependências em fluxos de publicação ou implantação.
• Tenha muito cuidado com pull_request_target; não combine seu uso com o checkout de código não confiável de PRs e o acesso a segredos ou tokens com permissão de escrita.
• Mantenha as permissões do GitHub Actions no mínimo possível e eleve-as apenas na tarefa que precisa da permissão.
• Desabilite envios forçados nos branches compartilhados dos repositórios sempre que possível. Se for necessário que desenvolvedores reformulem o histórico, prefira novos branches a reescrever branches que outras pessoas ou automações possam baixar.

Encerramento

Agradecemos aos mantenedores e pesquisadores que agiram rapidamente para publicar detalhes técnicos e indicadores. Isso permitiu que equipes como a nossa verificassem rapidamente a exposição e transformassem as lições em medidas concretas de reforço de segurança.

Continuaremos monitorando a campanha e atualizaremos este artigo se encontrarmos algum impacto significativo na Transloadit ou alguma ação necessária por parte dos clientes.