Da npm a pnpm: guida alla migrazione post-breach axios
Contesto: il 31 marzo 2026 l’account npm del maintainer principale di axios (jasonsaayman) e’ stato compromesso. Le versioni axio 1.14.1 e 0.30.4 sono state pubblicate con una dipendenza malevola plain-crypto-js che eseguiva un RAT cross-platform via postinstall.
L’attacco ha sfruttato un token npm long-lived, bypassando la pipeline CI/CD GitHub Actions. La catena da npm install a beacon C2 richiedeva circa 15 secondi. Le versioni malevole sono rimaste live per circa 3 ore.
Cosa ci insegna questo attacco
Quello che possiamo imparare, prima di passare all’azione e’ che dobbiamo smetterla di dare per scontato che i tool che utilizziamo quotidianamente siano sicuri. E’ inutile spostare la nostra fiducia esclusivamente a tool alternativi perche’, per definizione, anche questi saranno vulnerabili in futuro. Dobbiamo partire dalla realta’ dei fatti, ovvero che non esistono sistemi sicuri, punto. E quindi come si evitano questa categoria di problemi e vulnerabilita’ in sede di sviluppo? La soluzione e’ cambiare i processi di sviluppo, non semplicemente un tool. Ieri era npm, domani sara’ bun e cosi’ via.
Rimuovere la superficie di attacco e’ l’unico modo per sviluppare serenamente
E rimuovere la superficie di attacco significa predisporre un sistema containerizzato, separato, isolato da quello che utilizziamo normalmente. Questo tra l’altro risolve tutta una serie di problematiche emerse dall’uso massivo di llm per sviluppare, anche loro estremamente rischiosi se lasciati nel nostro os. Come? Ci stiamo lavorando, ma sostanzialmente usando podman e similari. Per ora concentriamoci sul risolvere il problema immediato: smettiamo di usare npm.
Smetti di usare npm. Adesso.
Perche’ pnpm? Avrebbe davvero bloccato questo attacco specifico?
Il vettore primario era un postinstall nella dipendenza transitive plain-crypto-js.
| Aspetto | npm (default) | pnpm v10+ (default) |
|---|---|---|
Esecuzione postinstall | Automatica | Bloccata di default |
| Dipendenze transitive flat | Accessibili | Isolate (strict node_modules) |
minimumReleaseAge | Non disponibile | Configurabile |
trustPolicy | Non disponibile | Rileva downgrade di trust |
blockExoticSubdeps | Non disponibile | Blocca sorgenti “exotic” |
Quindi?: Con pnpm (almeno da v10 in su) abbiamo un ottimo policy hardening, che avrebbe bloccato questo specifico attacco nel punto piu’ critico: la fase di postinstall.
Risolve tutto? Cosa pnpm non risolve?
Purtroppo no, non e’ una manna, ma per ora ci aiuta a facilitare il periodo di transizione alla containerizzazione di cui parlavamo prima.
- Lockfile avvelenato: se aggiornassimo il lockfile durante la finestra d’attacco, la versione compromessa rimarrebbe.
- Allow-list troppo ampia: un pacchetto autorizzato in
allowBuildspotrebbe diventare vettore. - Payload runtime: codice malevolo nel modulo non viene fermato magicamente.
- Compromissione registry: ricordiamoci che pnpm scarica dallo stesso npm registry di npm.
Step 0: verifica immediata
Se trovate tracce di tutto cio’, considerate la macchina compromessa: cambiate credenziali, invalidate token e rebuild completo da immagine pulita. Se e’ il vostro OS, per ora il consiglio degli esperti e’ la formattazione completa (si, hai letto bene, per aver eseguito npm install axios).
Step 1: installare pnpm
Versione stabile corrente: 10.33.x.
Nota Windows: Microsoft Defender puo’ rallentare installazioni massicce. Valutate una esclusione sullo store pnpm.
Step 2: configurazione sicura (pnpm-workspace.yaml)
Questa baseline riduce la finestra di rischio in modo concreto.
Step 3: tabella comandi prima/dopo
| Operazione | PRIMA (npm) | DOPO (pnpm) |
|---|---|---|
| Installa dipendenze | npm install | pnpm install |
| Installa un pacchetto | npm install axios | pnpm add axios |
| Dev dependency | npm install -D vitest | pnpm add -D vitest |
| Disinstalla | npm uninstall axios | pnpm remove axios |
| Esegui script | npm run dev | pnpm dev |
| One-shot | npx some-tool | pnpm dlx some-tool |
| CI lockfile immutabile | npm ci | pnpm install --frozen-lockfile |
Step 4: workflow reali
4.1 Creare un progetto React con Vite
4.2 Installare Bootstrap
4.3 Installare axios (versione sicura)
4.4 Progetto Express
Codice applicativo invariato:
4.5 Migrare un progetto esistente da npm a pnpm
4.6 .gitignore
4.7 package.json scripts
Step 5: quando pnpm vi protegge
Scenario A: postinstall non autorizzato
Scenario B: pacchetto troppo recente
Scenario C: downgrade di trust
Regole d’oro
pnpm addal posto dinpm installper aggiungere dipendenze.pnpm installper installare dal lockfile.pnpm devper gli script applicativi.pnpm dlxper tool one-shot.pnpm createper scaffold nuovi progetti.- Sempre
pnpm-workspace.yamlcon policy esplicite. - Sempre committare
pnpm-lock.yaml. - In CI usare
pnpm install --frozen-lockfile. - Il codice JavaScript/JSX applicativo non cambia col package manager.
Quick reference card