FreeSWITCH : un simple message SIP suffit à exécuter des commandes sur le serveur, la faille est exploitée

Veille cyber Top-Secured : analyse indépendante fondée sur les sources citées plus bas. Top-Secured n'est pas affilié aux entreprises mentionnées et ne vous demandera jamais vos identifiants bancaires ni vos mots de passe.

Une faille de FreeSWITCH, le serveur de téléphonie open source, permet à une requête SIP MESSAGE d’exécuter des commandes sur la machine, et ce dans la configuration par défaut. Les mainteneurs signalent une exploitation et la CISA a inscrit la CVE-2026-116779 à son catalogue des vulnérabilités exploitées le 9 novembre 2026 ; la version 1.11.3 corrige le problème.

Ce qui s’est passé

Les mainteneurs de FreeSWITCH ont publié le 28 octobre 2026 un avis de sécurité sur la CVE-2026-116779, une faille de ce serveur de téléphonie open source qui fait tourner des IPBX, des centres d’appels et des passerelles SIP. L’avis lui attribue la note de 9,8 sur 10 et indique que des exploitations ont été observées. Le 9 novembre, l’agence américaine CISA l’a ajoutée à son catalogue des vulnérabilités activement exploitées : les administrations fédérales ont jusqu’au 12 novembre pour agir et doivent mener une vérification de compromission.

Comment les attaquants entrent

Quand FreeSWITCH reçoit un SIP MESSAGE, la requête de messagerie instantanée du protocole SIP, il lit le nom du destinataire pour choisir le module de chat chargé de la remettre. L’un de ces modules, baptisé api, transmet directement son contenu à l’interpréteur de commandes de FreeSWITCH. L’attaquant choisit donc la commande et la fait exécuter avec les droits du processus FreeSWITCH : commandes système, lecture de la configuration et des mots de passe, passage d’appels. Si le module Lua est chargé, comme dans la configuration d’origine, du code Lua arbitraire passe aussi.

La configuration par défaut est exposée : le chat est actif sur les profils internal et external, et l’ACL entrante ne filtre pas ces messages. Si l’authentification des messages est exigée, un seul compte SIP, un poste ou un trunk, suffit. Les serveurs qui ont gardé l’utilisateur d’exemple default, sans mot de passe, n’en demandent même aucun.

Toutes les versions jusqu’à la 1.11.2 sont touchées. La 1.11.3 ajoute le paramètre enable-chat-api-proto, désactivé par défaut : ces messages sont alors rejetés par un 403 et journalisés.

Que faire maintenant

1. Vérifiez la version avec fs_cli -x version et passez en 1.11.3 ou plus récent.
2. En attendant, réglez enable-chat sur false dans chaque profil SIP qui n’a pas besoin du chat entrant. L’authentification des messages ou disable_system_api_commands réduisent le risque sans fermer la brèche.
3. Supprimez les utilisateurs sans mot de passe de l’annuaire : la configuration vanilla en livre deux, default et l’exemple Skinny.
4. Cherchez des traces : requêtes SIP MESSAGE dont le destinataire commence par api+ dans vos journaux ou captures, processus inconnus lancés par l’utilisateur freeswitch, fichiers modifiés récemment. Au moindre doute, changez les mots de passe SIP et des trunks.
5. Restreignez les ports SIP aux adresses de votre opérateur et de vos sites plutôt qu’à tout Internet.

Notre avis

Un serveur de téléphonie est un serveur comme les autres, souvent installé une fois puis oublié. Inscrivez-le dans votre inventaire et votre cycle de mises à jour, et retirez comptes d’exemple et fonctions inutilisées : ici, une messagerie dont personne ne se servait suffisait à livrer la machine.

Sources

• FreeSWITCH (GitHub) — Inbound SIP MESSAGE can select the api chat proto and run FreeSWITCH API commands (GHSA-mg63-h38w-8p9p)
• CISA — Known Exploited Vulnerabilities Catalog: CVE-2026-116779 (SignalWire FreeSWITCH)

Comment nous choisissons, vérifions et rédigeons nos analyses →