Sangoma Switchvox sotto attacco: SQL injection critica consente l’esecuzione di codice da remoto

CVE-2026-9586 è già sfruttata e impone una risposta immediata

Una vulnerabilità critica di Sangoma Switchvox viene sfruttata in attacchi reali contro sistemi esposti. La falla, identificata come CVE-2026-9586, permette a un aggressore remoto e privo di credenziali di inviare una singola richiesta manipolata e impartire comandi al database PostgreSQL dell’applicazione.

L’attività ostile è stata rilevata da Horizon3, che ha pubblicato anche indicatori di compromissione per aiutare le organizzazioni a verificare eventuali intrusioni. Il contenuto preciso di questi IoC non è noto, ma la loro disponibilità rende opportuno integrarli nelle attività di threat hunting.

CISA ha inserito CVE-2026-9586 nel catalogo Known Exploited Vulnerabilities (KEV) il 2 settembre 2026. Per le agenzie federali statunitensi, la scadenza di remediation è il 5 settembre 2026.

Non si tratta dunque di una vulnerabilità soltanto teorica. Le installazioni raggiungibili da Internet, soprattutto se ancora eseguono una versione vulnerabile, devono essere considerate potenzialmente compromesse e sottoposte anche ad analisi forense.

Il campo CISA relativo all’impiego in campagne ransomware è impostato su “Unknown”. Non esiste quindi un collegamento accertato con operazioni ransomware, ma il dato non consente neppure di escluderlo. CISA richiede espressamente il forensic triage previsto dalla direttiva BOD 26-04.

La richiesta XML che trasforma PhoneIP in una SQL injection

Il difetto si trova nell’endpoint /pa di Switchvox, incaricato di elaborare contenuti XML il cui elemento iniziale è <PolycomIPPhone>. All’interno della richiesta, il valore controllabile dall’utente PhoneIP viene inserito nelle query PostgreSQL senza un’adeguata neutralizzazione e senza parametrizzazione.

Un aggressore può quindi costruire un documento XML nel quale PhoneIP contiene sintassi SQL. Quando Switchvox elabora la richiesta, il contenuto ostile confluisce direttamente nell’istruzione inviata al database.

L’attacco presenta condizioni particolarmente favorevoli:

• può essere condotto attraverso la rete;
• non richiede autenticazione;
• ha bassa complessità;
• non dipende dall’interazione di un utente;
• può essere completato con una sola richiesta appositamente preparata.

L’accesso arbitrario a PostgreSQL permette di leggere o modificare informazioni, alterare il funzionamento dell’applicazione e compromettere disponibilità, integrità e riservatezza dei dati. In determinate condizioni, la catena può arrivare all’esecuzione di codice da remoto sul sistema interessato.

La classificazione è CWE-89, relativa alla mancata neutralizzazione degli elementi speciali inseriti in un comando SQL. Il punteggio NVD è CVSS 3.1 pari a 9.8, con vettore:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Un resoconto giornalistico attribuisce invece alla falla un punteggio di 9.3. Il valore tecnico dell’advisory NVD è 9.8, ma la divergenza resta da tenere presente quando si confrontano scanner, bollettini e sistemi di prioritizzazione.

Quali versioni aggiornare e quale build controllare per prima

La definizione NVD considera vulnerabili le versioni di Sangoma Switchvox precedenti alla 8.4.0.2. La scheda menziona in modo specifico anche Switchvox SMB Edition 8.3, build 104997.

La versione 8.4.0.2, pubblicata il 14 luglio 2026, è il riferimento da verificare per la correzione. Gli amministratori dovrebbero quindi aggiornare almeno a questa release, dopo avere controllato compatibilità, backup e indicazioni operative di Sangoma.

La sola installazione della patch non basta per i sistemi esposti. Poiché CVE-2026-9586 è già stata sfruttata, un aggiornamento può chiudere il punto d’ingresso senza rivelare che un attaccante lo abbia utilizzato in precedenza.

Le organizzazioni dovrebbero censire immediatamente gli appliance Switchvox, includendo eventuali istanze dimenticate, ambienti di test e interfacce pubblicate attraverso NAT o reverse proxy. Se non esistono mitigazioni praticabili, CISA indica di interrompere l’uso del prodotto.

Non sono stati resi noti workaround specifici alternativi all’aggiornamento. In assenza di una misura ufficiale, limitare l’accesso di rete può ridurre l’esposizione, ma non sostituisce la correzione né l’analisi di una possibile compromissione.

Cosa cercare nei log e nel database PostgreSQL

Il triage dovrebbe partire dalle richieste HTTP indirizzate a /pa, concentrandosi sui payload XML contenenti <PolycomIPPhone>. È necessario analizzare con particolare attenzione valori anomali o inattesi associati a PhoneIP.

Tra gli elementi da ricercare rientrano:

• richieste insolite verso /pa, soprattutto da indirizzi IP mai osservati;
• caratteri e costrutti SQL all’interno del valore PhoneIP;
• errori PostgreSQL coincidenti con chiamate all’endpoint vulnerabile;
• query non coerenti con il normale funzionamento di Switchvox;
• modifiche inattese a tabelle, utenti, privilegi o configurazioni;
• processi, file e connessioni di rete non riconducibili all’attività ordinaria;
• indicatori pubblicati da Horizon3.

La presenza di payload sospetti non dimostra automaticamente l’avvenuta esecuzione di codice, ma richiede una correlazione con log applicativi, database, sistema operativo e dispositivi perimetrali. Vanno inoltre preservate le evidenze prima di riavviare o reinstallare l’appliance.

CISA chiede di valutare l’esposizione Internet di ogni asset, applicare le mitigazioni del produttore e rispettare le prescrizioni BOD 26-04. Per Switchvox e gli altri prodotti soggetti al requisito, il forensic triage è parte della remediation, non un’attività facoltativa successiva.

Lo stesso aggiornamento KEV comprende altre sei falle sfruttate

Il 2 settembre 2026 CISA ha aggiunto al KEV altre sei vulnerabilità insieme a quella di Switchvox. Quattro condividono la scadenza del 5 settembre 2026:

• CVE-2026-82329, CVSS 9.8, riguarda JFrog Artifactory e può consentire a un attaccante non autenticato di ottenere privilegi amministrativi nella configurazione predefinita.
• CVE-2026-83548, CVSS 10.0, è una server-side request forgery negli appliance SonicWall SMA1000, sfruttabile senza autenticazione.
• CVE-2026-83549, CVSS 7.8, interessa ancora SMA1000 e consente command injection a un aggressore autenticato come amministratore.
• CVE-2026-49869, CVSS 10.0, colpisce Kestra OSS. Un controllo per suffisso nel componente AuthenticationFilter permette di aggirare la Basic Auth e creare workflow arbitrari. L’esecuzione di plugin shell o Python può trasformare il bypass in esecuzione di comandi. L’elenco NVD indica kestra < 1.0.45, mentre la descrizione cita come corrette le versioni 1.0.45 e 1.3.21.

Per queste vulnerabilità CISA richiede anche il triage forense, incluse le due falle SonicWall, Kestra e Switchvox.

Le altre due hanno scadenza il 16 settembre 2026:

• CVE-2026-48710, CVSS 6.5, interessa Starlette e diversi prodotti Red Hat. Un header Host manipolato può produrre una discrepanza tra il percorso HTTP reale e request.url.path, aggirando controlli basati sull’URL ricostruito. NVD elenca encode starlette < 1.0.1, ma la descrizione raccomanda una versione almeno pari a 1.0: le indicazioni non sono perfettamente allineate. CISA segnala inoltre una possibile concatenazione con CVE-2026-42271, presente nel KEV dall’8 giugno 2026, con scadenza fissata al 22 giugno 2026.
• CVE-2026-59822, CVSS 8.2, riguarda LiteLLM prima della 1.84.0. Un token Bearer contraffatto può attivare un fallback OAuth2 e raggiungere gli strumenti MCP senza una chiave LiteLLM valida. La correzione è nella versione 1.84.0.

Per Starlette, lo sfruttamento sarebbe iniziato a maggio; la vulnerabilità Kestra è stata divulgata a giugno, mentre tentativi contro LiteLLM sono stati osservati di recente in honeypot. Negli ultimi 90 giorni sono inoltre entrate nel KEV CVE-2015-5287 e CVE-2015-3246, il 26 agosto 2026, e CVE-2026-34486, il 4 agosto 2026, associate agli stessi ecosistemi vendor Red Hat, LiteLLM ed Encode.

Per gli amministratori Switchvox, tuttavia, la priorità resta netta: aggiornare almeno alla 8.4.0.2, controllare l’esposizione dell’endpoint /pa ed eseguire subito il triage forense. La patch chiude la falla. Solo l’analisi può stabilire se sia già stata usata.