Olá a todos!
A Socket publicou a 23 de abril de 2026, um alerta de segurança que deve ter chegado ao vosso radar. O @bitwarden/cli versão 2026.4.0 foi comprometido. Código malicioso foi injectado num ficheiro chamado bw1.js que faz parte dos conteúdos do package publicado no npm. O vector de ataque foi uma GitHub Action comprometida no pipeline de CI/CD do Bitwarden — o mesmo vector que está a ser usado pela campanha Checkmarx que a Socket e a Docker vieram a público denunciar há apenas um dia.
Estamos, sem hipérbole, a assistir a um supply chain attack em tempo real contra ferramentas de segurança. Um gestor de passwords. Uma ferramenta de análise de vulnerabilidades de infrastructure-as-code. E a lista vai crescer.
O contexto: A campanha Checkmarx ….
Para perceber o Bitwarden, precisamos de recuar 24 horas e olhar para o que a Socket descobriu primeiro.
A 22 de abril, a Docker alertou a Socket para actividade suspeita no repositório oficial checkmarx/kics no Docker Hub. Quem não conhece o KICS — Keeping Infrastructure as Code Secure — é um scanner open source da Checkmarx amplamente utilizado para analisar ficheiros Terraform, CloudFormation, Kubernetes e outros por vulnerabilidades e más configurações de segurança. É exactamente o tipo de ferramenta que grandes equipas de DevOps e segurança têm nos seus pipelines de CI/CD e confiam implicitamente.
O que a Docker e a Socket encontraram foi um desastre silencioso: os atacantes tinham sobrescrito tags existentes no Docker Hub, incluindo v2.1.20 e alpine, que são as tags que a maioria das equipas usa por serem as “estáveis” e conhecidas. E introduziram uma nova tag v2.1.21 que não corresponde a nenhuma release legítima upstream. O binário do KICS dentro da imagem comprometida tinha sido modificado para incluir capacidades de recolha de dados e exfiltração: gerava um relatório de scan não censurado, cifrava-o, e enviava-o para um endpoint externo.
Pausem um momento para pensar no que isto significa na prática.
O KICS é uma ferramenta que as equipas usam para analisar os seus próprios ficheiros de infraestrutura — ficheiros que frequentemente contêm, mesmo que involuntariamente, credenciais, API keys, connection strings de bases de dados, e segredos de cloud. Equipas que usaram a imagem comprometida do KICS para fazer scans de segurança dos seus próprios repositórios de infraestrutura enviaram, sem saber, um inventário detalhado dos seus segredos para os atacantes. A ironia é demasiado dolorosa para confortavelmente ignorar.
Mas os investigadores da Socket foram mais fundo. E o que encontraram transformou um incidente de Docker Hub num quadro muito maior. As extensões VS Code do Checkmarx — ferramentas que developers instalam no seu editor de código para integração com os scanners da Checkmarx — também foram afectadas. As versões 1.17.0 e 1.19.0 introduziram código capaz de descarregar e executar um addon remoto através do runtime Bun, sem confirmação do utilizador e sem verificação de integridade. A versão 1.18.0 não tinha este comportamento — o que sugere que não foi um erro de desenvolvimento, mas uma injecção deliberada que foi inserida, removida, e reinserida.
O vector partilhado é GitHub Actions. Alguém comprometeu uma ou mais GitHub Actions usadas no pipeline de CI/CD da Checkmarx, e usou esse acesso para introduzir alterações maliciosas nos artefactos publicados. Não precisaram de acesso directo ao Docker Hub, nem ao marketplace de extensões do VS Code, nem ao npm — precisaram apenas de comprometer o passo que faz o build e publica.
E depois chegou o Bitwarden
Um dia depois da história da Checkmarx, a Socket publicou o alerta sobre o Bitwarden CLI. O padrão é idêntico. O vector é o mesmo: uma GitHub Action comprometida no pipeline de CI/CD do Bitwarden foi usada para introduzir código malicioso na versão 2026.4.0 do @bitwarden/cli publicada no npm.
O código malicioso está em bw1.js, um ficheiro incluído nos conteúdos do package. A investigação técnica completa está ainda em curso — a Socket diz que vai publicar os indicadores de compromisso, versões afectadas, e orientações de remediação detalhadas. O que sabemos neste momento é suficiente para que a acção imediata seja necessária.
Vamos ser directos sobre o que o @bitwarden/cli faz, para que a gravidade seja clara.
O Bitwarden CLI é a interface de linha de comandos para o Bitwarden, um dos gestores de passwords open source mais populares do mundo. Com o CLI, podes fazer login na tua conta Bitwarden, listar itens, criar e modificar entradas, exportar vaults, gerar passwords, e integrar o Bitwarden em scripts de automação. Muitas equipas de DevOps usam o Bitwarden CLI exactamente desta forma — para injectar secrets em pipelines de CI/CD, para fazer rotação automática de credenciais, para scripts de onboarding que configuram credenciais de acesso a sistemas.
Agora imagina que instalaste a versão 2026.4.0 do @bitwarden/cli e depois corres bw login e bw list items. Que informação é que esse processo tem acesso? Todo o teu vault do Bitwarden. Todas as passwords. Todas as notas seguras. Todos os items de identidade. Toda a informação de cartão de crédito se guardaste lá. E se és uma equipa de DevOps que usa o Bitwarden CLI num script que corre com acesso a um vault de organização, a superfície de exposição é de toda a organização.
O código malicioso em bw1.js foi injectado precisamente para ter acesso a este contexto.
A anatomia de um ataque de CI/CD que não deixa rasto óbvio
O que torna esta campanha particularmente sofisticada é a escolha do vector: GitHub Actions.
Num modelo de distribuição de software tradicional, para comprometer o que é publicado precisas de acesso às credenciais de publicação directas — a token de npm, as credenciais do Docker Hub, a chave de assinatura. Essas credenciais são guardadas com cuidado, têm acesso restrito, e os seus usos são auditados.
Mas as GitHub Actions são diferentes. São ficheiros YAML no repositório que descrevem os passos de build e publicação, e frequentemente invocam actions de terceiros através de referências como uses: actions/checkout@v4. Cada uses: é uma dependência externa — código que não controlas e que vai correr com os privileges do teu workflow.
O padrão de ataque é assim: identificar projects open source populares que usam GitHub Actions para CI/CD, comprometer uma action de terceiros que esses projects usam (ou encontrar uma action que já estava comprometida), esperar que os maintainers corram o seu workflow de release, e o código malicioso corre durante o build com acesso completo ao ambiente — incluindo as secrets de publicação armazenadas nos GitHub Secrets.
O resultado: o attacker não precisa de compromisso directo das credenciais de publicação. O workflow de release legítimo, corrido pelo maintainer legítimo, é o que faz o trabalho por eles. O artefacto publicado parece ter vindo do maintainer — porque, tecnicamente, veio.
Esta é a razão pela qual o git log do repositório do Bitwarden pode estar completamente limpo. A mudança não aconteceu no código fonte — aconteceu durante o processo de build. E se a action comprometida foi referenciada por hash ou por tag mutável, pode até não ser imediatamente óbvio qual action foi o vector.
Fevereiro, Março, Abril: A linha cronológica de uma campanha coordenada
O que me preocupa quando olho para estes eventos não é o incidente do Bitwarden isoladamente. É o padrão.
O relatório do axios que documentei aqui há semanas mostrou que março de 2026 foi um mês catastrófico para supply chain security. O TeamPCP comprometeu o aquasecurity/trivy-action, usou as credenciais roubadas para comprometer o LiteLLM, e depois o Telnyx. Cada compromisso usou os artefactos do compromisso anterior para escalar para o próximo. Foi uma cascata.
O que estamos a ver agora em abril é diferente — não é uma cascata linear, é uma campanha horizontal. Um actor, ou um grupo com capacidades e táticas partilhadas, está a comprometer GitHub Actions usadas em múltiplos projectos simultaneamente, ou em rápida sucessão. Checkmarx KICS, extensões VS Code da Checkmarx, Bitwarden CLI — tudo com o mesmo vector, tudo no espaço de 24 a 48 horas.
A escolha dos targets também não é aleatória. Não estão a comprometer packages de nicho. Estão a comprometer ferramentas de segurança e infraestrutura. O KICS é usado por equipas de segurança para auditar a sua própria infraestrutura. As extensões VS Code são o ambiente de desenvolvimento de milhares de engenheiros. O Bitwarden CLI é o que equipas de DevOps usam para gerir secrets de produção.
Se eu quisesse maximizar o impacto de uma campanha de exfiltração de credenciais, não escolheria um package de parsing de CSV com 10.000 downloads semanais. Escolheria exactamente estas ferramentas.
O que deves fazer agora
Vou ser directo: a investigação completa ainda está em curso. A Socket está a trabalhar nos IOCs e nas orientações completas de remediação. O Bitwarden ainda não publicou resposta oficial que eu possa referenciar neste momento. Isto pode mudar nas próximas horas.
Mas o que podes e deves fazer imediatamente:
Verifica a versão instalada do Bitwarden CLI. Se tens @bitwarden/cli instalado localmente, num container, num pipeline de CI/CD, ou num script de automação qualquer, corre bw --version ou verifica o package.json / package-lock.json. Se a versão for 2026.4.0, trata-a como comprometida.
# Verificar versão instalada
bw --version
# Verificar em package.json
cat package.json | grep bitwarden
# Verificar em node_modules
cat node_modules/@bitwarden/cli/package.json | grep '"version"'
Faz downgrade para a versão anterior imediatamente. Não esperes pela investigação completa. A versão anterior à comprometida é 2026.3.x — instala-a explicitamente até haver mais clareza.
npm install -g @bitwarden/[email protected]
# ou a versão específica anterior, verifica no npmjs.com
Assume comprometimento se correste 2026.4.0 enquanto autenticado. Se corrias scripts ou processos que usavam o Bitwarden CLI versão 2026.4.0 com uma sessão autenticada — bw unlock com uma session key, ou scripts que fazem login automaticamente — assume que os dados a que essas sessões tiveram acesso foram exfiltrados.
Rota as credenciais críticas. Se tens passwords, API keys, ou secrets no teu vault do Bitwarden que foram acedidos durante o período potencialmente comprometido, rota-os. Sim, é trabalho. Menos trabalho do que lidar com as consequências de um vault comprometido.
Verifica os logs de CI/CD. Se usas o Bitwarden CLI em pipelines de CI/CD, revê os logs das últimas semanas para actividade da versão 2026.4.0. Olha para chamadas de rede inesperadas, acesso a secrets que normalmente não são tocados, ou comportamento anómalo nos jobs que usam o CLI.
Revê todas as GitHub Actions que usas. Não só no Bitwarden. O vector desta campanha são GitHub Actions comprometidas. Audita os teus workflows: que actions de terceiros estás a usar? Estão referenciadas por hash de commit (o único método verdadeiramente seguro) ou por tag mutável como @v4? Uma tag @v4 pode ser sobrescrita para apontar para código diferente sem que o teu workflow YAML mude.
O problema estrutural que não vai desaparecer
Há algo que me incomoda profundamente nesta sequência de eventos, e que vai além dos incidentes individuais.
Temos uma indústria de software que construiu um modelo de distribuição assente em trust implícito. Quando fazes npm install, confias que o que o npm distribui é o que o maintainer criou. Quando a tua pipeline de CI/CD usa uma GitHub Action, confias que o que aquela action faz é o que a sua documentação descreve. Quando a tua imagem Docker oficial de uma ferramenta de segurança é puxada do Docker Hub, confias que é a versão legítima.
Nenhum destes trust boundaries é verificado criptograficamente de forma que o utilizador final possa confirmar de forma independente. O npm assina packages com uma chave que controla. O Docker Hub guarda imagens sem verificação obrigatória de conteúdo. As GitHub Actions podem ser referenciadas por tags mutáveis.
O que os atacantes desta campanha perceberam — e o que qualquer actor sofisticado percebeu há anos — é que o ponto fraco não é o código do maintainer. É o pipeline que transforma esse código no artefacto distribuído. E esse pipeline, nas ferramentas de CI/CD modernas, está construído em cima de dependências de terceiros que são invocadas com elevated privileges.
O KICS distribui um scanner de segurança. O pipeline que constrói esse scanner usa GitHub Actions. Alguém comprometeu uma GitHub Action. Fim do jogo.
O Bitwarden distribui um gestor de passwords. O pipeline que constrói esse gestor usa GitHub Actions. O mesmo padrão. O mesmo resultado.
Não estou a dizer que o npm é inseguro, que o Docker Hub é inseguro, ou que o GitHub é inseguro. Estou a dizer que o modelo de trust que toda a indústria adoptou tem um pressuposto central — que o processo de build não está comprometido — que está a ser sistematicamente explorado, e que as ferramentas de detecção que temos disponíveis não estão à altura da sofisticação dos ataques.
O que a história do Bitwarden vai mostrar
Há um detalhe que me parece importante sublinhar antes de terminar, porque tem implicações para além do incidente específico.
O Bitwarden é um projecto genuinamente open source e auditável. O código do servidor, do cliente, e do CLI está disponível no GitHub e tem sido auditado por terceiros. A empresa por trás do Bitwarden investiu significativamente em transparência e em auditabilidade como propostas de valor centrais.
E ainda assim o CLI foi comprometido. Não porque o código open source fosse malicioso. Não porque os maintainers fossem negligentes ou mal-intencionados. Mas porque o pipeline que transforma esse código num package npm publicado foi infiltrado.
Isto tem uma implicação que devia preocupar qualquer equipa de segurança: a auditabilidade do código fonte já não é suficiente como garantia de que o que executas é o que foi auditado. Precisas também de verificar que o processo de build que transformou esse código no binário ou package que instalaste não foi comprometido.
Esta é uma barra muito mais alta. E muito poucas ferramentas e organizações estão actualmente a atingi-la de forma consistente.
Enquanto isso, a Socket está a fazer o trabalho
Devo dar crédito onde é devido. A Socket — não a npm, não o GitHub, não o Bitwarden — foi quem identificou e alertou para o compromisso do Bitwarden CLI. Tal como foi a Socket que investigou e expandiu o incidente da Checkmarx de um problema de Docker Hub para um padrão de campanha coordenada.
A Socket é uma empresa com um produto comercial de monitorização de supply chain para equipas de desenvolvimento, e é transparente sobre isso. Mas o trabalho de investigação que estão a publicar é genuíno e está a identificar compromissos que de outra forma podiam ter corrido durante muito mais tempo.
O modelo que têm é o da análise comportamental e semântica de packages — analisar o que o código realmente faz, não apenas verificar o hash contra uma base de dados de malware conhecida. É a mesma abordagem, conceptualmente, que o Joe Desimone da Elastic usou para detectar o axios, e que mostrei como replicar com um LLM local. A diferença é escala e cobertura.
Que empresas privadas estejam a fazer este trabalho é melhor do que ninguém o fazer. Mas que o ecossistema npm e PyPI em 2026 ainda não tenha este nível de análise incorporado como default é uma falha sistémica que vai continuar a criar as condições para estas campanhas.
Em resumo
O Bitwarden CLI 2026.4.0 foi comprometido. O vector foi uma GitHub Action no pipeline de CI/CD do Bitwarden, consistente com a campanha Checkmarx que a Socket documentou nas últimas 48 horas. O código malicioso foi injectado em bw1.js. A investigação está em curso.
Se usas o @bitwarden/cli em qualquer contexto, verifica a versão agora. Se tens 2026.4.0, faz downgrade. Se correste scripts autenticados com essa versão, assume comprometimento e rota as credenciais críticas.
Mais importante: começa a pensar na segurança das tuas pipelines de CI/CD como uma superfície de ataque activa. Audita as GitHub Actions que usas. Referencia-as por hash de commit, não por tag. Implementa verificação de integridade de artefactos onde puder. E considera monitorização activa de supply chain para os packages críticos no teu stack.
Esta campanha não terminou com o Bitwarden. O padrão está estabelecido, o vector está a funcionar, e os targets escolhidos — ferramentas de segurança e infraestrutura — sugerem um objectivo deliberado de maximizar o acesso a credenciais de alto valor. O próximo alerta pode chegar nas próximas horas.
Mantende-se vigilantes.
Um abraço,
Nuno Higgs
Fontes:
- Socket Research Team — Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain Campaign (23 Abril 2026)
- Socket Research Team — Malicious Checkmarx Artifacts Found in Official KICS Docker Repository and Code Extensions (22 Abril 2026)
- Este blog — Axios, DPRK, e um PoC feito numa tarde (14 Abril 2026)