C’è un momento, nel mondo della sicurezza informatica, in cui ti accorgi che il problema non è (solo) nel codice che vedi, ma nel terreno su cui quel codice poggia. È quello che è successo a Notepad++, l’editor di testo standard per milioni di utenti: a inizio febbraio 2026 il maintainer ha raccontato come un attore verosimilmente sponsorizzato da uno Stato abbia dirottato il meccanismo di aggiornamento, sfruttando una compromissione a livello di provider di hosting (targeted supply chain attack), non una falla dell’applicazione. In questo incidente, l’attacco a Notepad++ mette in luce il lato invisibile della supply chain e i rischi nascosti che ne derivano.

Come funziona l’attacco: updater, redirect e targeting selettivo

Come riportato nella nota ufficiale del progetto, l’attacco non ha sfruttato vulnerabilità applicative ma una compromissione dell’infrastruttura di hosting, con un impatto mirato sul meccanismo di aggiornamento (Notepad++ Hijacked by State‑Sponsored Hackers).

La dinamica, nella sua essenza, è lineare e per questo ancora più insidiosa: le richieste di aggiornamento inviate dall’updater (WinGUp) verso notepad-plus-plus.org sono state intercettate e, in casi selezionati, reindirizzate verso server sotto controllo dell’attaccante; lì, al posto del pacchetto legittimo, arrivava un eseguibile compromesso. Non un attacco “a pioggia”, ma chirurgico: solo alcuni utenti bersaglio hanno visto alterato il percorso, il che spiega perché l’anomalia sia rimasta low‑noise per mesi. 

Chi c’è dietro? Il maintainer parla apertamente di probabile gruppo “statale” cinese (state-sponsored attack), una valutazione condivisa da più ricercatori indipendenti e coerente con il profilo dell’operazione (targeting limitato, infrastruttura e TTP raffinati). L’ipotesi di un’operazione sponsorizzata da uno Stato è stata ripresa anche da testate di settore come The Hacker News, SecurityWeek e dalle analisi di SecurityAffairs, che sottolineano il carattere mirato e a basso rumore dell’attacco.

È un punto importante: la scelta di colpire l’infrastruttura di hosting del progetto, invece della superficie applicativa, è precisamente ciò che rende l’attacco silenzioso e credibile, perché sfrutta la fiducia preesistente nei canali ufficiali.

La timeline dell’incidente: da giugno a dicembre 2025

La timeline è un piccolo caso di studio. Secondo il resoconto ufficiale, la compromissione dell’host condiviso parte a giugno 2025; il 2 settembre un intervento di manutenzione (kernel/firmware) fa perdere agli attaccanti l’accesso diretto al server, ma credenziali interne rubate consentono loro di continuare a indirizzare parte del traffico fino al 2 dicembre, quando la rotazione delle chiavi chiude la porta. Alcune analisi indicano che l’attività offensiva si sarebbe di fatto arrestata l’11 novembre, ma la finestra di rischio documentata dal provider arriva comunque a inizio dicembre.  

Dal punto di vista tecnico-procedurale, Notepad++ aveva già iniziato a “serrare i bulloni” prima della disclosure completa: la v8.8.8 di metà novembre 2025 accenna a un potenziale problema sull’updater e invita a scaricare manualmente dal sito ufficiale; poche settimane dopo, con v8.8.9, arriva la mitigazione chiave: l’updater verifica sia la firma digitale sia il certificato dell’installer e abortisce l’update se qualcosa non torna (Notepad++ v8.8.9 release: Vulnerability‑fix). Nel frattempo, i binari erano già firmati con certificato GlobalSign (dalla 8.8.7) e il progetto suggeriva di rimuovere il vecchio root certificate proprietario non più necessario. 

Contromisure tecniche: hardening dell’updater e verifica delle firme

Ma la mossa più strutturale è a livello di protocollo degli update: l’XML restituito dal server viene ora firmato con XMLDSig e la validazione diventerà obbligatoria a partire dalla v8.9.2 (indicata come in arrivo circa un mese dopo l’annuncio di febbraio). È un passaggio fondamentale: non solo il binario è autenticato, ma anche il “manifesto” che dice all’updater che cosa scaricare; senza quest’anello, chi controlla l’infrastruttura può convincerti a fidarti di un contenuto ostile. 

C’è poi la bonifica del perimetro: il sito è stato migrato su un nuovo provider con pratiche di sicurezza più robuste, mentre il precedente hosting ha confermato che l’obiettivo dell’attaccante era specificamente il dominio Notepad++ e che altri clienti sullo stesso server condiviso non risultano presi di mira. Dal racconto del provider emergono anche i segnali di una risposta incidentale corretta: rotazione credenziali, patch di vulnerabilità sfruttate e controlli trasversali sugli altri sistemi ospitati. 

La supply chain come rischio di terze parti

Se guardiamo l’incidente con le lenti della gestione del rischio di terze parti, la lezione è chiara: puoi avere un’app dignitosamente sicura, ma se la catena di distribuzione non è blindata end‑to‑end, c’è sempre uno strato “a monte” che può essere forzato. È la differenza fra dire “l’installer è firmato” e dire “ogni artefatto e metadato che parte dall’origine e arriva all’endpoint è autenticato e verificato prima dell’esecuzione”. È esattamente il salto di qualità operato dal progetto con la combinazione firma binaria + manifest firmato + enforcement lato client. 

Questo episodio, infine, va letto anche come promemoria culturale: gli strumenti gratuiti e “banali” che usiamo ogni giorno (un editor, un visualizzatore PDF, un client FTP) possono rappresentare catene di fiducia che nessuno ha formalmente gestito, e che proprio per questo diventano appetibili per attacchi a basso impatto apparente ma alto rendimento strategico. Qui il damage non è stato un ransom eclatante, ma l’inizio silenzioso di catene d’infezione mirate dentro organizzazioni target: è il tipo di rischio che non fa rumore finché non lo colleghi ai log giusti. 

Cosa dovrebbero fare le aziende oggi

Cosa deve fare chi amministra ambienti aziendali? Se avete aggiornato Notepad++ tra giugno e inizio dicembre 2025 con l’updater legacy, vale la pena fare un threat hunting retrospettivo sui log proxy/DNS per richieste a endpoint di update con destinazioni anomale rispetto ai domini ufficiali, e controllare nei sistemi EDR eventuali esecuzioni inusuali lanciate dall’updater (o da percorsi Temp) nel momento dell’update. In ogni caso, portate tutti i client ad almeno v8.8.9 (meglio ancora: reinstallazione pulita dall’ultima versione stabile dal sito ufficiale) per beneficiare della verifica firma+certificato e prepararvi all’enforcement XMLDSig quando la v8.9.2 sarà disponibile.  

Il team di Notepad++ ha fatto quello che ci aspettiamo da un progetto maturo: trasparenza, migrazione di hosting, hardening dell’updater e dei manifest, roadmap chiara sull’enforcement. Il resto spetta a noi: inventariare le dipendenze, pretendere SLI/SLO minimi anche dai provider “piccoli”, e introdurre controlli che impediscano a qualunque updater di eseguire binari non firmati o non attesi.
Perché a volte, per difendersi davvero, bisogna guardare sotto il tappeto dove passa il filo della fiducia. 

Controlla che la supply chain sia affidabile

Capire se la propria supply chain software è davvero sotto controllo non significa solo verificare che gli applicativi siano aggiornati o che i binari siano firmati. La domanda giusta è un’altra: ogni passaggio, dall’origine del codice fino all’esecuzione sui sistemi degli utenti, è autenticato, monitorato e verificabile?
Updater, manifest, infrastrutture di hosting, dipendenze e fornitori esterni fanno tutti parte della stessa catena di fiducia: se uno di questi anelli è opaco o dato per scontato, il rischio non è teorico, ma operativo.

Molti incidenti non nascono dal codice, ma dai fornitori, dagli updater e dalle dipendenze che nessuno monitora davvero. Contattaci per una valutazione del rischio di terze parti e per progettare controlli di sicurezza end-to-end sulla tua infrastruttura di distribuzione software.