Bitwarden CLI compromesso: perché la supply chain fa paura

Di recente è emerso un incidente di sicurezza che riguarda direttamente Bitwarden CLI, uno degli strumenti più diffusi per la gestione delle credenziali in ambienti di sviluppo.

La versione bitwarden/cli 2026.4.0, distribuita tramite npm, è risultata compromessa per una finestra temporale ristretta, tra il 22 aprile e la sua rimozione avvenuta poche ore dopo. L’attacco non ha colpito il codice sorgente del progetto, ma il processo automatizzato di build e pubblicazione, alterato attraverso una GitHub Action compromessa all’interno della pipeline CI/CD ufficiale.

Come funziona l’attacco e cosa rischia chi ha installato quella versione

Il malware si attiva durante l’installazione del pacchetto, sfruttando hook automatici come preinstall. Una volta in esecuzione, raccoglie token GitHub, credenziali npm, chiavi SSH, variabili d’ambiente e file di configurazione locali. I dati vengono cifrati con AES-256-GCM e inviati a server controllati dagli attaccanti.

Il rischio non si ferma all’ambiente locale. In presenza di token validi, il codice malevolo tenta una propagazione laterale: modifica workflow GitHub Actions, inietta codice in altri repository e pubblica nuove versioni compromesse di pacchetti npm, innescando un effetto a catena tipico degli attacchi alla supply chain.

I vault di Bitwarden non risultano coinvolti: il sistema adotta un modello zero-knowledge con cifratura end-to-end che impedisce l’accesso ai dati in chiaro anche in caso di compromissione del servizio. Il pericolo reale riguarda tutto ciò che circonda il vault: segreti presenti nei file .env, chiavi private, token di accesso e credenziali CI/CD, come spiegato nel blog di socket.dev.

Cosa fare subito se hai usato la versione colpita

Chi ha installato la versione compromessa deve procedere con la rotazione immediata di tutte le credenziali presenti nell’ambiente coinvolto: token GitHub, chiavi SSH, credenziali cloud e qualsiasi segreto nelle variabili d’ambiente. È necessario verificare i log delle pipeline CI/CD per individuare esecuzioni anomale e controllare eventuali modifiche non autorizzate ai workflow.

Come misura temporanea, è consigliato tornare alla versione precedente sicura, la 2026.3.0, oppure utilizzare i binari ufficiali firmati disponibili sul sito di Bitwarden.

L’incidente non è isolato. Le analisi lo collegano a una campagna più ampia attribuita al gruppo TeamPCP, che ha già colpito strumenti come KICS e Trivy, componenti comuni nelle pipeline DevOps. La strategia è sempre la stessa: compromettere strumenti fidati per sfruttare la fiducia implicita che gli sviluppatori ripongono in essi.

Vale la pena notare che la versione compromessa è stata distribuita tramite trusted publishing npm, un sistema pensato per ridurre i rischi legati ai token statici. Questo caso dimostra che anche meccanismi avanzati di pubblicazione automatizzata non sono sufficienti se uno degli anelli della catena, come una GitHub Action esterna, viene compromesso.