Olá a todos!
Fico deprimido. Só não acerto no numero do euromilhões. Há duas semanas escrevi sobre o Megalodon e os 5.500 repositórios envenenados num domingo à tarde, e antes disso sobre a extensão de VS Code que pôs o próprio GitHub de joelhos. Disse-vos, com aquela ponta de cansaço de quem já viu o filme demasiadas vezes, que isto não ia parar. Que o carrossel ia continuar a girar, e que a única coisa que mudava era o nome no bilhete de entrada. Pois bem, o carrossel deu mais uma volta. E desta vez quem subiu para o cavalinho de plástico foi nada mais nada menos do que a Red Hat.
No dia 1 de junho de 2026, alguém publicou versões maliciosas de 32 pacotes oficiais no scope @redhat-cloud-services do npm. E quando digo oficiais, é mesmo oficiais. Não estamos a falar de typosquatting, não estamos a falar de alguém que registou @redhat-cloud-servic3s à espera que um developer com sono escrevesse mal o nome. Estamos a falar do namespace verdadeiro, o legítimo, aquele em que vocês confiam sem pestanejar porque tem o nome da Red Hat colado. Foi esse que foi sequestrado. E a parte que me dá vontade de atirar o café contra a parede: tudo isto aconteceu numa janela de 72 segundos. Setenta e dois segundos. O tempo que vocês demoram a aquecer as sobras de ontem no micro-ondas.
Vamos por partes, porque há aqui muito para desempacotar e eu sei que alguns de vocês ainda estão a tentar perceber se foram apanhados.
O que é que aconteceu, em português que se entenda
A campanha tem nome, como agora é moda dar nome a estas coisas para venderem melhor nos relatórios. Chama-se “Miasma: The Spreading Blight”, e é uma variante de uma família de malware chamada Mini Shai-Hulud. Os mais atentos vão lembrar-se que o Shai-Hulud original já tinha andado a fazer das suas no ecossistema npm há uns meses. A diferença agora é que a ferramenta foi tornada pública. Foi posta lá, à disposição de quem a quisesse usar, por um grupo chamado TeamPCP. E quando se democratiza uma arma destas, o resultado é exatamente este: qualquer um pega nela, muda-lhe a roupagem, e dá mais uma volta no carrossel.
Os números, para terem a noção da escala. Foram 32 pacotes comprometidos, com 96 versões maliciosas publicadas ao todo. Esses pacotes somavam, conforme a fonte que olharem, entre 80 mil e 117 mil downloads por semana. A ReversingLabs aponta para qualquer coisa como 9,8 milhões de downloads totais ao longo da vida destes pacotes. Não são bibliotecas obscuras. São componentes de UI, clientes de API, ferramentas de build, utilitários de configuração e até servidores MCP do ecossistema da Hybrid Cloud Console da Red Hat. Coisas que vivem no coração de pipelines de produção.
E agora a parte que separa este ataque dos amadores. Cada pacote envenenado trazia um script preinstall no package.json. Para os que não vivem com isto todos os dias: um preinstall é um pedaço de código que corre automaticamente, sozinho, no momento exato em que vocês fazem npm install. Antes de qualquer linha do vosso código arrancar. Antes de vocês terem a mais pequena pista de que algo está errado. Vocês escrevem npm install, carregam no Enter, e nesse preciso instante um payload ofuscado de 4,2 MB começa a correr na vossa máquina à procura de tudo o que vos possa custar caro.
A ironia que dói: a segurança que era para vos proteger foi a porta de entrada
Aqui é onde eu preciso que vocês prestem mesmo atenção, porque é a lição mais importante de todas e é também a mais incómoda.
Os atacantes não usaram um token roubado do npm. Isso seria quase banal a esta altura. O que eles fizeram foi muito mais elegante e muito mais perturbador. Comprometeram a conta de GitHub de um developer da Red Hat, e a partir daí injetaram commits órfãos diretamente nos repositórios da organização RedHatInsights. Esses commits traziam um ficheiro de workflow malicioso, um ci.yaml, e foi por aí que a coisa toda se desenrolou.
O workflow, quando corria, instalava o Bun e executava o payload. E em vez de andar a roubar passwords de longa duração, usava a permissão id-token: write para pedir ao próprio GitHub um token OIDC de curta duração. Com esse token, autenticava-se diretamente no endpoint de trusted publishing do npm e publicava as versões backdoored. Tudo limpinho. Tudo verificado. Tudo assinado.
Estão a ver a piada negra? O trusted publishing via OIDC foi inventado precisamente para acabar com os tokens de longa duração que andavam por aí esquecidos em ficheiros de configuração à espera de serem roubados. Era a solução. Era o upgrade de segurança. E foi exatamente esse mecanismo que se transformou num sinal de confiança enganador, num carimbo de autenticidade que os atacantes usaram para fazer passar veneno por remédio. Já tínhamos visto isto nos casos da TanStack e da Bitwarden. O padrão é sempre o mesmo: o pipeline de CI/CD deixou de ser a fábrica e passou a ser a superfície de ataque.
Eu já vos disse isto de mil maneiras diferentes e vou voltar a dizer porque parece que não entra: não existe segurança que se compre num botão. Cada camada de automação e de confiança que vocês adicionam é uma camada que alguém, mais cedo ou mais tarde, vai aprender a virar contra vocês. A conveniência tem sempre um preço, e o preço costuma vir com fatura atrasada e juros.
Como é que o developer foi apanhado
Há um detalhe nesta história que me arrepiou e que quase ninguém está a sublinhar com a força devida. A Whiteintel, uma empresa de threat intelligence, diz ter detetado credenciais de GitHub e cookies de sessão de um colaborador da Red Hat em logs de infostealers já em 13 de abril e 15 de maio de 2026. Ou seja, semanas antes do ataque, as chaves daquele developer já andavam à venda no submundo, despejadas por algum infostealer que lhe entrou na máquina sabe-se lá como. Um anexo, uma extensão, um instalador de qualquer coisa baixado num momento de pressa.
Isto diz-vos uma coisa fundamental. A máquina de um único developer, comprometida por um vulgar infostealer, foi suficiente para pôr em causa a cadeia de fornecimento de uma das maiores empresas de software open source do planeta. Não foi preciso um exploit de dia zero mirabolante. Não foi preciso um grupo patrocinado por um estado-nação com orçamento ilimitado. Foi preciso uma sessão roubada e paciência. O elo mais fraco continua a ser, e vai continuar a ser por muito tempo, o portátil de uma pessoa.
Estás afetado? Vê isto antes de fazer mais alguma coisa
Vamos ao que interessa para quem está com o coração nas mãos. Estás potencialmente afetado se correste npm install no dia 1 de junho de 2026, sobretudo na janela entre cerca das 10:54 e as 10:56 UTC, e se algum destes 32 pacotes aparece na tua árvore de dependências. E atenção: pode ser uma dependência direta tua, mas também pode ser uma dependência transitiva, escondida três níveis abaixo, daquelas que ninguém olha porque o package-lock.json tem dez mil linhas e a vida é curta.
Vai aos teus lockfiles. Faz grep ao scope @redhat-cloud-services. Olha para as versões. Cruza com as listas de IOCs que a Aikido, a Wiz, a ReversingLabs e a própria Red Hat já publicaram. Não confies na memória, não confies no “acho que não usamos isso”. Confirma com os ficheiros à frente dos olhos.
E se encontrares qualquer coisa, aqui vai o aviso que pode salvar-te a pele e que poucos estão a dar com a clareza necessária: isola a máquina afetada da rede ANTES de começares a revogar fosse o que for. Esta variante do malware traz um mecanismo de dead-man switch. Se começares a revogar tokens com a máquina ainda ligada e o bicho a observar, podes despoletar comportamento destrutivo. Primeiro tira o cabo de rede, ou desliga o Wi-Fi, e só depois começas a limpeza.
Quanto à limpeza propriamente dita, parte do princípio de que tudo o que aquela máquina tocava está queimado. Tokens de GitHub, tokens do npm, credenciais de cloud da AWS, GCP e Azure, tokens de service accounts de Kubernetes, chaves SSH, segredos de CI/CD. Tudo. Roda tudo, parte do zero, e dorme melhor.
A boa notícia, que existe e é importante dar
Sejamos justos, porque eu critico muito mas reconheço o que está bem feito. A Red Hat reagiu depressa. As versões maliciosas foram removidas do npm pouco depois da divulgação, e segundo o boletim oficial RHSB-2026-006, a análise preliminar indica que os builds de produtos da Red Hat não incorporaram as versões comprometidas. Por outras palavras: a posição da empresa, à hora a que escrevo, é a de que os clientes finais dos produtos Red Hat não precisam de fazer nada. O estrago, do que se sabe até agora, ficou contido no ecossistema npm a montante e nos developers que puxaram os pacotes diretamente.
Isto é a diferença entre uma empresa que tem processos de tracking de dependências e build systems auditáveis, e uma que não tem. Eles conseguiram, num espaço de horas, dizer com alguma confiança o que tinha e o que não tinha entrado nos builds. Vocês, na vossa empresa, conseguiriam responder à mesma pergunta com a mesma rapidez? Se a resposta é “não sei”, já sabem qual é o trabalho de casa desta semana.
O que é que vocês levam daqui para casa
Eu sei que estes posts começam a soar a disco riscado, e é exatamente esse o ponto. A repetição é a mensagem. Estamos em junho e já perdi a conta às campanhas deste ano: Aqua Trivy, Checkmarx KICS, Bitwarden, SAP, TanStack, o próprio GitHub, o Nx Console, o Megalodon, e agora a Red Hat. Isto não são incidentes isolados. Isto é o estado normal das coisas. O novo normal é vocês não poderem confiar cegamente em nada que entre na vossa máquina vindo de um registo público, por mais respeitável que seja o nome colado ao pacote.
Então o que fazer, em concreto, sem cair no fatalismo. Primeiro, desliguem os scripts de lifecycle por defeito. O npm install --ignore-scripts devia ser o vosso padrão mental, e só abrir exceção quando souberem exatamente porque é que aquele pacote precisa de correr código na instalação. Segundo, fixem versões. Nada de ^ nem de ~ em produção. Versões exatas, lockfiles commitados, e atualizações deliberadas em vez de automáticas. Terceiro, ponham uma quarentena temporal nas dependências. Não puxem a versão que saiu há cinco minutos. Deixem-na cozer uns dias, deem tempo a que a comunidade e os scanners apanhem o que houver para apanhar. Setenta e dois segundos foi o que estes pacotes demoraram a ser envenenados, mas demoraram horas a ser detetados. Esse intervalo é a vossa zona de perigo.
E por fim, a minha cassete do costume, aquela que vocês já sabem de cor: tragam o que for crítico para mais perto de casa. Espelhem os pacotes de que dependem num registo interno que vocês controlam. Não corram pipelines de produção contra o npm público em tempo real. Tenham um inventário, um SBOM a sério, que vos diga em trinta segundos o que é que está dentro do vosso software. Porque quando o próximo carrossel der a volta, e vai dar, a única coisa que vos vai distinguir de quem entra em pânico é saberem, com ficheiros à frente dos olhos, o que é vosso e o que é de casa alheia.
A Red Hat safou-se relativamente bem desta. A pergunta que vos deixo, e que vos peço que levem a sério em vez de a despacharem, é simples: e vocês, safavam-se?
Fiquem bem, fiquem atentos, e por amor da santa, leiam os vossos lockfiles.
Higgs