Bitwarden CLI teve pacote npm adulterado em campanha contra cadeia de suprimentos

Versão @bitwarden/cli@2026.4.0 executava código por gancho preinstall, coletava segredos de ambientes locais e CI/CD e tentava reutilizar tokens para contaminar outros pacotes e fluxos do GitHub Actions.

Componente	Pacote npm @bitwarden/cli@2026.4.0, com código malicioso incluído no arquivo bw1.js e distribuído pelo caminho de entrega npm da CLI do Bitwarden.
Vetor	Execução automática por gancho preinstall após instalação do pacote; a publicação maliciosa foi associada ao comprometimento de um fluxo GitHub Actions ligado ao mecanismo de distribuição.
Impacto	Coleta de tokens GitHub e npm, arquivos .ssh, arquivos .env, histórico de shell, segredos de GitHub Actions, credenciais de nuvem e configurações de ferramentas de codificação com IA.
Prioridade	Localizar instalações feitas entre 17h57 e 19h30 ET de 22 de abril de 2026, remover a versão 2026.4.0, rotacionar segredos acessíveis e revisar repositórios, workflows e publicações npm.
Versões	@bitwarden/cli@2026.4.0 foi a versão afetada; @bitwarden/cli@2026.4.1 foi disponibilizada como relançamento seguro baseado na versão 2026.3.0.
Artefatos	Arquivo bw1.js, domínio audit.checkmarx[.]cx, fluxo checkmarx/ast-github-action, string Shai-Hulud: The Third Coming e repositórios GitHub usados como canal alternativo de exfiltração.
Escopo	O pacote malicioso ficou disponível por uma janela limitada e teve estimativa de 334 downloads; não há evidência relatada de acesso a dados de cofres de usuários finais ou comprometimento de sistemas de produção.

Resumo técnico

A versão @bitwarden/cli@2026.4.0 do pacote npm da interface de linha de comando do Bitwarden foi distribuída com um componente malicioso durante uma janela restrita em 22 de abril de 2026, entre 17h57 e 19h30 no horário ET. O problema ficou concentrado no mecanismo de entrega via npm da CLI, não na integridade do código legítimo da aplicação nem nos cofres de senhas armazenados pelo serviço. A versão afetada incluiu o arquivo bw1.js, acionado durante a instalação por um gancho preinstall, o que tornava a simples instalação do pacote suficiente para iniciar a coleta de credenciais no ambiente do desenvolvedor ou em pipelines automatizados.

O incidente se encaixa em uma campanha de cadeia de suprimentos com abuso de GitHub Actions, tokens de publicação e segredos presentes em ambientes de desenvolvimento. O pacote adulterado buscava credenciais locais, credenciais de CI/CD, tokens GitHub, tokens npm, arquivos .ssh, arquivos .env, histórico de shell, segredos de GitHub Actions e credenciais de nuvem. O fluxo descrito também incluía coleta de configurações de ferramentas de codificação com IA, incluindo Claude, Kiro, Cursor, Codex CLI e Aider. A exfiltração usava criptografia AES-256-GCM e tentava enviar os dados ao domínio audit.checkmarx[.]cx, com uso de repositórios GitHub como alternativa caso o canal principal não estivesse disponível.

A relevância operacional do caso não está apenas na presença de um pacote trojanizado. Em ambientes modernos, uma CLI instalada por um desenvolvedor pode ter acesso indireto a múltiplos repositórios, credenciais de publicação, caches de autenticação, variáveis de ambiente e workflows com permissões amplas. Quando um token GitHub válido é recuperado, o código malicioso pode tentar criar ou alterar workflows para capturar segredos disponíveis em novas execuções. Quando credenciais npm são encontradas, o mesmo caminho pode permitir a publicação de versões adulteradas em outros pacotes alcançáveis pelo token roubado. Isso transforma um endpoint individual ou uma etapa de build em ponto de entrada para propagação dentro da cadeia de desenvolvimento.

Fluxo técnico

O ponto de execução principal foi o gancho preinstall, um mecanismo do ecossistema npm que permite executar scripts antes da instalação final de um pacote. Em uma estáção de trabalho, isso significa execução no contexto do usuário que instalou a dependência. Em um pipeline, a execução ocorre com as permissões e variáveis disponíveis ao job de CI. A versão 2026.4.0 carregava o arquivo bw1.js, responsável por acionar a rotina de coleta. Como o script roda antes de a aplicação ser usada, a exposição não dependia de autenticação posterior na CLI do Bitwarden; bastava que o pacote fosse baixado e que scripts de instalação estivessem habilitados.

A coleta descrita mirava seis superfícies principais de segredo: material local de desenvolvedores, credenciais npm, tokens GitHub, segredos de GitHub Actions, credenciais de provedores de nuvem e configurações de ferramentas de codificação com IA. A busca por arquivos .env amplia a exposição para chaves de API, URLs internas, tokens temporários e credenciais de banco ou serviços usados em desenvolvimento. A leitura de .ssh e histórico de shell pode revelar chaves privadas, comandos recentes, destinos internos e nomes de infraestrutura. Em CI/CD, variáveis de ambiente e segredos injetados por workflows podem incluir tokens de publicação, chaves de deploy e credenciais com alcance superior ao necessário para a etapa executada.

Quando tokens GitHub eram encontrados, o código podia reutilizá-los para injetar workflows maliciosos em repositórios acessíveis. Esse detalhe muda o perfil de risco: a execução inicial não fica limitada ao host onde o pacote foi instalado. Um token com permissão de escrita em repositórios pode permitir a criação de arquivos de workflow, disparo de execuções e captura de segredos expostos a esses workflows. O contexto também descreve um canal de comando e controle baseado em commits GitHub com entrega de comandos assinados por RSA, além de exfiltração autenticada e criptografada. Esses elementos indicam uma operação desenhada para sobreviver à perda de um único canal e para aproveitar a confiança concedida a plataformas de desenvolvimento.

A exfiltração tinha como destino primário audit.checkmarx[.]cx, domínio que imita a marca Checkmarx, e podia recorrer a repositórios GitHub como canal alternativo. O uso de GitHub para armazenar dados roubados reduz a visibilidade de algumas ferramentas de segurança, porque tráfego para a plataforma pode ser comum em ambientes de engenharia. O contexto também descreve repositórios criados em contas de vítimas com nomes inspirados em Dune e a string Shai-Hulud: The Third Coming dentro do pacote. Há indicação de conexão com o ecossistema de uma campanha anterior, mas as diferenças operacionais impedem tratar a atribuição como conclusão fechada. O nome TeamPCP aparece como suspeita, não como identificação confirmada.

Superfície afetada

A superfície exposta inclui qualquer ambiente que tenha instalado @bitwarden/cli@2026.4.0 a partir do npm durante a janela informada. A instalação em estáções de trabalho de desenvolvedores é crítica porque essas máquinas costumam concentrar tokens de repositório, chaves SSH, credenciais de nuvem, arquivos de ambiente e histórico operacional. A instalação em pipelines é ainda mais sensível quando o job recebe segredos de publicação, permissões para alterar repositórios ou acesso a ambientes de build compartilhados. Usuários que não baixaram a versão pelo npm no intervalo afetado não entram no escopo descrito.

O caso também afeta equipes que confiam em publicações npm automatizadas ou em GitHub Actions com permissões amplas. O repositório do Bitwarden usava checkmarx/ast-github-action, artefato comprometido na campanha relacionada. O caminho de publicação malicioso foi associado ao mecanismo de distribuição npm e ao uso de workflow adulterado, incluindo a possibilidade de comprometimento mesmo em cenários com publicação confiável do npm. A presença de uma estimativa de 334 downloads delimita o volume observado da versão afetada, mas não reduz a necessidade de resposta em ambientes que tenham baixado o pacote, porque um único token com escopo amplo pode abrir acesso a vários repositórios e pacotes.

O fornecedor indicou ausência de evidência de acesso a dados de cofres de usuários finais, de risco aos cofres armazenados, de comprometimento de dados de produção ou de sistemas de produção. Essa distinção é importante para a contenção: o foco de resposta deve ficar em segredos de desenvolvimento, credenciais de CI/CD, permissões de repositório e tokens de publicação, não em presumir comprometimento de cofres de usuários sem evidência. Ainda assim, credenciais roubadas de ambientes de engenharia podem ser suficientes para novas publicações maliciosas, alterações em workflows e acessos laterais dentro da cadeia de desenvolvimento se não forem invalidadas rapidamente.

• Instalações de @bitwarden/cli@2026.4.0 feitas via npm entre 17h57 e 19h30 ET em 22 de abril de 2026.
• Estáções de desenvolvedores com arquivos .env, diretórios .ssh, histórico de shell, tokens npm ou sessões GitHub autenticadas.
• Pipelines GitHub Actions com segredos injetados em jobs, permissões de escrita em repositórios ou credenciais de publicação npm.
• Ambientes que usam Claude, Kiro, Cursor, Codex CLI ou Aider com configurações autenticadas acessíveis ao usuário ou ao processo de build.

Hunting e telemetria

A primeira linha de investigação deve confirmar se a versão 2026.4.0 foi baixada, instalada ou armazenada em cache. Registros de gerenciadores de pacote, caches npm, lockfiles, imagens de build e logs de CI podem mostrar o momento da resolução da dependência. Como a execução ocorreu por preinstall, a ausência de uso posterior da CLI não elimina exposição. Equipes devem revisar máquinas e runners que processaram a instalação, incluindo ambientes efêmeros, caches persistentes e imagens base usadas em pipelines.

Em endpoints, a investigação deve procurar execução de scripts npm associados a @bitwarden/cli, criação ou leitura incomum de arquivos sensíveis, acesso a .ssh, varredura de arquivos .env e conexões para audit.checkmarx[.]cx. Também é necessário inspecionar histórico de shell e variáveis de ambiente disponíveis no momento da instalação, pois o material exposto pode estar fora do diretório do pacote. Em CI/CD, o foco deve ser o intervalo posterior à instalação: execuções de workflow inesperadas, adição de arquivos em .github/workflows, commits que não correspondem ao processo normal, criação de repositórios incomuns e uso de tokens em horários ou origens anormais.

No GitHub, sinais fortes incluem workflows novos ou alterados sem revisão esperada, commits automatizados com conteúdo que pareça armazenar dados codificados, criação de repositórios com nomes fora do padrão da organização e uso de tokens para ações de publicação ou alteração de permissões. Em npm, equipes devem revisar histórico de publicação de pacotes sob contas que poderiam estar acessíveis ao token comprometido. A busca deve incluir versões publicadas durante e após a janela do incidente, porque a campanha descrita tentava usar credenciais roubadas para republicar payloads em outros pacotes alcançáveis.

• Presença de @bitwarden/cli@2026.4.0, bw1.js ou execução de preinstall relacionada ao pacote em logs locais, CI ou cache npm.
• Conexões, resolução DNS ou tentativas HTTP para audit.checkmarx[.]cx a partir de máquinas de desenvolvedores ou runners.
• Alterações inesperadas em .github/workflows, novos workflows com acesso a segredos ou execuções disparadas por contas sem padrão operacional.
• Publicações npm não planejadas feitas por tokens de desenvolvedores ou contas de automação que tiveram contato com o ambiente afetado.
• Repositórios GitHub recém-criados ou commits incomuns em contas de vítimas, especialmente quando usados como armazenamento de dados.

Mitigação

A resposta deve começar isolando ambientes que instalaram a versão afetada e impedindo nova execução de scripts npm durante a limpeza. A orientação de desabilitar temporariamente scripts de instalação reduz o risco de reexecução acidental enquanto caches, diretórios de dependências e lockfiles são revisados. Depois, a versão 2026.4.0 deve ser removida e substituída por @bitwarden/cli@2026.4.1, publicada como relançamento seguro da 2026.3.0. Essa troca não encerra a resposta, porque o principal risco é a exposição de segredos já acessíveis no momento da instalação.

A rotação deve cobrir todos os segredos que poderiam estar no host ou no job, não apenas tokens explicitamente vistos em logs. Isso inclui tokens GitHub, tokens npm, chaves SSH, credenciais de nuvem, segredos de GitHub Actions, variáveis em .env, credenciais de ferramentas de IA e tokens usados por automações locais. Tokens com permissão de escrita em repositórios ou publicação de pacotes devem ser revogados antes de serem recriados. Em GitHub Actions, workflows precisam ser revisados antes da reativação plena, principalmente se houver commits recentes modificando arquivos sob .github/workflows.

Após a contenção inicial, organizações devem reduzir o alcance de credenciais usadas em desenvolvimento e publicação. Tokens de CI/CD devem ter escopo mínimo, validade curta e separação por repositório ou pacote quando possível. Workflows que publicam no npm precisam de proteção contra alteração não revisada e devem evitar expor segredos a etapas que instalam dependências de origem externa sem controle. Lockfiles e caches devem ser tratados como parte da superfície de resposta, porque podem preservar a versão maliciosa mesmo depois da remoção do pacote do registro. A validação final deve confirmar ausência de novas publicações, ausência de workflows injetados e invalidação de credenciais antigas em todos os sistemas conectados.

• Identificar hosts, runners, imagens e caches que instalaram @bitwarden/cli@2026.4.0 no intervalo afetado.
• Desabilitar temporariamente scripts npm durante a limpeza e remover a versão maliciosa antes de instalar @bitwarden/cli@2026.4.1.
• Revogar e recriar tokens GitHub, npm, credenciais de nuvem, chaves SSH e segredos de GitHub Actions acessíveis aos ambientes expostos.
• Auditar .github/workflows, histórico de commits, publicações npm e criação de repositórios após a instalação do pacote afetado.
• Revisar permissões de workflows e tokens para limitar escrita em repositórios, publicação de pacotes e acesso a segredos durante instalações de dependências.