La maggior parte delle storie sulla sicurezza in questa newsletter riguarda cose che accadono direttamente a te: un messaggio di phishing, una password trapelata, un sito di shopping falso. Questa è diversa. Gli incidenti descritti di seguito sono accaduti agli sviluppatori — le persone che scrivono le app e i servizi che usi ogni giorno. Ma il motivo per cui rientrano qui è semplice: se qualcuno avvelena gli strumenti usati per creare il software, il veleno non rimane con chi lo ha creato. Viene spedito insieme al prodotto.

Di recente sono successe due cose che lo illustrano. Nessuna delle due ha fatto notizia come farebbe una grande violazione, perché nessuna delle due è una violazione che riguarda te, nello specifico. Sono entrambe attacchi alla catena che produce il software che alla fine installi, apri o a cui accedi.

Estensioni contraffatte camuffate da marchi affidabili

Open VSX è un marketplace pubblico per le estensioni degli editor di codice — i piccoli componenti aggiuntivi che gli sviluppatori installano per ottenere il completamento automatico, il linting e le integrazioni per gli strumenti che usano ogni giorno (Visual Studio Code e molti dei suoi derivati open source attingono da qui). Tra il 26 luglio e il 1° agosto 2026, i ricercatori di sicurezza di Manifold Security hanno trovato 77 estensioni contraffatte nel registro. Ognuna copiava il nome e lo spazio dei nomi di un'estensione reale e affidabile, ma era stata pubblicata da un account che non apparteneva al titolare dell'originale — una classica forma di impersonificazione, talvolta chiamata namespace squatting.

I nomi usurpati non erano casuali. Riprendevano le identità di AMD, LEGO Education, Hyperledger, Azure, Artsy, dei progetti open source di Salesforce, di un'agenzia federale statunitense e — con una sorta di cupa ironia — del marketplace stesso delle estensioni. Tutti e 77 i pacchetti contattavano un unico dominio, registrato appena 11 giorni prima della comparsa del primo pacchetto falso: un elemento che fa pensare a una campagna coordinata e costruita ad hoc, piuttosto che a imitazioni opportunistiche.

La maggior parte delle estensioni false faceva qualcosa di modesto: comunicava silenziosamente un hostname al server dell'aggressore, cosa che di per sé potrebbe essere solo un controllo per vedere chi aveva installato l'esca. Ma i ricercatori hanno scoperto che circa un quarto delle 77 — 19 pacchetti — si spingeva oltre. Pochi secondi dopo l'attivazione, raccoglievano l'hostname, il nome utente del sistema operativo, i dettagli dell'editor e un ID della macchina. Poi leggevano qualunque progetto lo sviluppatore avesse aperto: il git remote (che rivela l'organizzazione e l'host del repository), il dominio dell'indirizzo email dei commit, il branch corrente e l'ultimo commit. Raccoglievano anche i valori della continuous integration — le credenziali e la configurazione che consentono ai sistemi automatizzati di compilare e distribuire il codice senza che un essere umano debba digitare ogni volta una password.

Nessuno di questi dati è utile per svuotare il conto bancario di qualcuno. È utile per qualcos'altro: capire per quali aziende lavora uno sviluppatore, che aspetto ha la loro infrastruttura interna e come riuscire a inserirvisi.

Un bug da 9,8 su 10 nella macchina che crea il software

Il secondo incidente riguarda TeamCity, una piattaforma di continuous integration e continuous delivery (CI/CD) realizzata da JetBrains. Se un editor di codice è il luogo in cui gli sviluppatori scrivono il software, una piattaforma CI/CD è il reparto automatizzato della fabbrica in cui quel codice viene compilato, testato e inviato in produzione — spesso senza che nessuno debba fare clic su «deploy». TeamCity è un elemento centrale di questo apparato in molte aziende.

In TeamCity sono state divulgate vulnerabilità nelle versioni on-premises, tracciata come CVE-2026-63077, con un punteggio di gravità di 9.8 su un massimo di 10. Si tratta di un difetto di deserializzazione — una classe di bug in cui un programma si fida abbastanza dei dati in ingresso da trasformarli direttamente in codice eseguibile, senza prima verificare cosa siano realmente. In pratica, consentiva a un aggressore di inviare una richiesta a un server TeamCity vulnerabile, senza bisogno di effettuare il login, ed eseguire comandi arbitrari con gli stessi privilegi del servizio TeamCity. JetBrains ha distribuito le patch (versioni 2025.11.7 e 2026.1.3, oltre a un plugin di patch per le installazioni più vecchie 2017.1+), ma la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti ha successivamente avvertito che gli aggressori stanno sfruttando attivamente i sistemi senza patch.

Chiunque controlli il server di build di un'azienda controlla ciò che quell'azienda distribuisce. Non è un'ipotesi — è la funzione letterale dello strumento.

Lo stesso manuale, due porte diverse

Si tratta di incidenti non collegati, esaminati da ricercatori diversi, ma hanno una struttura comune. Nessuno dei due attacca un prodotto finito. Entrambi attaccano un passaggio precedente — l'editor in cui uno sviluppatore scrive il codice o il server che trasforma quel codice in una release distribuita. È questo il tratto distintivo di un attacco alla catena di approvvigionamento del software: invece di penetrare in un singolo obiettivo, si compromette qualcosa a monte da cui dipendono molti obiettivi e si lascia che sia il loro stesso processo, considerato affidabile, a portare avanti l'accesso al posto tuo.

È importante essere onesti su ciò che ancora non sappiamo. Nessuno dei due rapporti emersi questa settimana ha rivelato un caso confermato in cui un'app o un utente a valle sia stato compromesso come conseguenza diretta — la campagna delle estensioni sembra puntare alla ricognizione e alla raccolta di accessi, mentre lo sfruttamento di TeamCity è descritto come attivo, ma senza vittime identificate. È normale: le compromissioni della catena di approvvigionamento vengono spesso scoperte nel punto d'ingresso molto prima che (o invece di) riuscire a ricostruire il profitto finale.

Perché questo è un tuo problema, non solo loro

Probabilmente non installerai mai un'estensione per la programmazione né gestirai un server CI/CD. Ma usi il risultato di centinaia di questi strumenti: la tua app bancaria, il tuo gestore di password, il portale scolastico di tuo figlio, il browser con cui stai leggendo questo testo. Tutto è passato attraverso l'editor di qualche sviluppatore e la pipeline di build di qualche azienda prima di arrivare sul tuo telefono. Se uno dei due collegamenti viene compromesso silenziosamente, la modifica malevola può viaggiare insieme a un normale aggiornamento software di routine — il tipo di aggiornamento che installi perché ti è stato detto che aggiornare è la cosa sicura da fare.

È anche per questo che i consigli contenuti in un'analisi successiva a una violazione a volte suonano strani ai lettori non tecnici: un'azienda dice che i suoi sistemi sono stati compromessi tramite un server di build, una credenziale di sviluppatore rubata o una dipendenza malevola, e tutto ciò può sembrare astratto rispetto a «qualcuno ha indovinato la mia password». Non è astratto. È lo stesso risultato — i tuoi dati o l'integrità della tua app compromessi — raggiunto attraverso una porta di cui non sapevi nemmeno l'esistenza.

Cosa aiuta davvero

Non puoi verificare la pipeline CI/CD della tua banca, e non dovresti doverlo fare. Ma alcune abitudini riducono davvero la tua esposizione a questa categoria di rischio:

Mantieni attivi gli aggiornamenti automatici, ma non considerare automaticamente affidabili gli aggiornamenti. Le patch sono il modo in cui correzioni come quella di TeamCity descritta sopra raggiungono il software che usi — restare aggiornati chiude le finestre che gli aggressori stanno sondando attivamente. Allo stesso tempo, un aggiornamento è valido solo quanto la pipeline che lo ha prodotto, che è proprio ciò che viene preso di mira qui; non esiste una difesa individuale perfetta contro una release a monte realmente avvelenata, ed è per questo che si tratta fondamentalmente di un problema di responsabilità del fornitore, non tuo.

Se lavori con gli sviluppatori o li gestisci, ci sono due azioni concrete e verificabili: controlla che ogni estensione dell'editor di codice sia installata dall'account effettivamente verificato del publisher, non solo da un account con lo stesso nome (Open VSX e marketplace simili mostrano l'identità del publisher: controllala, non fidarti soltanto dell'icona e del titolo); e se la tua organizzazione gestisce TeamCity on-premises, verifica oggi stesso che sia alla versione 2025.11.7, 2026.1.3 o che abbia applicato il plugin di patch, non durante la prossima finestra di manutenzione — l'avvertimento della CISA significa che lo sfruttamento è attivo, non teorico.

Per tutti gli altri, il cambiamento utile è semplicemente una maggiore consapevolezza: quando leggi di una violazione aziendale che risale a «uno strumento per sviluppatori compromesso» o a «un sistema di build», non si tratta di una nota tecnica di nicchia. È la stessa categoria di evento delle violazioni di password e delle truffe di phishing di cui questa newsletter parla più spesso — è solo iniziato uno strato più a monte, prima che il prodotto arrivasse a te.