Bitwarden CLI é comprometido em ataque de cadeia de suprimentos via Checkmarx; pacote @bitwarden/cli@2026.4.0 ficou malicioso no npm por 90 minutos

A Bitwarden confirmou que sua ferramenta de linha de comando — o pacote @bitwarden/cli, versão 2026.4.0 — foi publicada no npm contendo código malicioso entre 17h57 e 19h30 (horário do leste dos EUA) do dia 22 de abril. O payload, ativado por um preinstall hook, exfiltra tokens, segredos de CI/CD, .env, .ssh e histórico de shell. O cofre de senhas em si não foi tocado, mas o caso reabre o debate sobre como GitHub Actions de terceiros se tornaram o vetor de risco mais explorado em supply chain de software.

O que aconteceu

Em comunicado oficial, a Bitwarden afirmou ter “identificado e contido um pacote malicioso que foi brevemente distribuído via npm como @bitwarden/cli@2026.4.0” durante uma janela de 93 minutos. A versão envenenada chegou aos repositórios públicos pelo pipeline de publicação automatizado da própria empresa, depois que atacantes obtiveram acesso aos seus segredos de CI ao comprometer uma GitHub Action de terceiros amplamente utilizada — a checkmarx/ast-github-action.

Esse mesmo ataque à Checkmarx é o evento-mãe de uma onda de contaminações que atingiu dezenas de repositórios na semana, incluindo bibliotecas com base de usuários significativa. O cluster vem sendo rastreado pela comunidade como uma nova rodada da campanha Shai-Hulud, que já havia sido documentada em campanhas anteriores no ecossistema npm e cuja marca registrada é justamente o uso de Actions e workflows comprometidos para roubar segredos e propagar pacotes maliciosos.

A Bitwarden tem aproximadamente 10 milhões de usuários do aplicativo gerenciador de senhas, mas o impacto direto deste incidente é muito menor: o pacote @bitwarden/cli no npm registra cerca de 250 mil downloads mensais, segundo análise da OX Security. Somente quem baixou ou atualizou a CLI dentro da janela de 93 minutos está exposto.

Como o ataque funciona

O fluxo é elegante na sua maldade. O atacante primeiro comprometeu a action checkmarx/ast-github-action, usada por milhares de projetos no GitHub. A action manipulada exfiltra os segredos do workflow que a invoca — tokens do GitHub, credenciais do npm, chaves de nuvem (AWS/GCP/Azure), variáveis de ambiente arbitrárias. Como Bitwarden usava essa action no pipeline de build da CLI, o token de publicação da @bitwarden no npm foi sequestrado.

De posse do token, o adversário publicou a versão 2026.4.0 com modificações cirúrgicas: a inclusão de um preinstall hook que executa antes mesmo da instalação propriamente dita. Quem rodou npm install @bitwarden/cli ou um npm ci em pipeline com a CLI listada como dependência durante a janela viu o script disparar e empacotar credenciais para envio a domínios de comando-e-controle e a commits em repositórios atacante. A própria Bitwarden depreciou a versão maliciosa do npm e revogou os tokens comprometidos assim que detectou o problema.

“Não há evidência de que dados do cofre dos usuários finais tenham sido acessados ou colocados em risco, nem de comprometimento de dados ou sistemas de produção.”

Bitwarden, em comunicado oficial

Quem é afetado

• Desenvolvedores e DevOps que instalaram ou atualizaram @bitwarden/cli@2026.4.0 entre 17h57 e 19h30 ET de 22 de abril em máquinas locais.
• Pipelines de CI/CD que executaram npm install sem lock file pinning na mesma janela e tinham a CLI como dependência direta ou transitiva.
• Imagens Docker e workers construídos durante a janela e ainda em circulação — o payload pode ter ficado embutido na camada.
• Usuários do app móvel/desktop Bitwarden: não foram afetados. O incidente é exclusivo da CLI distribuída via npm.
• Quem usa a action checkmarx/ast-github-action em seus próprios workflows: pode ter exposto segredos próprios, independentemente do uso de Bitwarden.

Análise

O incidente Bitwarden importa pelo simbolismo, não pelo tamanho. Quando o produto comprometido é justamente um gerenciador de senhas — a peça que os defensores recomendam há uma década como antídoto à reutilização de credenciais — a narrativa de “e agora?” surge naturalmente. Mas, lendo os fatos com calma, o que falhou não foi o produto Bitwarden em si, e sim a cadeia de fornecimento de software que entrega esse produto. A diferença é fundamental.

O padrão Shai-Hulud — atacar uma Action popular, colher segredos, transformar projetos legítimos em vetor — é a evolução natural da estratégia que vimos com event-stream em 2018, com ua-parser-js em 2021, com Codecov em 2021, com o tj-actions/changed-files em março de 2025 e com a rodada anterior do próprio Shai-Hulud em meados de 2025. A cada iteração, o adversário aprende a alcançar mais escala com menos esforço. A Action é o equivalente moderno da biblioteca compartilhada do início dos anos 2000: todo mundo a usa, ninguém a auditou, e quando ela quebra, quebra com efeito dominó.

Para os defensores, o recado é desconfortável mas claro: pinning de versão de pacotes é apenas metade da equação. Sem pinning das próprias Actions por SHA imutável, a postura de segurança permanece dependente da boa-fé do mantenedor. E como a Bitwarden mostrou, mesmo empresas com práticas razoáveis de SDLC continuam vulneráveis quando um único ponto da cadeia é capturado. A boa notícia é que a janela foi curta (93 minutos) e a detecção rápida — mas isso é fruto de monitoramento de publicações no npm, não de prevenção. A prevenção real exige rever toda a árvore de Actions de cada repositório.

Para o usuário final do gerenciador de senhas — incluindo o público brasileiro — o cenário é tranquilizador: cofres não foram acessados, o app móvel/desktop não usa esse pacote npm, e não há indício de qualquer comprometimento de dados de produção. A recomendação “use um password manager” segue válida. O que muda é a régua para quem opera infraestrutura: a confiança em qualquer dependência terceirizada — biblioteca, Action, container base — precisa ser ativa, não presumida.

Recomendações práticas

• Verificar se a CLI da Bitwarden foi instalada ou atualizada na janela 22/04/2026 entre 17h57–19h30 (ET); em caso afirmativo, rotacionar imediatamente todas as credenciais expostas no shell e nos arquivos .env/.ssh daquela máquina.
• Em pipelines de CI/CD, varrer logs por execuções de npm install ou npm ci na mesma janela; se positivo, revogar tokens de GitHub, npm, AWS/GCP/Azure usados pelo job.
• Pinar GitHub Actions de terceiros pelo SHA imutável do commit, não pela tag — uses: org/action@<SHA> em vez de @v1. Tags são mutáveis e podem ser apontadas para um commit malicioso.
• Habilitar npm provenance nos pacotes que sua organização publica e exigir provenance ao consumir pacotes críticos.
• Reconstruir imagens Docker e artefatos buildados na janela suspeita, mesmo sem indício direto de impacto — o custo é baixo, o ganho de garantia é alto.
• Adotar ferramentas de SCA com bloqueio de versões maliciosas conhecidas (Socket, Snyk Advisor, Endor Labs, OX Security) integradas ao pipeline.
• Para o público em geral: continuar usando o app gerenciador de senhas Bitwarden normalmente — o cofre, a sincronização e o app não foram afetados.

Fonte: Forbes — Davey Winder