CVE-2026-9586 : un XML de téléphone Polycom suffit pour devenir superutilisateur PostgreSQL sur Switchvox

Rapport CTI technique du 4 septembre 2026

Résumé exécutif

Sangoma Switchvox, plateforme de téléphonie sur IP déployée en PME et en entreprise, contient une injection SQL non authentifiée référencée CVE-2026-9586 et notée 9.3 en CVSS. Le point d'entrée est l'endpoint /pa, celui qui traite les requêtes de provisionnement de téléphones. Quand le contenu XML commence par la balise <PolycomIPPhone>, la valeur PhoneIP fournie par le client est concaténée directement dans une requête PostgreSQL, sans paramétrage ni assainissement. Une seule requête forgée suffit pour exécuter des instructions SQL arbitraires en tant que superutilisateur de la base, ce qui ouvre la voie à une exécution de code sur le serveur.

Le correctif existe depuis le 14 juillet 2026 avec Switchvox 8.4.0.2. Horizon3.ai observe des tentatives d'exploitation valides en conditions réelles depuis le 30 août 2026, soit six semaines après la disponibilité du patch, et la CISA a inscrit la référence à son catalogue KEV le 2 septembre. Environ 4 000 instances sont exposées sur Internet, majoritairement aux États-Unis. Les tentatives observées sur les pots de miel Horizon3 déposent des shells inverses, puis exécutent des commandes encodées en base64 pour énumérer les processus en cours. La même faille avait été trouvée indépendamment par SRA Labs en mai 2026, qui a démontré l'extraction de la clé de signature des cookies : de quoi forger du matériel d'authentification pour n'importe quel utilisateur, sans même passer par le shell.

Chronologie

Fiche vulnérabilité

CVE-2026-9586 | CVSS 9.3 | Sangoma Switchvox SMB Edition 8.3 (build 104997)

Injection SQL non authentifiée. L'endpoint /pa traite du contenu XML commençant par <PolycomIPPhone> et concatène directement la valeur PhoneIP, contrôlée par le client, dans des requêtes PostgreSQL, sans assainissement ni paramétrage. Le motif relève de CWE-89 (Improper Neutralization of Special Elements used in an SQL Command).

Le contexte d'exécution est ce qui fait passer la faille de sérieuse à critique : la requête tourne avec les droits de superutilisateur PostgreSQL. À ce niveau de privilège, l'injection ne se limite pas à la lecture de données. Elle permet l'écriture, la modification d'enregistrements utilisateurs, l'élévation vers un compte administrateur web Switchvox, et l'exécution de code sur l'hôte par les mécanismes natifs du moteur de base.

Conditions d'exploitation : une seule requête HTTP vers /pa, aucun identifiant, aucune interaction utilisateur. L'endpoint de provisionnement est joignable par construction sur les déploiements où les téléphones s'approvisionnent depuis l'extérieur.

PoC disponible : pas de code d'exploitation complet publié, mais la description technique est suffisamment précise pour une reproduction rapide, et deux équipes de recherche indépendantes (Horizon3.ai et SRA Labs) ont publié leurs analyses avec captures de requête. Exploitation confirmée en conditions réelles depuis le 30 août 2026.

Patch : Switchvox 8.4.0.2, publié le 14 juillet 2026 (notes de version Sangoma).

Diagramme de la chaîne d'attaque

Chaîne reconstruite à partir de l'analyse Horizon3.ai du 2 septembre 2026, des publications SRA Labs de mai 2026 et de la description CVE.org.

Analyse technique

Étape 1 : un endpoint de provisionnement qui fait confiance à son client

Les plateformes de téléphonie exposent presque toutes un service de provisionnement automatique : le téléphone démarre, se signale, reçoit sa configuration. Sur Switchvox, /pa remplit ce rôle. Le traitement fait un aiguillage sur la racine du document XML, et le cas <PolycomIPPhone> conduit à une branche de code qui utilise PhoneIP pour retrouver ou créer l'enregistrement du poste.

L'hypothèse implicite du développeur est visible : PhoneIP est une adresse IP, une adresse IP a une forme fixe, donc la concaténer dans une requête ne pose pas de problème. Rien dans le code ne vérifie cette hypothèse. Un client HTTP arbitraire n'est pas un téléphone Polycom, et rien n'oblige la valeur à ressembler à une adresse.

Étape 2 : de l'injection au superutilisateur

L'écart entre une injection SQL classique et celle-ci tient au compte de connexion. La plupart des applications web se connectent à leur base avec un rôle restreint au schéma applicatif. Switchvox se connecte en superutilisateur PostgreSQL. Dans ce contexte, l'attaquant hérite de tout : lecture et écriture sur l'ensemble des bases, accès aux fonctions système, chargement d'extensions natives, et écriture de fichiers via les mécanismes serveur du moteur.

SRA Labs décrit précisément ce que cela donne en pratique : opérations arbitraires sur la base, extraction du contenu, modification des enregistrements utilisateurs, élévation vers un compte administrateur web Switchvox, et exécution de code sur le serveur avec obtention d'un shell inverse.

Étape 3 : la variante sans shell, plus discrète

Le scénario le plus intéressant pour un red teamer n'est pas le shell. SRA Labs a montré l'exfiltration de la clé de signature des cookies vers un serveur externe. Avec cette clé, un attaquant forge du matériel d'authentification valide pour n'importe quel utilisateur, y compris administrateur, sans jamais exécuter de commande sur l'hôte.

Cette voie contourne toute détection basée sur l'apparition de processus enfants anormaux ou sur la surveillance d'exécution. Du point de vue des journaux applicatifs, l'attaquant se connecte simplement avec une session valide. Sur un système de téléphonie, l'accès administrateur donne ensuite la configuration des trunks SIP, l'interception ou le renvoi d'appels, l'accès aux messageries vocales et aux enregistrements, et une base d'annuaire interne exploitable en reconnaissance sociale.

Étape 4 : ce que font réellement les attaquants observés

Les tentatives capturées par les pots de miel Horizon3.ai suivent un schéma simple : déploiement d'un shell inverse sur le système compromis, puis exécution de commandes encodées en base64 pour énumérer les processus en cours. L'encodage base64 sert ici à passer sous les filtres naïfs sur les chaînes de commande, pas à chiffrer quoi que ce soit.

Le chercheur Zach Hanley note que les tentatives se succèdent rapidement sur plusieurs pots de miel depuis la même IP source, et estime probable que la plupart des instances Switchvox exposées sur Internet aient déjà été ciblées, ou le seront. Avec environ 4 000 systèmes joignables et un délai d'exploitation d'une seule requête, l'hypothèse est raisonnable.

Étape 5 : la fenêtre de six semaines

Le correctif est disponible depuis le 14 juillet. L'exploitation démarre le 30 août. Entre les deux, six semaines pendant lesquelles la description publique de la faille et les notes de version permettaient de reconstruire le vecteur par différentiel. Ce délai n'a rien d'exceptionnel : il correspond au temps qu'il faut pour qu'un correctif public devienne un exploit fonctionnel entre les mains d'opérateurs qui n'ont pas trouvé la faille eux-mêmes.

Concrètement, la fenêtre utile de correction sur un équipement exposé se compte en jours. Les parcs de téléphonie IP en PME suivent rarement ce rythme, et les 12 vulnérabilités signalées par Horizon3.ai en avril suggèrent que la surface Switchvox mérite un examen plus large que cette seule référence.

Indicateurs de compromission

Le fichier db-quirks.log est l'artefact le plus exploitable pour une chasse rétrospective : il n'est pas destiné à la sécurité, mais il enregistre les anomalies de requête, donc la trace du payload y subsiste.

MITRE ATT&CK

Aucune cartographie ATT&CK officielle n'a été publiée par Sangoma, Horizon3.ai ou la CISA pour cette exploitation. Le tableau ci-dessous est notre lecture technique construite à partir des comportements confirmés dans les analyses Horizon3.ai et SRA Labs.

Remédiation : checklist opérationnelle

1. Mettre à jour vers Switchvox 8.4.0.2 ou supérieur sans délai. C'est le seul correctif, aucun contournement de configuration n'a été publié.
2. Retirer l'endpoint /pa d'Internet si le provisionnement des postes se fait exclusivement en interne. Une restriction par liste d'adresses en amont du service coupe le vecteur même sur une version vulnérable.
3. Rechercher la trace de l'injection dans /var/log/switchvox/db-quirks.log sur les instances où l'accès SSH est disponible, en remontant au minimum au 30 août 2026.
4. Bloquer et rechercher 176.65.148[.]184 dans les journaux de pare-feu et de proxy.
5. Considérer toute instance restée exposée et non patchée après le 30 août comme potentiellement compromise, et non comme simplement vulnérable.
6. En cas de suspicion : régénérer la clé de signature des cookies, forcer l'expiration de toutes les sessions actives, et réinitialiser les mots de passe des comptes administrateurs web. Une clé de signature volée reste exploitable tant qu'elle n'est pas remplacée.
7. Auditer les comptes administrateurs Switchvox à la recherche d'ajouts ou de modifications de privilèges non tracés dans les procédures de changement.
8. Vérifier la configuration des trunks SIP et des règles de renvoi d'appel, cibles classiques après compromission d'un système de téléphonie (fraude à la terminaison, interception).
9. Restreindre les privilèges du compte de connexion applicatif à PostgreSQL. Le rôle superutilisateur pour une application web est ce qui transforme cette injection en compromission d'hôte.
10. Étendre l'examen au-delà de cette CVE : Horizon3.ai a signalé 12 vulnérabilités distinctes dans Switchvox en avril 2026, dont toutes ne sont pas nécessairement corrigées ni publiées.

Sources

• The Hacker News, Attackers Exploit Critical Switchvox Flaw to Deploy Reverse Shells Without Credentials
• Horizon3.ai, CVE-2026-9586 Sangoma Switchvox RCE
• SRA Labs, Switchvox research
• SRA Labs, Switchvox post-exploitation
• Sangoma, Switchvox Release Notes Version 8.4.0.2 (14 juillet 2026)
• CVE.org, CVE-2026-9586
• CISA, Adds Seven Known Exploited Vulnerabilities to Catalog (2 septembre 2026)
• The Hacker News, CISA Adds Seven Exploited Flaws as Attackers Deploy Reverse Shells and Crypto Miners