Notepad++ afferma che il suo traffico di aggiornamento è stato dirottato per mesi nel 2025, con gli aggressori che hanno intercettato e reindirizzato selettivamente alcuni utenti verso infrastrutture dannose. BleepingComputer segnala che la compromissione è iniziata a giugno 2025 e si è conclusa il 2 dicembre, dopo che il provider di hosting ha rilevato la violazione e bloccato l'accesso.
L'incidente è un utile promemoria del fatto che "download tramite HTTPS" non è una questione di sicurezza completa. I sistemi di aggiornamento necessitano di una verifica end-to-end solida, perché l'infrastruttura di cui ti fidi può essere compromessa.
Cosa hanno sfruttato gli aggressori
BleepingComputer descrive una lacuna nei controlli di verifica degli aggiornamenti nelle vecchie versioni di Notepad++, che consente agli aggressori di fornire manifesti di aggiornamento manomessi e reindirizzare i download.
Si dice che la campagna sia stata ristretta e selettiva, in linea con un attore che si preoccupa più dell'accesso a obiettivi specifici che della distribuzione di massa.
La cronologia è importante:
- Compromesso iniziale nel giugno 2025
- Interruzione temporanea all'inizio di settembre dopo gli aggiornamenti del kernel/firmware
- Accesso continuato tramite credenziali interne rubate fino al 2 dicembre
Il passaggio "credenziali sopravvissute alla correzione" è un classico fallimento della risposta agli incidenti: applicare una patch al server non è sufficiente se l'aggressore ha già le chiavi.
Cosa è cambiato in Notepad++ dopo l'incidente
BleepingComputer segnala che Notepad++ ha migrato i client a un nuovo provider di hosting, ha ruotato le credenziali e ha migliorato la verifica.
A partire dalla versione 8.8.9, WinGUP:
- Verifica i certificati e le firme dell'installatore
- Utilizza XML di aggiornamento firmato crittograficamente
Il progetto prevede inoltre di rendere obbligatoria la verifica della firma del certificato nella versione 8.9.2.
Questa progressione (controlli facoltativi → controlli più rigorosi → controlli obbligatori) è esattamente il modo in cui la distribuzione del software dovrebbe rafforzarsi nel tempo.
L'aspetto malware: Chrysalis e attribuzione
BleepingComputer fa riferimento alla ricerca di Rapid7 che attribuisce una campagna correlata a un gruppo APT cinese noto come Lotus Blossom (descritto anche con altri alias) e a una backdoor personalizzata Rapid7 denominata "Chrysalis".
Negli incidenti mirati alla supply chain, il payload è spesso personalizzato. Ecco perché la difesa chiave non è "rilevare esattamente questo malware", ma "rendere difficile la distribuzione di qualsiasi payload non autorizzato tramite l'updater".
Cosa dovrebbero fare diversamente le organizzazioni
Se gestisci software in un ambiente aziendale, questo incidente evidenzia alcune impostazioni difensive predefinite:
- Evita gli aggiornamenti automatici dei consumatorisui sistemi critici ove possibile.
- Utilizzare la distribuzione di software gestito(pacchetti firmati in repository interni, Intune/SCCM, ecc.).
- Aggiungi un pin e verifica le firmeper installatori e aggiornamenti.
- Monitorare i “percorsi di aggiornamento”come infrastruttura critica: DNS, policy di ispezione TLS, comportamento del proxy e catene di esecuzione degli endpoint.
Se sei un utente singolo, i passaggi pratici sono più semplici:
- Aggiorna a una versione corrente di Notepad++ dal sito ufficiale
- Diffidate delle richieste di aggiornamento che non assomigliano al normale programma di installazione
- Evita gli annunci "scarica ora" nei risultati di ricerca che imitano le pagine ufficiali
In conclusione
Il dirottamento degli aggiornamenti di Notepad++ durato sei mesi non riguardava un singolo bug, ma i limiti di attendibilità. Se un aggressore riesce a modificare il manifesto o i controlli delle firme sono deboli, gli "aggiornamenti" diventano intrinsecamente un'esecuzione di codice remoto. La soluzione è una verifica end-to-end che non può essere aggirata, nemmeno quando il provider di hosting viene aggredito.