La U.S. Cybersecurity and Infrastructure Security Agency (CISA) ha aggiunto quattro vulnerabilità al proprio catalogo Known Exploited Vulnerabilities (KEV) il 9 novembre, citando prove di sfruttamento attivo. Le falle riguardano GPUStack, SignalWire FreeSwitch, OpenBSD OpenSSH e IBM Aspera Faspex, ed espongono le organizzazioni che usano installazioni vulnerabili al rischio di accesso non autorizzato, esecuzione di comandi o privilegi elevati.
L'avviso della CISA indica le priorità di correzione per le organizzazioni interessate. Resoconti tecnici pubblici descrivono attacchi contro OpenSSH su Linux e GPUStack, mentre l'avviso dell'autore di FreeSWITCH conferma anche lo sfruttamento in natura.
Le quattro aggiunte al catalogo sono:
- CVE-2026-102895, GPUStack: autenticazione non corretta che consente l'accesso amministrativo senza credenziali. L'autore identifica come vulnerabili le versioni precedenti alla 2.2.0 e raccomanda la 2.2.0 o successive.
- CVE-2026-116779, SignalWire FreeSwitch: iniezione di codice che può esporre configurazione e credenziali, consentire agli attaccanti di controllare le chiamate ed eseguire comandi.
- CVE-2026-123158, OpenBSD OpenSSH: difetto legato a un codice di stato o a un valore di ritorno inatteso, noto come SSHole, che può aggirare l'autenticazione su Linux.
- CVE-2026-123218, IBM Aspera Faspex: autorizzazione non corretta che consente a un utente autenticato di inviare un messaggio appositamente costruito e di ottenere privilegi elevati.
The Hacker News ha riportato punteggi di gravità CVSS pari a 9,8 per le falle di GPUStack, FreeSwitch e Faspex e 8,1 per SSHole. Ne colloca le correzioni rispettivamente a luglio, ottobre, novembre e novembre 2026.
Gli attacchi a OpenSSH includono tentativi di mantenere l'accesso
The Hacker News ha riportato che Previdian ha registrato ventidue tentativi di sfruttamento di SSHole provenienti da quattordici indirizzi IP unici, con tentativi risalenti al 6 novembre. Defused Cyber ha scritto in un post del 7 novembre di aver osservato un numero ridotto di attori che prendevano di mira la falla e che l'attività non era ancora diffusa.
GreyNoise ha collocato il primo tentativo contro la propria rete di honeypot — sistemi usati per osservare gli attacchi — alle 00:46 UTC del 7 novembre. Ha segnalato attività confermata successiva allo sfruttamento da sei indirizzi IP di origine, corrispondenti a diciotto catene di attacco distinte.
Tra queste catene figuravano ricognizione, interrogazioni dei servizi di metadati cloud, tentativi di leggere gli hash delle password e le chiavi SSH di root, e tentativi di modificare il file authorized_keys di SSH per mantenere l'accesso. In almeno un caso, gli attaccanti hanno installato TAC Agent, un programma Python di comando e controllo in grado di eseguire comandi shell, raccogliere informazioni di sistema, elencare directory, trasferire file e aggiornarsi.
Il rapporto cita anche osservazioni di watchTowr sullo sfruttamento di SSHole a fini di attività botnet e di mining di criptovalute.
GPUStack può scambiare il traffico remoto per un amministratore locale
L'avviso di GPUStack descrive un errore di fiducia in get_current_user, in gpustack/api/auth.py. Prima della versione 2.2.0, le richieste considerate provenienti dal loopback — l'indirizzo di rete locale dell'host stesso — ricevevano automaticamente l'identità di amministratore integrata quando force_auth_localhost era False, ovvero il suo valore predefinito.
Due percorsi potevano attivare questo comportamento. In una tipica installazione self-hosted con un reverse proxy sulla stessa macchina che inoltra a 127.0.0.1, le richieste remote arrivavano a GPUStack con un indirizzo socket locale. Non servivano credenziali né header falsificati. L'avviso afferma che questo percorso è stato verificato dall'inizio alla fine sulla HEAD 6bee5883. In alternativa, un attaccante poteva inviare X-GPUStack-Real-IP: 127.0.0.1 per far sembrare locale una richiesta.
Questo accesso consentiva agli attaccanti di ispezionare e modificare utenti, modelli, worker e configurazione; leggere le credenziali dei worker e i segreti dei provider cloud; e creare chiavi API amministrative persistenti con scope ["*"], utilizzabili successivamente da qualsiasi IP di origine. Le funzionalità amministrative, tra cui POST /v2/inference-backends/from-yaml, potevano poi eseguire codice sugli host dei worker.
I manutentori segnalano lo sfruttamento di un'installazione 2.1.1, in cui backend personalizzati creati dagli attaccanti eseguivano reverse shell, dando loro accesso remoto ai comandi. Riconoscono le segnalazioni indipendenti di Nikko Enggaliano, Wei Yunzhou e di Rui Yang e Haoyu Wang, della Johns Hopkins University, mentre lo sfruttamento attivo è stato segnalato da Javier Sixto di Ulex Innovative Systems. The Hacker News data l'avviso al 31 luglio.
I messaggi di chat di FreeSWITCH possono raggiungere le interfacce di comando
L'avviso di FreeSWITCH spiega che sofia_presence_handle_sip_i_message() divide l'utente di destinazione di un SIP MESSAGE in arrivo in corrispondenza di +, trattando la parte sinistra come selettore del protocollo di chat. SIP è un protocollo di segnalazione usato dai sistemi di chiamata.
Il modulo mod_dptools registra un'interfaccia di chat api che passa il proprio indirizzo a switch_api_execute(). Un peer che riesce a far accettare anche un solo MESSAGE può quindi selezionare un comando API di FreeSWITCH. I comandi vengono eseguiti con i privilegi del processo FreeSWITCH, consentendo l'esecuzione di comandi del sistema operativo, la divulgazione di credenziali e configurazione e il controllo completo delle chiamate. Quando mod_lua è caricato, come nella configurazione standard, anche il codice Lua inline può accedere all'intera libreria standard.
La chat in ingresso è abilitata a meno che un profilo non imposti enable-chat=false; i profili predefiniti internal ed external la lasciano abilitata. Restringere la lista di controllo degli accessi in ingresso non elimina l'esposizione, perché tale lista non copre il traffico MESSAGE.
Dove l'autenticazione dei MESSAGE è applicata, basta un account ordinario con permesso di registrazione. Alcune configurazioni predefinite consentono anche l'accesso senza un account controllato dall'attaccante: conf/vanilla/directory/default/default.xml definisce un utente default privo di password e di a1-hash, che viene autenticato a meno che allow-empty-password non sia false per quell'utente.
La correzione introduce un'impostazione enable-chat-api-proto per profilo, disabilitata a meno che non venga abilitata esplicitamente. I tentativi bloccati di selezionare api ricevono una risposta 403 e generano un log con l'origine e il comando richiesto. La verifica non distingue tra maiuscole e minuscole; i messaggi senza selettore o che usano altri protocolli di chat mantengono il proprio instradamento. L'impostazione è fornita commentata nei profili vanilla e nell'esempio mod_sofia. L'avviso riconosce il contributo di Örn Arnarson e Gunnlaugur.
Cosa devono fare gli amministratori
Gli amministratori di GPUStack dovrebbero aggiornare alla 2.2.0 o successiva, versione che elimina l'accesso amministrativo automatico tramite loopback e rafforza la gestione degli indirizzi dei client. Le soluzioni alternative indicate dai manutentori sono impostare force_auth_localhost=true, impedire ai proxy di presentare richieste esterne come loopback, rimuovere al perimetro gli header X-GPUStack-Real-IP forniti dal client e limitare l'accesso alle API tramite VPN o autenticazione sul perimetro.
Gli amministratori di FreeSWITCH dovrebbero applicare la correzione dell'autore oppure impostare enable-chat=false su ogni profilo che non richiede chat SIP in ingresso. Questa soluzione alternativa disattiva tutta la consegna in ingresso dei messaggi MESSAGE di chat su tali profili.
La sola autenticazione non chiude il percorso dei comandi di FreeSWITCH. L'autenticazione dei MESSAGE è abilitata per impostazione predefinita dalla 1.10.7; combinata con la rimozione di ogni utente della directory privo di entrambi i campi password — inclusi gli utenti di esempio predefiniti default e Skinny — riduce soltanto l'esposizione all'esecuzione di comandi da parte di utenti autenticati. Allo stesso modo, disable_system_api_commands=true rimuove l'API system ma lascia raggiungibili le altre API, compresi il caricamento dei moduli e l'originazione di chiamate.
Per le agenzie del Potere Esecutivo civile federale degli Stati Uniti (U.S. Federal Civilian Executive Branch), la Binding Operational Directive 26-04 della CISA richiede di dare rapida priorità alle vulnerabilità del catalogo KEV presenti su asset esposti pubblicamente, dove lo sfruttamento consente il controllo totale, e stabilisce le aspettative per verificare se una compromissione sia avvenuta prima dell'applicazione della patch. The Hacker News riporta una scadenza di correzione al 12 novembre per queste aggiunte; tale data riguarda le agenzie civili federali. La CISA incoraggia le altre organizzazioni a dare priorità alla correzione delle vulnerabilità KEV attraverso una gestione delle vulnerabilità basata sul rischio.
