Switchvox ciblé par une attaque : une injection SQL critique installe un reverse shell sans identifiants

Des acteurs malveillants exploitent CVE-2026-9586, une vulnérabilité critique de Sangoma Switchvox SMB Edition qui permet de compromettre le serveur au moyen d’une seule requête, sans authentification.

Horizon3.ai a détecté des tentatives d’exploitation réussies à partir du 30 août 2026. Les attaques observées sur les honeypots ne se sont pas limitées à vérifier la présence de la faille : elles ont installé un reverse shell et exécuté des commandes encodées en Base64 afin d’énumérer les processus actifs.

La vulnérabilité affiche un score de 9,3 sur 10 selon le CVSS et un correctif est déjà disponible. Les administrateurs qui gèrent des systèmes Switchvox exposés sur Internet doivent considérer comme urgentes la mise à jour et la recherche d’éventuelles traces de compromission.

Quelles versions de Switchvox sont vulnérables

CVE-2026-9586 concerne Sangoma Switchvox SMB Edition 8.3 (104997). La fiche officielle de la CVE considère comme vulnérables toutes les versions comprises entre cette version et les versions antérieures à la 8.4.0.2.

La version corrective est donc :

• Switchvox SMB Edition 8.4.0.2

Sangoma a publié cette version le 14 juillet 2026. La CVE a ensuite été rendue publique le 17 juillet 2026, sans autre mise à jour enregistrée depuis cette date.

La mise à jour constitue la mesure d’atténuation officielle disponible. Aucun contournement spécifique permettant de neutraliser la vulnérabilité tout en conservant une version antérieure en production n’a été indiqué.

Horizon3.ai estime qu’environ 4 000 instances Switchvox sont directement accessibles depuis Internet, principalement aux États-Unis. Ce chiffre n’est pas confirmé par les fiches CVE ou NVD, mais il donne une indication de la surface d’exposition potentielle.

Pour un système VoIP d’entreprise, les conséquences peuvent dépasser le périmètre de la téléphonie. Switchvox peut devenir un point d’accès à la base de données, à l’interface d’administration et au serveur applicatif sous-jacent.

La valeur PhoneIP se retrouve dans les requêtes PostgreSQL

La vulnérabilité se situe dans le point de terminaison /pa, utilisé pour traiter des contenus XML initiaux contenant l’élément <PolycomIPPhone>.

Au cours de ce traitement, la valeur PhoneIP, contrôlable par le client, est insérée directement dans les requêtes adressées à la base de données PostgreSQL. L’application n’applique pas une sanitisation suffisante et n’utilise pas correctement les requêtes paramétrées.

Un attaquant peut donc construire une requête qui modifie la syntaxe SQL attendue par l’application. Aucun identifiant, aucune session active ni interaction de l’utilisateur ne sont nécessaires.

Une seule requête spécialement conçue peut permettre de :

• exécuter des instructions SQL arbitraires ;
• lire ou modifier les données stockées ;
• manipuler les comptes et les privilèges ;
• passer de l’accès à la base de données à l’exécution de code sur le serveur.

Horizon3.ai indique que le code peut être exécuté avec les privilèges du superutilisateur PostgreSQL. Ce niveau de privilège précis ne figure pas dans les informations disponibles auprès de la NVD et de la CVE, qui confirment néanmoins la possibilité d’aboutir à une exécution de code à distance.

La vulnérabilité est classée CWE-89, qui concerne la non-neutralisation des éléments spéciaux insérés dans une commande SQL. Le CNA responsable de la fiche est Security Risk Advisors.

Le vecteur complet est :

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

L’évaluation CVSS 4.0 décrit une attaque réalisable via le réseau, de faible complexité, sans prérequis technique, privilèges ni action de la victime. Les impacts sur le système vulnérable sont élevés en matière de confidentialité, d’intégrité et de disponibilité.

De l’extraction de la base de données à la falsification des sessions

Les chercheurs de Security Risk Advisors Labs ont démontré une chaîne de compromission qui va bien au-delà d’une simple consultation abusive de la base de données.

Grâce à CVE-2026-9586, ils ont réussi à extraire le contenu de PostgreSQL, à modifier les enregistrements des utilisateurs et à obtenir des privilèges équivalents à ceux des administrateurs Web de Switchvox. Ils ont également exécuté du code arbitraire et ouvert un reverse shell sur la machine ciblée.

Un autre scénario concerne la clé utilisée par Switchvox pour signer les cookies de session. La vulnérabilité permet de la dérober et de la transférer vers un serveur externe.

Une fois la clé obtenue, un attaquant peut créer du matériel d’authentification apparemment valide pour des utilisateurs choisis arbitrairement. Le simple changement des mots de passe peut donc s’avérer insuffisant après une compromission : il faut également vérifier l’intégrité de la clé de signature et des sessions existantes.

Les attaques interceptées par les honeypots montrent que ces capacités ne sont pas uniquement théoriques. Les charges utiles ont tenté d’installer des reverse shells, créant un canal distant persistant ou interactif vers le système compromis.

Des commandes en Base64 destinées à énumérer les processus ont également été observées. Cet encodage ne constitue pas un chiffrement, mais il peut rendre l’analyse des commandes moins immédiate dans les journaux ou lors de contrôles reposant sur de simples correspondances textuelles.

Indicateurs à rechercher sur les systèmes exposés

L’une des adresses associées aux tentatives observées est :

176.65.148[.]184

Cette adresse IP est également signalée sur VirusTotal pour des activités de scan de ports, de brute force et d’exploitation de vulnérabilités. Elle ne doit pas être considérée comme un indicateur exhaustif : d’autres attaquants peuvent utiliser des infrastructures différentes.

Sur les appareils dont l’accès SSH est activé, les traces des charges utiles SQL peuvent être recherchées dans le fichier :

/var/log/switchvox/db-quirks.log

Les administrateurs doivent au minimum examiner les éléments suivants :

1. les requêtes anormales vers le point de terminaison /pa ;
2. les contenus XML suspects associés à <PolycomIPPhone> ;
3. les valeurs inhabituelles ou la syntaxe SQL présente dans le paramètre PhoneIP ;
4. les connexions provenant de ou à destination de 176.65.148[.]184 ;
5. les shells, processus ou services inattendus lancés par le serveur ;
6. les commandes encodées en Base64, en particulier lorsqu’elles sont liées à l’énumération des processus ;
7. les modifications récentes et non autorisées de comptes ou de privilèges administratifs ;
8. les connexions sortantes incompatibles avec le fonctionnement normal du central téléphonique ;
9. les éventuels accès, exports ou remplacements de la clé de signature des cookies.

L’apparition rapide de la même adresse IP contre plusieurs honeypots indique une activité automatisée. Selon le chercheur Zach Hanley, il est donc probable que de nombreuses instances accessibles publiquement aient déjà été analysées ou puissent l’être prochainement.

L’absence de connexion avec l’adresse IP connue ne prouve pas que le système est sain. La vérification doit couvrir l’application, la base de données, les comptes administratifs, les processus du système d’exploitation et le trafic réseau.

Mettre à jour ne suffit pas si l’exploitation a déjà réussi

La première mesure consiste à mettre immédiatement Switchvox à jour vers la version 8.4.0.2. Toutes les installations allant de la 8.3 (104997) aux versions antérieures au correctif doivent être considérées comme vulnérables.

Les instances non mises à jour et directement accessibles depuis Internet doivent être traitées en priorité. Si la mise à jour ne peut pas être appliquée immédiatement, aucun contournement documenté n’étant disponible, il faut au minimum réduire l’exposition publique au moyen de contrôles réseau adaptés aux besoins opérationnels.

Après l’installation du correctif, une intervention de réponse à incident reste nécessaire. Le correctif empêche les nouvelles tentatives exploitant la faille, mais il ne supprime pas les reverse shells, les comptes modifiés ni les autres changements déjà introduits.

En présence d’indicateurs suspects, il est recommandé d’isoler le système, de conserver les journaux et de vérifier l’intégrité de la base de données. Les administrateurs Web, les sessions actives et la clé utilisée pour signer les cookies doivent également être contrôlés.

Les informations disponibles n’indiquent pas l’ajout de CVE-2026-9586 au catalogue Known Exploited Vulnerabilities de la CISA, et aucune échéance fédérale de correction n’y est associée. Aucun élément suffisant ne permet non plus de relier ce cas à d’autres ajouts récents au catalogue KEV concernant Sangoma.

L’absence d’une échéance documentée de la CISA ne réduit toutefois pas l’urgence technique. L’exploitation a été observée concrètement et permet d’aboutir à une exécution de code sans identifiants. Pour les installations exposées, CVE-2026-9586 doit être traitée comme une compromission potentielle, et non comme une vulnérabilité purement théorique.