Notepad++ introduce doppia verifica contro attacchi: cosa cambia per gli utenti

Un sistema di aggiornamento automatico compromesso può trasformarsi in un canale privilegiato per distribuire codice malevolo. È quanto accaduto al popolare editor open source Notepad++ che, dopo un incidente di sicurezza durato mesi, ha introdotto un nuovo modello di protezione basato su una verifica a doppio livello. L’intervento, culminato con il rilascio della versione 8.9.2, si inserisce in un contesto in cui gli attacchi alla supply chain software sono cresciuti in modo costante dal 2020, colpendo strumenti di sviluppo, gestori di pacchetti e applicazioni largamente diffuse.

La revisione dell’infrastruttura di aggiornamento di Notepad++ rappresenta quindi un caso concreto di risposta tecnica a una compromissione reale, con misure verificabili e orientate a rendere sicuro il sistema mettendo al primo posto la sicurezza degli utenti.

Il contesto dell’attacco alla catena di distribuzione di Notepad++

L’incidente che ha indotto lo sviluppatore a rivedere il sistema di aggiornamento di Notepad++ è stato attribuito al gruppo Lotus Blossom, legato a operazioni di cyber-spionaggio.

Tra giugno e dicembre 2025 gli aggressori hanno compromesso il provider di hosting che gestiva il servizio di aggiornamento dell’editor, reindirizzando selettivamente le richieste di update di specifici utenti verso server controllati dagli stessi criminali informatici.

L’attacco ha sfruttato debolezze nei controlli di verifica delle versioni precedenti di Notepad++, permettendo l’installazione di payload malevoli firmati o mascherati come aggiornamenti legittimi. L’analisi di Rapid7 ha evidenziato l’impiego della backdoor “Chrysalis”, progettata per mantenere accesso persistente e raccogliere dati.

Architettura di aggiornamento e limiti del modello precedente

Prima della revisione, il meccanismo di aggiornamento di Notepad++ si basava su un componente chiamato WinGUp per scaricare e installare nuove versioni.

La verifica dell’integrità si limitava a controlli di base sull’origine dei file e su parametri di configurazione non firmati. In assenza di una verifica crittografica end-to-end dei metadati di update, un attaccante in grado di intercettare o reindirizzare le richieste HTTP/HTTPS poteva fornire un file manifest modificato e un installer malevolo, aggirando i controlli lato client.

La presenza di componenti come libcurl.dll aumentava inoltre il rischio di DLL side-loading, una tecnica con cui un’applicazione carica in modo improprio una libreria dinamica (DLL) malevola al posto di quella legittima, soprattutto in sistemi già compromessi.

Il modello double-lock introdotto con Notepad++ 8.9.2

La risposta tecnica si basa su un approccio a “doppia serratura” (double-lock) che combina due meccanismi indipendenti di verifica.

Il primo, introdotto dalla versione 8.8.9, prevede la verifica della firma digitale dell’installer scaricato da GitHub, effettuata tramite un certificato di code signing Authenticode, un sistema di firma di Microsoft che garantisce l’autenticità del software e l’integrità del file, assicurando che non sia stato modificato dopo la pubblicazione.

Il secondo livello, integrato pienamente in 8.9.2, prevede la verifica di un file XML di aggiornamento firmato tramite XMLDSig e distribuito dal dominio ufficiale del progetto Notepad++. Solo se entrambe le verifiche hanno esito positivo, il processo di aggiornamento prosegue.

La presenza di due fonti di verità distinte, una per il binario e una per il manifest, rende significativamente più complessa la compromissione del processo: un attaccante dovrebbe controllare simultaneamente l’infrastruttura di hosting e le chiavi di firma per riuscire a inserire codice malevolo.

Il nuovo schema di funzionamento double-lock è messo a confronto con la precedente (insicura) soluzione nel post pubblicato da Notepad++.

Rafforzamento dei componenti di rete e gestione plugin

Oltre al doppio controllo crittografico, il team ha eliminato componenti considerati superflui o rischiosi. La rimozione di libcurl.dll riduce la superficie d’attacco legata al caricamento di librerie esterne.

Disabilitate anche opzioni SSL non sicure di cURL, tra cui CURLSSLOPT_ALLOW_BEAST e CURLSSLOPT_NO_REVOKE, che potevano indebolire la verifica delle connessioni TLS.

La gestione dei plugin risulta a sua volta ulteriormente irrigidita: l’esecuzione di programmi associati al plugin manager è ora limitata a binari firmati con lo stesso certificato di WinGUp, impedendo l’iniezione di codice tramite moduli non autorizzati.

Distribuzione controllata e opzioni per gli amministratori

Gli utenti e gli amministratori di sistema possono disabilitare completamente l’aggiornamento automatico in fase di installazione.

L’interfaccia grafica consente di escludere il modulo durante l’installazione standard, mentre in ambienti enterprise è possibile utilizzare il pacchetto MSI richiamandolo dalla riga di comando con la seguente sintassi:

msiexec /i npp.8.9.2.Installer.x64.msi NOUPDATER=1

L’opzione consente di gestire gli aggiornamenti tramite repository interni o sistemi di patch management centralizzati, mantenendo il controllo sulla distribuzione delle versioni.

Conclusioni

L’episodio dimostra come anche applicazioni ampiamente diffuse e apparentemente a basso rischio possano diventare veicoli di compromissione su larga scala. L’adozione di firme multiple, la separazione dei canali di distribuzione e il controllo rigoroso dei componenti di rete rappresentano contromisure efficaci contro attacchi alla supply chain. Per gli utenti finali resta fondamentale aggiornare tempestivamente alla versione 8.9.2 o successive e scaricare gli installer esclusivamente dal dominio ufficiale.

Come nota finale, lo sviluppatore di Notepad++ ha effettuato una migrazione verso un nuovo provider di hosting, accompagnata dalla rotazione completa delle credenziali e delle chiavi utilizzate nei processi di pubblicazione.