Pacotes npm ligados ao SAP são comprometidos em ataque de cadeia de suprimentos

Versões maliciosas publicadas em 29 de abril adicionaram gancho preinstall, carregador em setup.mjs, execução via Bun e roubo de tokens, segredos de nuvem e credenciais de ambientes de desenvolvimento.

Componente	Pacotes npm relacionados ao ecossistema SAP de desenvolvimento JavaScript e aplicações em nuvem, incluindo pacotes @cap-js, @cap-js/sqlite e mbt citados no incidente.
Vetor	Publicação de versões adulteradas em 29 de abril de 2026, entre 09:55 UTC e 12:14 UTC, com novo gancho preinstall em package.json que executa setup.mjs durante a instalação.
Impacto	Roubo e exfiltração criptografada de credenciais locais de desenvolvedores, tokens GitHub e npm, segredos do GitHub Actions e segredos de AWS, Azure, GCP e Kubernetes.
Prioridade	Remover versões comprometidas, atualizar para versões seguras publicadas pelos mantenedores, rotacionar tokens e revisar repositórios acessíveis por contas que instalaram os pacotes.
Artefatos	Arquivos e mecanismos citados incluem setup.mjs, execution.js, .claude/settings.json, .vscode/tasks.json, runOn, folderOpen, SessionStart e uso de PowerShell com -ExecutionPolicy Bypass no Windows.
Exfiltração	Dados roubados são cifrados com AES-256-GCM, com chave encapsulada por RSA-4096 usando chave pública embutida, e enviados para repositórios GitHub criados na própria conta da vítima.

Resumo técnico

Uma campanha de cadeia de suprimentos comprometeu pacotes npm associados ao ecossistema SAP de desenvolvimento JavaScript e aplicações em nuvem. As versões suspeitas foram publicadas em 29 de abril de 2026, em uma janela concentrada entre 09:55 UTC e 12:14 UTC, e alteraram o comportamento de instalação esperado desses pacotes. A mudança central foi a inclusão de um gancho preinstall em package.json, responsável por iniciar um arquivo setup.mjs antes que o consumidor do pacote pudesse usar o componente normalmente. Esse detalhe é crítico porque scripts de instalação são executados automaticamente por fluxos de desenvolvimento, pipelines e ambientes de build que confiam no registro npm.

O setup.mjs atua como carregador. Ele baixa um ZIP específico para a plataforma contendo o runtime JavaScript Bun a partir de GitHub Releases, extrai o binário e o executa imediatamente. No Windows, a execução inclui uso de PowerShell com -ExecutionPolicy Bypass, o que aumenta o risco operacional em estáções de desenvolvedores e runners de CI/CD que permitem instalação de dependências sem isolamento forte. O código também segue redirecionamentos HTTP sem validar o destino final, ampliando a superfície para abuso caso a cadeia de download seja desviada ou manipulada.

A carga subsequente, identificada no contexto como execution.js, combina roubo de credenciais, exfiltração criptografada e autopropagação por fluxos de desenvolvimento. O malware busca credenciais locais, tokens GitHub e npm, segredos do GitHub Actions e segredos de nuvem associados a AWS, Azure, GCP e Kubernetes. Também há capacidade de coletar senhas de navegadores como Chrome, Safari, Edge, Brave e Chromium. O material roubado é cifrado antes da saída, com AES-256-GCM para os dados e encapsulamento da chave por RSA-4096 usando uma chave pública embutida no payload.

Fluxo técnico

O fluxo começa quando um ambiente instala uma versão envenenada dos pacotes afetados. Como o vetor está no ciclo de instalação, o acionamento não depende de importação explícita da biblioteca pela aplicação nem de execução manual de uma função vulnerável. A pré-condição prática é que um desenvolvedor, job de CI/CD, processo de release ou ambiente automatizado resolva e instale uma das versões comprometidas. A partir desse ponto, o npm executa o gancho preinstall, que chama setup.mjs e transforma a instalação da dependência em ponto de entrada para código arbitrário controlado pelo atacante.

Depois de iniciado, o carregador obtém o runtime Bun, extrai o binário e o usa para executar a estrutura de roubo e propagação. O uso de um runtime baixado dinamicamente reduz a dependência de ferramentas já existentes no sistema e permite ao payload executar lógica JavaScript em diferentes plataformas. O detalhe do ZIP específico por plataforma indica adaptação a ambientes heterogêneos, como estáções macOS, Windows, Linux e runners usados em automação. Em Windows, o uso de PowerShell com -ExecutionPolicy Bypass deve ser tratado como sinal de execução anômala em contexto de instalação de pacote npm.

A propagação explora o valor operacional de tokens de desenvolvedores. Com credenciais GitHub e npm obtidas no ambiente, a carga tenta injetar workflow malicioso do GitHub Actions em repositórios da vítima, capturar segredos de repositório e publicar novas versões envenenadas de pacotes no registro npm. O mesmo payload também grava artefatos em repositórios acessíveis, incluindo .claude/settings.json para abusar do hook SessionStart do Claude Code e .vscode/tasks.json com runOn definido para folderOpen, fazendo com que a abertura do repositório em VS Code ou Claude Code possa reativar a execução maliciosa.

A exfiltração usa GitHub como canal principal. Em vez de depender apenas de domínio próprio de comando e controle, o malware cria repositórios públicos na conta da vítima com a descrição A Mini Shai-Hulud has Appeared e envia para esses repositórios os dados cifrados. O contexto registra mais de 1.100 repositórios com essa descrição no momento da análise. Esse desenho dificulta bloqueio grosseiro, porque GitHub é infraestrutura legítima em fluxos de desenvolvimento, mas a criação automatizada de repositórios com descrição fixa e conteúdo criptografado oferece sinais defensivos concretos.

Superfície afetada

A superfície principal inclui ambientes que instalaram versões comprometidas dos pacotes npm ligados ao ecossistema SAP, especialmente projetos que usam pacotes @cap-js ou mbt dentro de fluxos de desenvolvimento e entrega. O caso dos três pacotes @cap-js envolve comprometimento da conta RoshniNaveenaS, alteração de workflow em um ramo que não era o principal e uso de token npm OIDC extraído para publicar pacotes maliciosos sem provenance. No caso de mbt, o contexto aponta suspeita de comprometimento do token npm estático cloudmtabot, por um canal ainda não determinado.

Um ponto relevante é a configuração de trusted publishing OIDC para @cap-js/sqlite. A configuração confiava qualquer workflow no repositório cap-js/cds-dbs, em vez de restringir a troca ao workflow canônico release-please.yml no ramo principal. Com permissão id-token: write e referência environment: npm, um push em ramo alternativo podia solicitar um token npm em nome do pacote. Essa condição transforma uma permissão de CI/CD em caminho de publicação, mesmo sem um segredo npm persistente armazenado no repositório.

Também ficam expostos repositórios acessíveis pelas contas comprometidas, estáções de desenvolvimento com navegadores contendo senhas, runners com variáveis de ambiente sensíveis e pipelines com permissões amplas para GitHub Actions. A presença de arquivos .claude/settings.json e .vscode/tasks.json aumenta a superfície para ambientes que usam agentes de codificação e editores integrados ao repositório. A ameaça não termina quando a instalação npm falha ou é removida; repositórios modificados podem carregar mecanismos de reexecução que atingem outros usuários que apenas abrem a pasta.

• Instalações npm que resolveram versões adulteradas publicadas em 29 de abril de 2026 entre 09:55 UTC e 12:14 UTC.
• Repositórios GitHub acessíveis por tokens presentes no host ou no runner afetado.
• Pipelines GitHub Actions com id-token: write, environment: npm e configuração OIDC permissiva.
• Ambientes que usam VS Code ou Claude Code e passam a conter .vscode/tasks.json ou .claude/settings.json inseridos pelo payload.

Hunting e telemetria

A investigação deve começar por inventário de instalações e builds executados na janela de publicação das versões suspeitas. Logs de npm, lockfiles, caches de dependências e históricos de CI/CD podem indicar quais projetos resolveram pacotes afetados. Como o vetor é preinstall, a ausência de uso da biblioteca em runtime não elimina o risco: basta a instalação ter ocorrido. Em endpoints, busque execução de setup.mjs, execução de Bun baixado durante instalação de pacote e chamadas de PowerShell com -ExecutionPolicy Bypass associadas a npm, node, shells de build ou agentes de automação.

No GitHub, a telemetria deve cobrir criação inesperada de repositórios públicos, especialmente aqueles com a descrição A Mini Shai-Hulud has Appeared, commits automatizados contendo blobs cifrados e alterações em múltiplos repositórios feitas por uma mesma conta em curto intervalo. Também é necessário revisar workflows adicionados ou modificados fora do ramo principal, porque a campanha explorou a capacidade de publicar pacotes a partir de um ramo alternativo. Eventos de troca OIDC, solicitações de token npm e publicações sem provenance devem ser correlacionados com commits recentes e permissões id-token: write.

Em repositórios, procure arquivos .claude/settings.json e .vscode/tasks.json recém-adicionados. No caso do VS Code, a chave runOn com valor folderOpen é particularmente sensível, porque permite disparo quando a pasta é aberta. No caso de Claude Code, o abuso citado envolve SessionStart. Esses artefatos devem ser tratados como mecanismo de persistência e propagação, não apenas como configuração de ferramenta. A análise precisa incluir ramificações, forks, pacotes publicados, releases e histórico de automação, porque o incidente usa o ecossistema de desenvolvimento como canal de execução.

• Execução de setup.mjs, execution.js ou Bun baixado durante preinstall de pacote npm.
• Uso de PowerShell com -ExecutionPolicy Bypass iniciado por npm, node, runner de CI/CD ou script de instalação.
• Repositórios públicos criados automaticamente com descrição A Mini Shai-Hulud has Appeared.
• Commits que adicionam .claude/settings.json ou .vscode/tasks.json com runOn e folderOpen.
• Workflows GitHub Actions novos ou alterados fora do ramo principal com permissão id-token: write e referência environment: npm.

Mitigação

A resposta deve priorizar contenção de credenciais, não apenas atualização de dependência. Primeiro, identifique projetos, estáções e runners que instalaram as versões comprometidas. Em seguida, remova as versões envenenadas dos lockfiles e caches, atualize para versões seguras publicadas pelos mantenedores e reexecute builds em ambiente limpo. Como o payload foi desenhado para roubar tokens e segredos, qualquer conta ou pipeline exposto deve passar por rotação de credenciais GitHub, npm, GitHub Actions, AWS, Azure, GCP e Kubernetes, conforme o material presente no host afetado.

A revisão de GitHub precisa incluir repositórios criados pela conta, workflows adicionados, permissões de Actions, segredos de repositório e publicações npm feitas após a janela do incidente. Repositórios com .claude/settings.json ou .vscode/tasks.json inseridos sem justificativa devem ser limpos antes de serem abertos por outros usuários. Também é necessário verificar se pacotes internos ou públicos foram republicados usando tokens roubados, pois a autopropagação descrita usa credenciais npm para empurrar novas versões maliciosas ao registro.

Para reduzir risco recorrente, configure trusted publishing com escopo estrito. O caso de @cap-js/sqlite mostra que confiar qualquer workflow de um repositório é uma condição perigosa quando ramificações alternativos podem acionar troca OIDC. Restrinja o publicador ao workflow esperado, ao ramo principal e ao ambiente correto; remova permissões id-token: write de jobs que não precisam publicar; e valide provenance nas publicações. Em paralelo, monitore criação de repositórios anômalos, eventos OIDC, execuções de scripts de instalação e mudanças em arquivos de configuração de ferramentas de desenvolvimento.

A validação final deve reconstruir o fluxo de exposição: quais hosts instalaram os pacotes, quais tokens estavam presentes, quais repositórios eram acessíveis por esses tokens, quais segredos poderiam ser lidos por workflows e quais pacotes foram publicados depois. Somente depois dessa cadeia ser fechada faz sentido encerrar a contenção. Em ambientes com grande número de desenvolvedores, a abertura de repositórios infectados em VS Code ou Claude Code deve ser bloqueada até que os arquivos de persistência sejam removidos e o histórico de commits seja revisado.

• Atualizar imediatamente para versões seguras que substituem as versões comprometidas.
• Rotacionar tokens GitHub e npm, segredos do GitHub Actions e credenciais de AWS, Azure, GCP e Kubernetes presentes nos ambientes expostos.
• Remover .claude/settings.json e .vscode/tasks.json maliciosos antes de abrir repositórios em ferramentas de desenvolvimento.
• Restringir OIDC trusted publishing ao workflow, ramo e ambiente esperados, evitando confiança ampla em qualquer workflow do repositório.
• Auditar publicações npm, criação de repositórios GitHub e alterações de workflows realizadas por contas que instalaram os pacotes afetados.