CVE-2026-44278 riguarda FortiClient VPN e il meccanismo “Save Password”: una libreria interna poteva essere richiamata da codice esterno per recuperare le credenziali VPN memorizzate localmente. La falla, classificata Low con CVSS 2.3, è stata scoperta da Alex Ghiotto e corretta da Fortinet con una mitigazione sul caricamento della componente.
Le funzionalità di comodità pensate per semplificare la vita dell’utente nascondono spesso insidie non banali dal punto di vista della sicurezza.
È il caso dell’opzione “Save Password” presente in molti client VPN, che permette di evitare di reinserire le credenziali ad ogni connessione, ma che solleva interrogativi legittimi: come vengono protette le credenziali memorizzate? Dove vengono salvate localmente? E soprattutto, quanto è robusto il meccanismo adottato per impedirne il recupero da parte di un attaccante?
A queste domande ha cercato di rispondere Alex Ghiotto, ricercatore di sicurezza e bug hunter di HackerHood, che attraverso un’attività di analisi approfondita su FortiClient VPN ha scoperto una vulnerabilità nel meccanismo di protezione delle credenziali salvate localmente dal client. La ricerca, condotta combinando monitoraggio di sistema, reverse engineering e debugging a basso livello, ha portato all’identificazione di una libreria interna al prodotto, richiamabile anche al di fuori del contesto previsto, in grado di restituire in chiaro le credenziali VPN memorizzate, superando di fatto la protezione che l’utente si aspetterebbe da una funzionalità di questo tipo.
La vulnerabilità individuata da Alex è stata segnalata a Fortinet seguendo un processo di responsible disclosure. Il vendor ha verificato la problematica e ha introdotto una mitigazione che limita l’utilizzo della componente interessata ai soli processi eseguiti dalla directory di installazione ufficiale del prodotto, impedendo così il richiamo della funzione da parte di codice arbitrario. Al termine del processo di disclosure, alla vulnerabilità è stato assegnato l’identificativo CVE-2026-44278 con CVSS v3.1 di 2.3 (Low) e vettore CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N.
In questo articolo viene ricostruito il percorso di analisi seguito da Alex: dalle prime osservazioni con Process Monitor, passando per il debugging con x64dbg e la decompilazione con Ghidra, fino allo sviluppo di un Proof of Concept in grado di dimostrare concretamente l’impatto della vulnerabilità e all’analisi della correzione introdotta dal vendor.
La prima fase dell’analisi è stata condotta utilizzando Process Monitor (Procmon) con l’obiettivo di individuare dove e come FortiClient VPN memorizza le credenziali quando è abilitata l’opzione “Save Password”.
Per ottenere una visione completa del comportamento del client sono stati applicati i seguenti filtri:
Successivamente è stata avviata una connessione utilizzando un profilo VPN precedentemente configurato con il salvataggio delle credenziali abilitato.

Dall’analisi degli eventi generati è emerso che il client accede al registro di sistema interrogando specifiche chiavi associate al profilo VPN configurato. In particolare, durante la fase di connessione vengono effettuate operazioni di lettura sui valori:
Tali valori sono contenuti all’interno di una sottochiave direttamente riconducibile al profilo VPN utilizzato.
Questa osservazione conferma che le credenziali non vengono gestite esclusivamente in memoria, ma sono persistite localmente all’interno del registro di sistema.
Diversi riferimenti presenti in forum tecnici e comunità di sicurezza suggeriscono inoltre una possibile correlazione tra tali valori e le credenziali salvate dal client:
Sebbene tale associazione non sia ufficialmente documentata dal vendor, risulta coerente con il comportamento osservato durante l’analisi dinamica.
L’analisi della call stack associata agli eventi di lettura mostra inoltre l’utilizzo dell’API Windows RegQueryValueExA, confermando che l’accesso alle informazioni avviene tramite interrogazioni dirette al registro di sistema.
L’analisi con Process Monitor ha evidenziato l’utilizzo dell’API Windows RegQueryValueExA durante la lettura delle chiavi DATA1 e DATA2. Il passo successivo consiste nell’individuare il punto del codice responsabile di tali operazioni e comprendere come il client gestisce le credenziali salvate.
A tale scopo è stato collegato il debugger x64dbg al processo FortiVPN.exe, impostando un breakpoint sull’API RegQueryValueExA.
Per limitare il numero di intercettazioni e concentrarsi esclusivamente sugli accessi di interesse, è stata definita la seguente break condition:
strstr(utf16(RDX), “DATA”)
La condizione forza l’interruzione dell’esecuzione solamente quando il nome del valore richiesto contiene la stringa DATA, consentendo di intercettare le letture delle chiavi precedentemente identificate. Una volta configurato il breakpoint, viene avviata una connessione VPN utilizzando il profilo contenente le credenziali salvate.

L’interruzione avviene correttamente durante la fase di autenticazione. Analizzando la call stack è possibile osservare che la richiesta non origina direttamente dal client principale, ma da una funzione denominata reg_getstringW appartenente alla libreria utilsdll.dll, componente distribuita da Fortinet insieme a FortiClient.

L’osservazione è significativa poiché consente di identificare un primo punto di interesse all’interno della logica di gestione delle credenziali. L’accesso al registro risulta infatti delegato a una libreria interna anziché essere implementato direttamente all’interno di FortiVPN.exe.
Per approfondire il comportamento della funzione, il breakpoint viene successivamente spostato all’ingresso di reg_getstringW. Ripetendo la procedura di connessione è possibile analizzare i parametri passati alla funzione e seguire con maggiore precisione il flusso di elaborazione delle informazioni associate alle chiavi DATA1 e DATA2.
L’analisi della call stack ha permesso di identificare la funzione reg_getstringW all’interno della libreria utilsdll.dll, componente utilizzata da FortiClient per accedere alle informazioni salvate nel registro di sistema.
In questa fase non è ancora disponibile una definizione completa della funzione, ma l’osservazione dei registri durante il debugging consente di formulare alcune ipotesi preliminari sulla struttura dei parametri.
In particolare:

La disposizione dei parametri suggerisce che la funzione venga utilizzata per recuperare un valore dal registro e copiarne il contenuto all’interno del buffer fornito dal chiamante.
Per verificare questa ipotesi, l’esecuzione viene seguita fino al ritorno della funzione monitorando il contenuto del buffer puntato da R8.
L’analisi mostra che il buffer viene popolato con il valore associato alla chiave richiesta e che, nel caso della password VPN, il contenuto restituito risulta già disponibile in chiaro.

Un rapido confronto con il codice decompilato tramite Ghidra conferma le osservazioni effettuate durante l’analisi dinamica e permette di identificare un quarto parametro, inizialmente trascurato poiché valorizzato a zero durante i test.
A questo punto emerge un aspetto particolarmente interessante: la routine responsabile della lettura e della decifratura delle credenziali risiede all’interno di una DLL distribuita insieme al client e può essere richiamata da codice esterno.
Per verificare questa ipotesi viene sviluppato un semplice Proof of Concept in linguaggio C. Il programma apre un handle alla chiave di registro associata al tunnel VPN e richiama direttamente la funzione individuata durante il reverse engineering.
Poiché non è disponibile una import library ufficiale, la libreria viene caricata dinamicamente tramite LoadLibraryEx, utilizzando i flag:
Una volta caricata la DLL, la funzione viene risolta tramite GetProcAddress e invocata utilizzando una definizione coerente con la firma ricostruita durante l’analisi.
L’esecuzione del Proof of Concept conferma le osservazioni precedenti: la routine può essere richiamata al di fuori del client VPN e restituisce correttamente le credenziali in chiaro memorizzate dal prodotto.

L’analisi delle versioni successive alla correzione mostra che la mitigazione introdotta da Fortinet si concentra sul controllo del contesto di esecuzione della DLL.
In particolare, prima di consentire l’utilizzo delle routine interne, la libreria verifica il percorso del processo chiamante, permettendo l’esecuzione solamente quando quest’ultimo risiede all’interno della directory di installazione del prodotto:
C:\Program Files\Fortinet\FortiClient\
Questo controllo impedisce l’utilizzo diretto della DLL da parte di processi arbitrari eseguiti da percorsi differenti, bloccando lo scenario descritto nel Proof of Concept originale.
La correzione non modifica tuttavia la logica di gestione o di decifratura delle credenziali, ma introduce un vincolo aggiuntivo sul contesto dal quale tali funzionalità possono essere richiamate.
La modifica introdotta risulta comunque sufficiente a impedire la riproduzione diretta del Proof of Concept descritto in questo articolo nelle versioni corrette del prodotto.
L’analisi descritta in questo articolo è stata condivisa con Fortinet attraverso il processo di responsible disclosure. A seguito delle verifiche effettuate dal vendor e dell’introduzione delle mitigazioni descritte, alla problematica è stato assegnato l’identificativo CVE-2026-44278.
L’assegnazione della CVE conferma l’impatto della possibilità di riutilizzare al di fuori del contesto previsto una componente del client in grado di accedere alle credenziali memorizzate localmente.
La correzione introdotta da Fortinet impedisce la riproduzione diretta dello scenario illustrato nel Proof of Concept, riducendo significativamente la superficie di attacco.
Sono aperte le iscrizioni al corso in Live Class “AGENTIC AI CYBER OPERATIONS (AACO)”. La cybersecurity sta entrando nell'era degli AI Agent: sistemi capaci di ragionare, utilizzare strumenti, orchestrare attività e portare avanti operazioni complesse. Ma come funzionano davvero dal punto di vista tecnico? Con AACO, Red Hot Cyber porta i professionisti della cybersecurity a toccare con mano gli strumenti agentici, attraverso una Live Class in italiano con 15 ore di formazione, laboratori pratici e scenari reali. Agentic AI, Tool Calling, MCP, orchestrazione di agenti, OSINT, Threat Intelligence, vulnerability assessment e automazione delle operazioni di cybersecurity. Non un corso per imparare a usare un chatbot, ma un percorso per capire, costruire e governare sistemi agentici applicati alla sicurezza informatica.
Partenza: Sabato 7 novembre
Programma completo e iscrizioni: https://www.redhotcyber.com/linksSk2L/academy-agentic-ai
Per info: 379 163 8765 [email protected]