A lição sobre a cadeia de suprimentos por trás do Shai-Hulud e do Megalodon

A versão resumida

O que: Shai-Hulud e Megalodon foram ataques à cadeia de suprimentos de software ocorridos em 2026 que tiveram como alvo os sistemas nos quais os desenvolvedores mais confiam: registros de pacotes, fluxos de trabalho do GitHub Actions, executores de CI/CD, pipelines de proveniência e federação de identidades na nuvem.

Impacto: O Mini Shai-Hulud comprometeu pacotes do npm e do PyPI, incluindo pacotes vinculados ao TanStack, Mistral AI, Guardrails AI, UiPath e OpenSearch, e foi o primeiro ataque amplamente documentado a distribuir malware com proveniência válida de nível 3 do SLSA (CVE-2026-45321, CVSS 9,6). Posteriormente, o Megalodon enviou 5.718 commits maliciosos para 5.561 repositórios do GitHub em cerca de seis horas, criando backdoors nos fluxos de trabalho do GitHub Actions para roubar credenciais de nuvem, chaves SSH, tokens do GitHub, dados de tokens OIDC e segredos de código-fonte.

Status: Essas campanhas já não são mais notícias de última hora, mas a lição continua válida. Quaisquer credenciais expostas, fluxos de trabalho contaminados e inativos, versões de pacotes comprometidas ou políticas de confiança de CI/CD excessivamente amplas que não tenham sido corrigidas ainda podem gerar riscos a jusante.

Gravidade: Alto impacto na cadeia de suprimentos. Não se trata de um único pacote vulnerável ou de um único CVE que possa ser corrigido e esquecido. Trata-se de um padrão de ataque repetível contra as infraestruturas que desenvolvem e publicam software.

Por que isso é importante para a aceitação de pacotes: o Megalodon explorou a lacuna entre o código-fonte e a publicação. O invasor não precisava comprometer a conta do npm, já que um mantenedor legítimo poderia, sem saber, publicar a partir de um código-fonte adulterado. Esse é o tipo de lacuna que o SecureChain foi projetado para preencher, analisando novas versões de pacotes no momento da integração, incluindo diferenças no código-fonte, ganchos de compilação, cargas ofuscadas, caminhos de execução ocultos e comportamento de exfiltração, antes que uma versão seja considerada confiável nas etapas posteriores.

Faça isso agora: audite os fluxos de trabalho do GitHub Actions, verifique se há indicadores do Megalodon, alterne quaisquer segredos expostos a executores de CI suspeitos, analise a aceitação de pacotes afetados e torne mais rigorosas as políticas de confiança do OIDC.

Isso me afeta?

Você pode ser afetado se a sua organização:

• Utiliza o GitHub Actions para compilações, testes, lançamentos, publicação de pacotes ou implantação
• Permite que os fluxos de trabalho solicitem um id-token: gravação
• Armazena credenciais de nuvem, registro, SSH, Docker, Kubernetes, Terraform ou Vault no CI/CD
• Utiliza pacotes do npm ou do PyPI provenientes de registros públicos sem controles adicionais de aceitação
• Pacotes Mini Shai-Hulud afetados foram instalados durante a janela de exposição de maio de 2026
• Versões 2.18.6 a 2.18.12 do @tiledesk/tiledesk-server instaladas
• Permite envios diretos para os ramos padrão
• Não requer revisão para alterações em .github/workflows
• Considera a proveniência, a assinatura ou um editor de pacotes conhecido como prova de que uma dependência é segura

Um bom ponto de partida é pesquisar nos repositórios os nomes conhecidos dos fluxos de trabalho do Megalodon e o endereço C2:

grep -R "SysDiag\|Optimize-Build\|216\.126\.225\.129" .github/workflows/ 2>/dev/null

Em seguida, procure por execução de shell codificada dentro dos fluxos de trabalho:

grep -R "base64 -d.*bash\|base64.*| *bash" .github/workflows/ 2>/dev/null

Caso alguma das pesquisas apresente resultados inesperados, analise o histórico do repositório e os logs de CI antes de remover arquivos ou atualizar as credenciais. Os logs podem ser necessários para entender o que foi executado, quando foi executado e quais segredos foram expostos.

O que são o Shai-Hulud e o Megalodon

Shai-Hulud é o nome dado a uma família de ataques à cadeia de suprimentos que se propagam automaticamente contra ecossistemas de desenvolvedores, especialmente o npm e o PyPI.

O worm original surgiu em setembro de 2025, quando a Unit 42 documentou um worm npm autorreplicável que coletava credenciais e as utilizava para se propagar. Uma variante mais abrangente, o Shai-Hulud 2.0, surgiu em novembro. Na primavera de 2026, o agente malicioso conhecido como TeamPCP já havia passado meses inserindo backdoors em ferramentas de desenvolvimento e segurança de alta confiança.

O Mini Shai-Hulud, a onda de maio de 2026, elevou o nível do risco. Ele não se limitou a publicar pacotes maliciosos por meio de contas obviamente suspeitas. Ele comprometeu pipelines de compilação legítimos e os utilizou para produzir pacotes maliciosos que apresentavam atestados de proveniência válidos.

O Megalodon atingiu um nível diferente. Em vez de se concentrar na publicação de pacotes, ele injetou em massa fluxos de trabalho do GitHub Actions em milhares de repositórios. Esses fluxos de trabalho foram executados dentro de executores de CI e roubaram os segredos que os sistemas de CI/CD mantêm por padrão: credenciais de nuvem, tokens do GitHub, chaves SSH, dados de solicitação de tokens OIDC, credenciais do Docker, configurações do Kubernetes, credenciais do Terraform, tokens do Vault e segredos do código-fonte.

Juntas, as duas campanhas mostram a mesma tendência. Os invasores não estão mais apenas tentando corromper o pacote que você instala. Eles estão tentando corromper o sistema que o compila, assina, publica e implanta.

Primeira onda: o Mini Shai-Hulud e o problema do SLSA

O momento de destaque do Mini Shai-Hulud ocorreu em 11 de maio de 2026, às 19h20 UTC, quando 84 artefatos maliciosos foram publicados em 42 pacotes no namespace @tanstack, em um intervalo de seis minutos. Os pacotes pareciam ter origem no pipeline de lançamento real da TanStack, utilizando sua identidade OIDC real.

Isso porque eles realmente fizeram isso.

O mecanismo, identificado como CVE-2026-45321 (CVSS 9,6), combinou três vulnerabilidades conhecidas do GitHub Actions em um único caminho:

1. Um gatilho `pull_request_target` que é executado com acesso de gravação mesmo quando o pull request que o aciona provém de um fork, servindo como ponto de partida.
2. Envenenamento de cache do GitHub Actions, usado para inserir uma dependência modificada na compilação legítima.
3. Roubo de um token OIDC ativo da memória do processo do runner, utilizado para obter um certificado de assinatura Sigstore válido.

Com um certificado de assinatura autêntico proveniente de um pipeline real, o worm gerou atestados de proveniência SLSA válidos, de Nível 3, para os pacotes maliciosos.

Essa é a parte que deve mudar a forma como as equipes encaram a proveniência.

Isso não significa que o SLSA tenha falhado no que se propôs a fazer. Significa que muitas equipes estão fazendo à proveniência uma pergunta para a qual ela não tem resposta. A proveniência pode mostrar de onde um artefato veio e se ele foi compilado pelo processo esperado. Nesse caso, essa garantia era tecnicamente verdadeira, pois os pacotes maliciosos realmente foram compilados pelo pipeline esperado. O problema era que o próprio pipeline havia sido comprometido.

O SLSA atesta a integridade da compilação. Ele não comprova que o código inserido na compilação era seguro, que o fluxo de trabalho não foi adulterado ou que o ambiente do mantenedor não havia sido comprometido a montante. Essa distinção não é meramente acadêmica: a onda de imitações de 1º de junho contra o namespace @redhat-cloud-services distribuiu pacotes maliciosos, cada um com proveniência npm válida, publicados por meio do OIDC do GitHub Actions a partir de uma conta de funcionário comprometida. A proveniência fez exatamente o que promete. Só que ela não promete o que as equipes supõem.

O worm se espalhou por 172 pacotes do npm, além de dois pacotes do PyPI, em 404 versões maliciosas, atingindo ecossistemas vinculados ao TanStack, Mistral AI, Guardrails AI, UiPath e OpenSearch. A carga útil ofuscada de 2,3 MB vasculhou mais de 100 caminhos de arquivos em busca de segredos e instalou ganchos de persistência que sobrevivem à reinicialização em ferramentas de desenvolvimento, incluindo o Claude Code e o Visual Studio Code. Relatórios públicos estimaram que os pacotes afetados somaram mais de 518 milhões de downloads [verificar o número exato antes da publicação; as fontes divergem se esse número é cumulativo ou semanal], razão pela qual esse foi um problema de dependência a jusante para qualquer organização que tenha feito downloads de registros públicos durante o período em questão, e não apenas um incidente do lado dos mantenedores.

Um dia depois, em 12 de maio, a TeamPCP disponibilizou o framework Shai-Hulud na íntegra como código aberto no GitHub sob uma licença MIT, supostamente acompanhado de um concurso que oferecia US$ 1.000 em Monero para o maior ataque à cadeia de suprimentos criado com ele. Uma capacidade aperfeiçoada ao longo de meses tornou-se algo que qualquer invasor competente poderia replicar até o fim de semana.

Uma verificação de proveniência ecológica não é um veredicto de segurança. É apenas um dos indicadores que contribuem para uma decisão mais ampla sobre a confiabilidade.

Segunda Onda: O Megalodon e a Revolução do CI/CD

Seis dias após esse lançamento de código aberto, o Megalodon chegou.

Entre 11h36 e 17h48 UTC do dia 18 de maio de 2026, a campanha enviou 5.718 commits maliciosos para 5.561 repositórios do GitHub. O invasor utilizou contas descartáveis com nomes de usuário aleatórios de oito caracteres (rkb8el9r, bhlru9nr e similares) e identidades de autor falsificadas no estilo de bots:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

As mensagens de commit foram elaboradas de forma a parecerem parte de uma manutenção de rotina:

• ci: adicionar etapa de otimização da compilação
• tarefa: otimizar o tempo de execução do pipeline
• mudanças semelhantes relacionadas à CI que são fáceis de deixar passar despercebidas

O invasor não estava tentando fazer com que o código do aplicativo parecesse malicioso. O invasor estava tentando fazer com que as alterações no pipeline parecessem enfadonhas.

O Megalodon implantou duas variantes de fluxo de trabalho do GitHub Actions, ambas solicitando `id-token: write` e `actions: read`, ambas executando uma carga útil em Bash decodificada em base64 e ambas se comunicando com o mesmo servidor C2 no endereço 216.126.225.129:8443.

O SysDiag era a variante mais barulhenta e abrangente. Ele adicionava um fluxo de trabalho acionado a cada solicitação de envio e recebimento, maximizando a frequência com que era executado e coletava dados.

O Optimize-Build era a variante silenciosa. Ele utilizava o `workflow_dispatch`, de modo que o fluxo de trabalho podia permanecer inativo até ser acionado manualmente por meio da API do GitHub. Isso o torna mais útil como uma porta dos fundos: sem compilações falhadas constantes, sem falhas evidentes e sem motivo imediato para que um mantenedor percebesse.

A coleta de dados pela carga útil foi abrangente. Ela coletou variáveis de ambiente de CI e /proc/*/environ, credenciais da AWS em todos os perfis configurados, tokens do Google Cloud, credenciais de funções de instância extraídas dos endpoints IMDSv2 da AWS e IMDS do Azure, chaves privadas SSH, Docker, .npmrc, .netrc, Kubernetes, Vault e Terraform, histórico do shell, mais de 30 padrões de expressões regulares de chaves de API e cadeias de conexão e, mais importante ainda, a URL de solicitação do token OIDC do GitHub Actions e o próprio token, além dos tokens do GITHUB_TOKEN, GitLab e Bitbucket.

Por que o roubo na OIDC é importante

Muitas organizações deixaram de usar chaves de nuvem de longa duração em CI/CD e passaram a adotar a federação OIDC. Essa é uma boa direção. Em vez de armazenar credenciais permanentes da AWS, do Google Cloud ou do Azure no GitHub Actions, o fluxo de trabalho solicita credenciais de curta duração quando precisa delas.

O Megalodon mostra em que pontos esse modelo ainda precisa de limites.

Se um fluxo de trabalho malicioso puder solicitar “id-token: write”, ele poderá obter os dados da solicitação de token OIDC necessários para se passar por uma identidade confiável de um fluxo de trabalho. Se a política de confiança na nuvem correspondente tiver um escopo muito amplo, esse fluxo de trabalho malicioso poderá gerar credenciais de nuvem de curta duração na própria máquina do invasor.

A questão não é que o OIDC seja ruim. A questão é que a confiança no OIDC deve ser restrita. Uma configuração segura deve responder:

• Qual repositório, exatamente, pode solicitar essa função?
• Qual ramificação, tag ou ambiente é permitido?
• Qual fluxo de trabalho é permitido?
• Esse fluxo de trabalho realmente precisa da operação “id-token: write”?
• Um fluxo de trabalho recém-adicionado pode herdar o mesmo nível de confiança?
• Um fluxo de trabalho em um branch que não seja de lançamento pode solicitar credenciais de produção?

Se a política de confiança efetivamente afirmar que “este repositório é confiável”, o alcance do impacto será maior do que o necessário. O OIDC reduz o risco de segredos estáticos de longa duração. Ele não resolve o problema da execução de fluxos de trabalho comprometidos.

O caso da Tiledesk mostra o risco a jusante

O Megalodon não era apenas um problema do proprietário do repositório.

Pelo menos um pacote dependente, @tiledesk/tiledesk-server, foi publicado de forma comprometida nas versões 2.18.6 a 2.18.12. O detalhe importante é que a conta do npm não foi o ponto inicial da invasão. O invasor contaminou o repositório de código-fonte ao injetar arquivos maliciosos de fluxo de trabalho do GitHub Actions, e o mantenedor legítimo, sem saber, publicou versões a partir desse código-fonte contaminado.

É por isso que a autenticação de dois fatores (2FA) e a assinatura de código não foram suficientes. O evento de publicação ainda parecia legítimo, pois o invasor nunca precisou assumir o controle da conta do npm. Ambos os controles confirmaram que a versão havia sido lançada pelo mantenedor legítimo, o que de fato aconteceu. A falha de integridade ocorreu antes disso, entre o código-fonte e a publicação.

É também por isso que a análise de diferenças no código-fonte é importante. Um detector que compare uma nova versão de um pacote com a versão anterior no momento da integração examinaria a alteração da versão 2.18.5 para a 2.18.6 antes de confiar na nova versão. Os arquivos de fluxo de trabalho e a carga útil injetados se enquadram perfeitamente nas categorias que devem acionar alarmes: ganchos de execução em tempo de compilação, caminhos de execução no estilo CI/CD, cargas úteis ofuscadas, execução oculta, coleta de credenciais e atividade de rede suspeita — o mesmo padrão de backdoor encontrado no event-stream e no ua-parser-js.

Essa é exatamente a lacuna específica que o SecureChain foi desenvolvido para resolver. Como ele analisa o diff do código-fonte em vez de confiar no evento de publicação, o SecureChain foi projetado para detectar o cenário em que o mantenedor publica um código-fonte corrompido — situação que a assinatura, a proveniência e a autenticação de dois fatores (2FA) do registro não conseguem identificar — e para fornecer à equipe de segurança um artefato de raciocínio, trechos do diff sinalizados, justificativas e um veredicto, antes que a versão seja distribuída para as etapas posteriores do processo.

 

A cadeia de eventos, em termos mais amplos, se apresenta da seguinte forma:

1. Um repositório é alterado por meio de acesso roubado ou indevido.
2. Um fluxo de trabalho do GitHub Actions é inserido ou substituído.
3. O fluxo de trabalho é executado em um ambiente de CI confiável.
4. Os segredos são extraídos do corredor.
5. Um pacote pode ser compilado ou publicado a partir de um código-fonte corrompido.
6. Os usuários finais instalam o que parece ser um pacote legítimo.

Do ponto de vista do consumidor, o nome do pacote é conhecido, o editor é legítimo e o lançamento vem da conta esperada. Mas a fonte e o fluxo de trabalho por trás disso já estavam comprometidos. “Editor confiável” e “pacote seguro” não são a mesma coisa.

A disputa sobre a atribuição e por que isso não altera sua resposta

É aí que a cobertura da mídia se torna confusa.

O TeamPCP está fortemente associado às atividades mais amplas do Shai-Hulud, incluindo campanhas anteriores relacionadas à cadeia de suprimentos e o lançamento, em 12 de maio, da estrutura do worm. Algumas reportagens atribuem o Megalodon diretamente ao TeamPCP.

Uma análise mais cuidadosa indica que o Megalodon apresenta forte sobreposição de técnicas operacionais com atividades no estilo Shai-Hulud, mas a atribuição direta ainda não está confirmada. A OX Security, que analisou a carga útil do Megalodon, avaliou-a como provavelmente uma imitação, observando comportamento e estilo semelhantes, mas pouco código compartilhado, ausência de links diretos, ausência de indicadores de identificação em comum e nenhuma reivindicação de responsabilidade. O Megalodon também não possui a chave de criptografia pública exigida pelo TeamPCP para inscrições em seu próprio concurso, portanto, nem sequer é uma inscrição no concurso. O Mini Shai-Hulud apresenta fortes indícios de atribuição ao TeamPCP; o Megalodon apresenta semelhanças circunstanciais. Considere a atribuição direta como de baixa confiança.

Para os defensores, essa distinção não deve atrasar nada. Seja o Megalodon o TeamPCP, um imitador ou outro agente utilizando as ferramentas de código aberto, a resposta é a mesma: identificar fluxos de trabalho comprometidos, alternar segredos expostos, reforçar a segurança do OIDC, restringir alterações nos fluxos de trabalho e tratar os endpoints dos desenvolvedores e as identidades de CI/CD como parte da cadeia de suprimentos. É preciso se defender contra o método, não contra o nome da marca.

A causa principal também é menos exótica do que os nomes da campanha sugerem. A Hudson Rock cruzou os nomes de usuário do GitHub por trás dos commits do Megalodon com seu banco de dados de infostealers e descobriu que 331 de 978 (mais de um terço) correspondiam a máquinas já infectadas por infostealers, concluindo que o acesso teve origem nos logs desses infostealers. A pré-condição para ataques como esse geralmente não é uma vulnerabilidade zero-day no GitHub. Trata-se de uma estação de trabalho de desenvolvedor ou ambiente de mantenedor que já estava comprometido.

Por que os scanners tradicionais não detectam esse tipo de ataque

A maioria dos scanners de vulnerabilidades é desenvolvida para responder a perguntas como:

• Este pacote possui algum CVE conhecido?
• Essa dependência está desatualizada?
• Este contêiner está utilizando uma biblioteca vulnerável?
• Esse artefato está associado a algum malware conhecido?

Essas questões ainda são importantes. Mas Shai-Hulud e Megalodon atuam em um nível diferente.

Um fluxo de trabalho do GitHub Actions adulterado não é necessariamente uma dependência vulnerável. Uma carga útil de shell codificada em base64 dentro de .github/workflows pode não constar em um SBOM. Um token OIDC roubado não é um CVE. Um pacote malicioso pode apresentar proveniência válida se o invasor tiver comprometido o pipeline que o produziu. Um mantenedor legítimo pode publicar uma versão maliciosa se a fonte a partir da qual ele publica já tiver sido adulterada.

A defesa da cadeia de suprimentos precisa ir além do produto final. As equipes precisam de controles que verifiquem:

• comportamento do pacote antes da instalação
• alterações no código-fonte e comparações entre versões
• integridade do fluxo de trabalho e ganchos de execução durante a compilação
• Permissões de CI/CD e comportamento do executor
• proveniência e contexto de atestado
• escopo de identidade na nuvem
• Exposição das credenciais de mantenedores e desenvolvedores
• sinais de vulnerabilidade e comprometimento pós-publicação

O registro é apenas uma camada. O sistema de compilação é agora o foco principal.

Mitigação

Considere o Shai-Hulud e o Megalodon como um motivo para auditar e fortalecer o fluxo de entrega de software, especialmente se você não tiver revisado sua exposição a CI/CD desde maio de 2026.

1. Pesquise seus repositórios

Pesquise nos repositórios e forks do GitHub por:

• Nomes dos fluxos de trabalho do SysDiag e do Optimize-Build
• o endereço C2 216.126.225.129
• Execução de `base64 -d | bash`
• acionamentos inesperados do workflow_dispatch
• token de identificação não identificado: permissões de gravação
• confirmações no fluxo de trabalho provenientes de identidades desconhecidas que parecem ser de bots
• pushes diretos que alteraram o repositório .github/workflows

Preste atenção especial às mudanças no fluxo de trabalho por volta de 18 de maio de 2026, especialmente às que contornaram a revisão das solicitações de pull.

2. Bloquear e revisar saídas conhecidas

Bloqueie o tráfego de saída dos executores do CI para 216.126.225.129:8443 e analise os registros históricos do proxy, do firewall e do NetFlow para conexões provenientes de sistemas de compilação ou executores auto-hospedados. Bloquear o endereço IP não é uma defesa completa, já que a infraestrutura muda rapidamente, mas é útil para análise histórica e limpeza imediata.

3. Alternar os segredos expostos

Se um fluxo de trabalho suspeito foi executado, considere que o ambiente do executor foi comprometido. Priorize a rotação das PATs do GitHub e dos tokens de acesso detalhados, chaves de implantação, segredos do Actions, credenciais de aplicativos do GitHub, tokens de publicação do npm e do PyPI, credenciais do registro do Docker, chaves privadas SSH, credenciais da AWS, do Google Cloud e do Azure, configurações do Kubernetes, credenciais do Terraform, tokens do Vault e relações de confiança OIDC vinculadas aos fluxos de trabalho afetados.

Uma advertência antes de revogar: algumas cargas maliciosas da família Shai-Hulud incluíram um mecanismo de segurança destrutivo vinculado à revogação de tokens. Esse comportamento não foi confirmado como uma característica das cargas maliciosas do Megalodon, mas, em qualquer host que você suspeite estar infectado, isole-o e crie uma imagem do sistema, além de preservar os registros de infraestrutura de nuvem (CI), o histórico de execução de fluxos de trabalho e os eventos de auditoria, antes de revogar as credenciais.

4. Colocar em quarentena versões de pacotes conhecidas como comprometidas

Se você utiliza o @tiledesk/tiledesk-server, verifique se há versões de 2.18.6 a 2.18.12. Caso alguma delas tenha sido instalada, compilada ou implantada, analise os ambientes afetados e atualize os segredos disponíveis durante a compilação ou em tempo de execução. Fixe a versão na última versão verificada como livre de falhas, a 2.18.5, e valide os arquivos de bloqueio.

5. Fortalecer a confiança na OIDC

Não permita confiança ampla no nível do repositório para funções sensíveis na nuvem. Sempre que possível, restrinja a confiança OIDC por repositório, ramificação, tag, ambiente, arquivo de fluxo de trabalho, público-alvo e caminho de lançamento. Uma condição como “sub restrito a repo:org/name:ref:refs/heads/main” impede que um fluxo de trabalho malicioso em uma ramificação secundária gere credenciais de produção.

Analise todos os fluxos de trabalho que solicitam:

permissions:
id-token: write

Remova-o, a menos que o fluxo de trabalho tenha uma necessidade documentada de solicitar um token.

6. Exigir revisão para alterações no fluxo de trabalho

Trate o .github/workflows como código sensível em termos de segurança. Utilize a aprovação dos CODEOWNERS para arquivos de workflow, proteção de ramificação, revisão obrigatória de pull requests, commits assinados quando apropriado, permissões padrão de somente leitura para Actions, ações de terceiros fixadas a SHA de commits em vez de tags mutáveis, saída restrita dos runners e runners separados para workflows de lançamento sensíveis. Um arquivo de workflow pode ser tão poderoso quanto o código de implantação em produção. Não deve ser mais fácil alterá-lo.

Detecção

Nenhum resultado isolado de varredura comprova a exposição ao Shai-Hulud ou ao Megalodon. As evidências relevantes estão espalhadas pelo histórico do repositório, arquivos de fluxo de trabalho, logs do executor de CI, logs de rede, eventos de auditoria do GitHub, logs de identidade na nuvem e arquivos de bloqueio de pacotes. Os sinais comportamentais também perduram mais do que os indicadores atômicos, pois o operador realiza a rotação da infraestrutura.

Entre os sinais úteis estão:

• alterações inesperadas em .github/workflows
• Execução de shell decodificada em base64 dentro da CI
• fluxos de trabalho “workflow_dispatch” novos ou sem explicação
• fluxos de trabalho que solicitam um token de identificação: gravação sem um motivo claro
• envio direto para os ramos padrão
• nomes de autores desconhecidos que parecem ter sido gerados por bots e datas de commit falsificadas
• tráfego de saída do CI Runner para 216.126.225.129
• novas chaves de implantação, autorizações OAuth ou instalações de aplicativos do GitHub
• suposições incomuns sobre funções na nuvem a partir das identidades do GitHub Actions
• divulgar as publicações logo após alterações suspeitas no fluxo de trabalho
• versões inesperadas do npm ou do PyPI nos arquivos de bloqueio durante o período de exposição

Exemplos de termos de pesquisa no GitHub:

"216.126.225.129"
"SysDiag"
"Optimize-Build"
"base64 -d | bash"
"id-token: write"

Exemplo de pesquisa de fluxo de trabalho local:

grep -R "216\.126\.225\.129\|SysDiag\|Optimize-Build\|base64 -d" .github/workflows/ 2>/dev/null

Essas verificações são um ponto de partida, não um atestado de boa saúde.

Lista de verificação de medidas corretivas priorizadas

Revisar repositórios: analise as alterações nos fluxos de trabalho do GitHub Actions, especialmente aquelas ocorridas por volta de 18 de maio de 2026.

Pesquise por IOCs: procure por SysDiag, Optimize-Build, execução suspeita de base64 e o endereço C2 relatado.

Preservar registros: mantenha os registros de execução do fluxo de trabalho, os registros de auditoria do GitHub, os arquivos de bloqueio de pacotes e os artefatos de compilação antes da limpeza.

Rotação de segredos: Faça a rotação das credenciais expostas a qualquer ambiente de execução suspeito.

Reforçar o OIDC: Delimitar as políticas de confiança na nuvem para fluxos de trabalho, filiais, tags ou ambientes específicos.

Restringir alterações no fluxo de trabalho: exigir revisão de pull requests e aprovação dos CODEOWNERS para .github/workflows.

Análise da aceitação de pacotes: Verifique se versões de pacotes com vulnerabilidades conhecidas foram instaladas em seu ambiente.

Reforçar o CI/CD: Vincule as ações de terceiros aos SHAs dos commits, restrinja o tráfego de saída do executor e minimize as permissões padrão do fluxo de trabalho.

Inspecionar os pontos de acesso dos desenvolvedores: Trate as estações de trabalho dos desenvolvedores como parte da cadeia de suprimentos, especialmente nos casos em que os responsáveis pela manutenção instalaram pacotes afetados ou mantinham credenciais armazenadas localmente.

Por que isso vai além de uma simples campanha

O que importa em relação ao Shai-Hulud e ao Megalodon não é apenas a escala. É a direção do movimento. Os invasores estão avançando rio acima, partindo de pontos vulneráveis em direção aos sistemas de confiança que se encontram atrás deles:

• credenciais do mantenedor
• pontos de conexão para desenvolvedores
• Executores de CI/CD
• Fluxos de trabalho do GitHub Actions
• Identidades OIDC
• automação da publicação de pacotes
• sistemas de proveniência e assinatura
• funções de implantação em nuvem

Isso muda o significado da segurança de código aberto. Não basta mais verificar um pacote depois que ele entra no seu ambiente. É preciso saber de onde ele veio, como foi compilado, se o processo de compilação era confiável, o que mudou em relação à versão anterior, se o pacote realiza alguma ação suspeita durante a instalação ou a compilação, se o editor ou o repositório foi comprometido e se o componente continuará recebendo correções de segurança após a implantação.

Esse é o problema que o SecureChain foi desenvolvido para resolver. O SecureChain oferece às organizações uma fonte verificada de componentes de código aberto, com triagem de malware, inspeção no nível do código-fonte, proveniência e correção contínua de vulnerabilidades CVE ao longo de todo o ciclo de vida do componente. Para novas versões de pacotes, ele foi projetado para analisar as diferenças entre versões e sinalizar alterações suspeitas antes que sejam consideradas confiáveis nas etapas posteriores, incluindo ganchos de execução durante a compilação, cargas ofuscadas, caminhos de execução ocultos e comportamentos de exfiltração.

Em um cenário do tipo Megalodon, isso é importante porque o pacote pode ser publicado pelo mantenedor legítimo a partir da conta legítima. A alteração maliciosa não está no limite do registro. Ela está no código-fonte corrompido que chegou ao registro.

O Shai-Hulud e o Megalodon nos lembram que a cadeia de suprimentos de software não se resume apenas ao código que você instala. Trata-se do sistema que o selecionou, o desenvolveu, o assinou, o publicou e continua a mantê-lo. Esse sistema agora precisa ser protegido da mesma forma que a infraestrutura de produção.

Conheça o SecureChain →

Perguntas frequentes

O Megalodon é a mesma coisa que o Shai-Hulud?

Não. Shai-Hulud se refere a uma família de ataques à cadeia de suprimentos que se propagam automaticamente, especialmente no npm e no PyPI. Megalodon foi uma campanha em massa de injeção de fluxos de trabalho no GitHub Actions, ocorrida em 18 de maio de 2026. Eles estão relacionados em termos de momento e técnicas utilizadas, mas não há confirmação de que Megalodon seja a mesma operação ou o mesmo operador.

O Megalodon foi mesmo desenvolvido pela TeamPCP?

Não. O TeamPCP está fortemente ligado às atividades do Shai-Hulud, e o Megalodon apresenta semelhanças com esse estilo de ataque, mas não há confirmação de uma atribuição direta. Os pesquisadores que analisaram o código do Megalodon avaliam que se trata, muito provavelmente, de um imitador. Os defensores devem se concentrar na técnica, e não na identificação do agente.

A proveniência do SLSA me protege contra isso?

Não por si só. O Mini Shai-Hulud demonstrou que pacotes maliciosos podem conter uma proveniência válida do SLSA Build Level 3 caso o invasor comprometa o pipeline de compilação. A proveniência ajuda a comprovar a origem e a integridade da compilação. Ela não comprova que o código era seguro.

O OIDC protege o CI/CD contra o roubo de credenciais?

O OIDC é mais seguro do que armazenar chaves de nuvem de longa duração na infraestrutura de integração (CI), mas ainda assim requer um escopo bem definido. Se um fluxo de trabalho mal-intencionado puder solicitar o `id-token: write` e a política de confiança na nuvem for muito ampla, um invasor poderá gerar credenciais de curta duração por meio da identidade do pipeline confiável.

Por que a autenticação de dois fatores (2FA) e a assinatura não impediram o ataque ao Tiledesk?

Isso porque o invasor não precisou comprometer a conta do npm. O Megalodon corrompeu o repositório de código-fonte, e o mantenedor legítimo publicou a partir desse código-fonte corrompido. A autenticação de dois fatores (2FA) e a assinatura protegem o evento de publicação; elas não garantem que o código-fonte publicado estivesse intacto.

Não administro muitos repositórios no GitHub. Ainda assim, estou vulnerável?

É possível. Mesmo que você não tenha sido afetado diretamente, suas dependências a montante podem ter sido compiladas ou publicadas a partir de repositórios comprometidos. Qualquer organização que utilize pacotes de código aberto herda algum risco dos pipelines de compilação por trás desses pacotes.

Qual é a solução mais importante a longo prazo?

Trate a CI/CD como infraestrutura de produção. Restrinja alterações no fluxo de trabalho, defina rigorosamente o escopo do OIDC, monitore o comportamento dos executores, reduza o uso de segredos na CI, inspecione os pacotes antes da instalação e pare de considerar a proveniência ou um editor conhecido como um indicador absoluto de segurança.

Fontes

• Cloud Security Alliance – “Shai-Hulud/Megalodon: Um ataque em duas etapas à cadeia de suprimentos de desenvolvedores de IA”
• Protos Labs – “A campanha Shai-Hulud da TeamPCP e a onda de imitações”
• SafeDep – Análise da campanha Megalodon (conjunto de dados de commit, cascata do Tiledesk)
• OX Security – Análise de atribuição dos imitadores do Megalodon e do Shai-Hulud
• StepSecurity – Análise da exfiltração de segredos no Megalodon GitHub Actions; Análise do Mini Shai-Hulud / TanStack
• Tenable – Mini Shai-Hulud CVE-2026-45321: Perguntas frequentes
• Hudson Rock – Análise da causa raiz do infostealer Megalodon
• Unidade 42 (Palo Alto Networks) – relatório original sobre o worm Shai-Hulud, setembro de 2025
• The Hacker News – Cobertura da campanha do Megalodon e do Mini Shai-Hulud
• Socket – invalidação de tokens do npm e análise da campanha Shai-Hulud