axios CVE-2026-67320: aggiorna alla 1.18.0 ora

Il 1° agosto, i manutentori di axios hanno divulgato CVE-2026-67320, una vulnerabilità di prototype pollution nell'adattatore HTTP Node.js della libreria. axios è uno dei pacchetti più installati su npm, quindi questa falla interessa moltissimi backend. In breve: nelle giuste condizioni, un attaccante in grado di inquinare Object.prototype può fare in modo che il server instradi le richieste HTTP in uscita attraverso un proxy sotto il suo controllo. Per le chiamate in chiaro http://, quel proxy può leggere l'intestazione Authorization, le credenziali Basic auth, il metodo, l'URL completo, l'intestazione Host e il corpo della richiesta, per poi restituire una risposta a sua scelta. NVD lo ha valutato 8,3 (Alto) su CVSS 4.0.

Ecco il meccanismo, perché il dettaglio conta. axios indurisce la configurazione unita delle richieste costruendola su un oggetto a prototipo nullo, in modo che le proprietà ereditate non possano infiltrarsi. Ma gli interceptor delle richieste vengono eseguiti dopo quella fusione, e un pattern di interceptor molto comune — return { ...config } oppure Object.assign({}, config) — riconverte silenziosamente quell'oggetto indurito in uno ordinario con Object.prototype nella sua catena. L'adattatore Node legge quindi config.proxy da quell'oggetto, percorre la catena dei prototipi e trova ciò che un attaccante ha depositato in Object.prototype.proxy. La correzione in 1.18.0 legge quei valori di configurazione annidati attraverso un accessor sicuro che ignora le proprietà ereditate.

Una precisazione onesta: axios da solo non consegna questo all'attaccante. Quest'ultimo ha bisogno di un bug separato di prototype pollution da qualche parte nella tua app o nel tuo albero delle dipendenze per impostare Object.prototype.proxy. axios è l'amplificatore, non il punto d'ingresso. Ed è esattamente per questo che vale la pena prenderlo sul serio. I gadget di prototype pollution sono comuni nelle codebase JavaScript, e questo trasforma una vulnerabilità che molti team liquidano come teorica in un'esfiltrazione di credenziali.

Vediamo questo schema continuamente durante i nostri pentest e audit di sicurezza. Lo scanner di un cliente segnala un problema di prototype pollution, qualcuno lo classifica come «nessun impatto reale» e rimane nel backlog per un anno. Poi arriva un bug come questo e il teorico diventa una linea retta verso token compromessi. Il prototype pollution raramente è l'intera exploit. È il primitivo che rende il prossimo bug molto peggiore.

L'azione immediata è banale e dovresti eseguirla oggi: aggiorna axios alla versione 1.18.0, oppure alla 0.33.0 se sei ancora sulla linea 0.x. Tutte le versioni da 1.15.2 a 1.18.0, o da 0.31.1 a 0.33.0, sono interessate. Esegui npm ls axios e ti mostrerà ogni copia nel tuo albero, comprese quelle transitive che il tuo codice non ha mai importato direttamente. Quelle copie transitive sono di solito quelle che ti fregano, perché nessuno le monitora.

Poi vai oltre la patch. Dal nostro lavoro con PHP e Docker per la creazione di backend cloud-native, i team che gestiscono queste divulgazioni con calma sono quelli che già trattano il traffico in uscita come qualcosa da controllare, non solo quello in entrata. Alcune misure che ripagano:

Effettua sempre le chiamate server-to-server tramite https://. Questo bug non trapela nulla su TLS correttamente validato. La chiamata http:// in chiaro tra due servizi è quella che ti brucia.
Limita l'egress. Se un servizio deve raggiungere solo tre host noti, un allowlist di egress o un proxy che gestisci tu significa che un config.proxy dirottato non ha dove andare.
Tieni i segreti fuori dagli URL e riduci la durata di validità di qualsiasi cosa invii in Authorization sui hop interni. I token di breve durata limitano i danni quando qualcosa trapela.

C'è anche un aspetto mobile, ed è facile trascurarlo. Nei nostri progetti native iOS e Android, l'app stessa non esegue axios, ma il backend-for-frontend o l'API gateway che vi sta dietro molto spesso sì. Un token upstream trapelato lì può silenziosamente compromettere tutti i client mobile a valle, e non lo vedrai nei log dell'app stessa. Quando esaminiamo un sistema mobile, tracciamo il token fino in fondo attraverso il backend, non solo al primo hop.

La lezione alla base del CVE è quella che vale la pena conservare. Il tuo albero delle dipendenze è superficie d'attacco, e «non usiamo quella funzionalità» non equivale a «quel codice non può eseguire». axios ha il supporto proxy che potresti non aver mai configurato, e la vulnerabilità vi risiedeva comunque. Sapere cosa è effettivamente installato ed essere in grado di correggerlo in un pomeriggio è una capacità che costruisci prima di averne bisogno, non durante un incidente.

Se non sei sicuro di cosa ci sia nel tuo albero delle dipendenze o di come il traffico in uscita lasci i tuoi servizi, parliamone.