La faille du raccrochage de Signal était corrigée avant d’être publiée

Un interlocuteur malveillant, en plein appel Signal, pouvait faire en sorte que le bouton rouge de sa victime ne coupe plus rien : le micro, et peut-être la caméra, continuaient d’émettre vers lui alors que l’autre croyait avoir raccroché. C’est ce que décrit la fiche CVE-2026-113380, le numéro attribué à la faille dans le catalogue mondial des vulnérabilités, publiée le 20 octobre avec une note de 9,3 sur 10, « critique ». Pour qui tient son application à jour, le problème est pourtant réglé depuis plusieurs semaines : la correction est dans le code de Signal depuis le 4 septembre, et dans les trois applications grand public depuis le 1^er octobre au plus tard.

Un raccrochage qui attend son tour

La faille ne touche pas le chiffrement des conversations. Elle se trouve dans RingRTC, la bibliothèque de logiciel libre que Signal a écrite pour ses appels audio et vidéo, et que partagent ses applications Android, iPhone et ordinateur. Pendant un appel, chaque événement (un message de l’autre participant, un changement de réseau, l’appui sur « raccrocher ») est rangé dans une file d’attente, puis traité dans l’ordre par un automate, la « machine à états » qui fait passer l’appel d’une étape à l’autre.

Le déclarant de la faille, qui publie sur GitHub sous le nom d’Imahian, résume le défaut d’une phrase : « Raccrocher n’est pas un interrupteur d’arrêt : c’est juste un événement de plus, placé au bout de la file d’événements de l’appel. » Si l’autre participant remplit cette file d’événements sans intérêt, la demande de raccrocher attend derrière eux, et l’appel n’est jamais démonté.

Signal ne l’a pas formulé autrement. Le correctif du 4 septembre, signé par Jim Gustafson, développeur de Signal, s’intitule sobrement « S’assurer que les appels se terminent complètement dans les cas limites ». Mais l’un des tests qu’il ajoute porte un commentaire sans ambiguïté : « Un participant qui inonde la file d’événements de l’appel ne doit pas pouvoir empêcher un raccrochage local de démonter l’appel. » La parade ne consiste pas à trier la file : la demande d’arrêt est désormais signalée à part, vérifiée après chaque événement traité, et les attentes de fermeture sont limitées à cinq secondes, au lieu de pouvoir durer indéfiniment. Ce correctif est entré dans RingRTC 2.72.0, publiée le même jour.

Les versions qui embarquent la correction

Signal n’a publié ni billet ni avis de sécurité : son blog n’en dit rien au 23 octobre, et la note de la version pour ordinateur qui a apporté le correctif se contente d’« autres petits ajustements, corrections de bogues et améliorations de performances ». Le 20 octobre, CyberInsider avait demandé à Signal quelles versions étaient touchées, sans réponse à la publication de son article.

Nous avons donc lu, dans les dépôts publics de chaque application, le fichier qui fixe la version de RingRTC utilisée par chaque version publiée. La date d’intégration sur la branche de développement ne suffit pas : les versions sont préparées sur des branches à part, et la correction y arrive plus tard.

Ces dates sont celles des versions dans le code. Sur iPhone, l’historique de l’App Store date la version 8.30 du 23 septembre ; Google Play ne publie pas le sien. La version 8.29 pour iPhone, finalisée le 15 septembre, utilisait encore l’ancienne bibliothèque alors que le changement avait été intégré au développement le 9. Sur ordinateur, la version 8.28.0 du 23 septembre ne l’avait pas non plus ; seule la bêta du même jour en bénéficiait.

En pratique, il suffit de vérifier dans la boutique d’applications (Google Play, App Store) ou dans le gestionnaire de mises à jour qu’aucune mise à jour de Signal n’attend. Les versions courantes sont bien au-delà : 8.33 sur Android, 8.34 sur iPhone, 8.32 sur ordinateur, d’après les dépôts au 23 octobre.

Une note « critique » qui ne dit pas tout

Le 9,3 n’a pas été calculé par l’Institut américain des normes (NIST), qui tient la base de référence des failles : sa fiche est toujours « en attente d’analyse ». La note accompagne la fiche enregistrée par MITRE, l’organisme américain qui attribue les numéros CVE « en dernier recours », quand aucun autre organisme habilité ne couvre le logiciel, sur simple formulaire. L’enregistrement montre que le numéro a été réservé et publié à moins d’une seconde d’intervalle, le 20 octobre à 4 h 25 (heure universelle), et la note du déclarant a été mise en ligne une heure plus tard. Rien n’y indique comment la faille a été trouvée, ni si Signal en avait été informé avant de la corriger. Le schéma rappelle celui de Telegram Desktop, dont la faille avait reçu son numéro trois semaines après un correctif passé sans annonce.

Le score CVSS (la grille commune de gravité, de 0 à 10) suppose ici une attaque à distance, sans compte ni droit particulier et avec une interaction « limitée » de la victime. C’est exact sur le papier, mais trompeur en pratique : la seule « interaction » requise est un appel déjà établi avec l’attaquant, que la victime a passé ou accepté. Le déclarant le dit lui-même, sa démonstration commence par « L’attaquant lance un appel Signal ordinaire avec la victime ». Le vecteur attribue aussi un impact élevé sur l’intégrité des données, que ni la fiche ni la note n’expliquent : l’attaquant entend ce qu’il ne devrait plus entendre, il ne modifie rien. La spécification CVSS 4.0 recommande d’ailleurs de croiser la note avec des éléments qu’elle ne mesure pas pour hiérarchiser les menaces.

Deux autres limites. La démonstration publiée par le déclarant est conceptuelle : un petit modèle de file d’attente qui tourne sans réseau ni appel réel, et non un outil d’attaque. Elle ne dit pas comment produire ce flot d’événements avec une application Signal ordinaire. Enfin, les tests ajoutés par Signal portent sur des appels sortants à deux ; ni la fiche ni le correctif ne disent si les appels de groupe étaient concernés.

Aucune exploitation n’a été signalée : Malwarebytes le 21 octobre et Help Net Security le 22 n’en connaissent pas, et Signal n’a rien communiqué.

Ce que le précédent de 2019 permet de mesurer

Signal a déjà connu une faille d’appel plus grave. En 2019, la chercheuse Natalie Silvanovich, de l’équipe Project Zero de Google, avait montré qu’un appelant pouvait forcer une réponse à l’appel sans que la personne appelée touche son téléphone ; Signal l’avait corrigée dans la version 4.47.7 pour Android, comme le racontait alors Next. Il suffisait alors d’appeler. En 2026, il faut avoir déjà obtenu la conversation, et seulement pour prolonger l’écoute au-delà du raccrochage.

Le conseil du déclarant reste de bon sens pour qui n’aurait pas mis à jour : après avoir raccroché, vérifier que l’indicateur d’appel a disparu avant de reprendre une conversation sensible. Pour les autres, la faille appartient déjà au passé de leur application. Ce qui reste ouvert tient à Signal : dire quelles versions étaient exposées, si les appels de groupe l’étaient aussi, et pourquoi un défaut que ses propres tests décrivaient le 4 septembre n’a été présenté comme une faille de sécurité que six semaines plus tard, par un tiers.

Les citations de l’anglais ont été traduites par la rédaction.