Des failles dans le protocole Matrix fragilisent les messageries sécurisées

Coup de froid sur Matrix après la découverte de deux failles dans le protocole de communication open source. La Fondation Matrix a indiqué dans un message que les vulnérabilités ont été découvertes il y a un mois, mais les informations sur les mesures d’atténuation ont été gardées secrètes pour laisser le temps aux utilisateurs du protocole de les tester et de les appliquer. Matrix sert de base à des messageries sécurisées en particulier Tchap en France dédié au secteur public. Elle a été consacrée cet été par le Premier ministre pour devenir la seule messagerie utilisable dans les ministères. Matrix sert par ailleurs aux forces armées allemandes et polonaises.

Selon Erik Avakian, conseiller technique chez Info-Tech Research Group et ancien responsable de la sécurité informatique de l'État de Pennsylvanie, « il apparaît que dans différentes entreprises, les serveurs Matrix sont fréquemment connectés à d'autres serveurs ». Et d’ajouter « le piratage de l'un d'entre eux pourrait avoir des répercussions en aval et servir à attaquer d'autres serveurs ».

Le projet « Hydra », un effort continu de sécurité

Contrairement à WhatsApp ou à Signal qui sont basés sur le cloud, le standard ouvert Matrix est exécutable sur n’importe quel serveur. Utilisé par plusieurs entités gouvernementales européennes, « le protocole est assez populaire pour éviter les fournisseurs de cloud hébergés ou contrôlés par les Etats-Unis », rapporte Johannes Ullrich, doyen de la recherche au SANS Technology Institute. À la mi-juillet, Matrix a publié une pré-divulgation des deux vulnérabilités de haute gravité référencées CVE-2025-49090 et CVE-2025-54315 et communiqué les détails des correctifs sous embargo aux organisations utilisant le protocole. Au départ, la Fondation avait prévu six jours pour la mise en œuvre des changements, mais, face à l’inquiétude des utilisateurs qui ont estimé que ce délai était trop court, la Fondation l’a repoussé d'un mois.

Après la publication récente et coordonnée des correctifs, les administrateurs de serveurs ont eu trois jours pour effectuer la mise à niveau avant que Matrix ne divulgue les détails de la vulnérabilité. Et, Room Version 12 a été livrée le jeudi 14 août. « L'ensemble de ce processus est très inhabituel pour l'écosystème, et il est regrettable que nous n'ayons pas pu effectuer ces modifications au grand jour », a écrit Kegan Dougal, ingénieur chez Matrix, dans un article de blog. Dans le cadre d’un projet baptisé « Hydra », équipes de sécurité et les consultants de Matrix cherchent en permanence à améliorer la sécurité du protocole. Pendant la période d'embargo, la fondation a publié des versions expurgées des modifications apportées aux spécifications à Matrix (MSC) « dès que nous nous sommes sentis à l'aise sur le plan de la sécurité ». Erik Avakian a expliqué que les corrections et les mises à jour des directives comprennent notamment une modification dans la gestion des salles de discussion et la création des identifiants. « Si l’entreprise est connectée uniquement à son propre système (sans fédération), il n’y a rien à craindre », a-t-il précisé. « Si elle se connecte à d'autres serveurs, en particulier ceux auxquels elle ne peut pas faire entièrement confiance, elle doit mettre à jour les salles vers le nouveau format et s’assurer que ses applications de messagerie et ses bots sont également mis à jour afin qu'ils continuent à fonctionner. »

Des failles à gravité élevée

La Fondation a qualifié ces vulnérabilités d’« élevées » plutôt que de « critiques », car elles « n'entraînent pas de compromission ou d'exposition des données ». Matrix précise qu’à sa connaissance, ces failles n’ont pas été exploitées. Cependant, selon Erik Avakian, si ces deux failles graves ne sont pas corrigées immédiatement, elles pourraient donner la capacité à des pirates de perturber les conversations et les communications confidentielles. Par exemple, pour l’une des vulnérabilités, un acteur malveillant pourrait prendre le contrôle des actions réservées au « créateur » d'un salon de discussion, et apporter des modifications, rediriger les utilisateurs vers un autre salon ou fermer complètement le salon. Dans le cas de l’autre faille, le pirate pourrait prédire l'adresse d'une salle avant qu’elle ne soit ouverte par le créateur, ce qui pourrait semer la confusion ou des acteurs malveillants pourraient créer une fausse version d'une salle, pour y diffuser « des informations potentiellement erronées, inciter les gens à partager des informations ou simplement fermer des canaux de communication essentiels à l'entreprise ou pendant une crise ou un projet sensible », a-t-il mis en garde.

La Fondation Matrix a fourni de plus amples informations sur ces vulnérabilités. Denis Kasak, chercheur en sécurité et programmeur chez Matrix, a précisé que ces brèches ne peuvent être exploitées que par des serveurs (ou des opérateurs de serveurs) ayant déjà participé à la salle en question. Un attaquant réseau arbitraire ne peut pas les utiliser pour accéder à une salle, même si le serveur est autorisé à se fédérer avec d'autres serveurs. Il a également souligné que si la faille CVE-2025-49090 pouvait éventuellement autoriser un membre de la salle de réinitialiser l'état de la salle à une valeur antérieure, cela ne lui confère pas pour autant des privilèges d'administrateur ou de créateur. De plus, M. Kasak a indiqué que la faille CVE-2025-54315 posait un problème de sécurité « sans voie d'exploitation connue », et qu’elle a été corrigée à titre purement préventif. « Cela n'implique pas de prédire un identifiant de salle, et même si un futur identifiant de salle pouvait être deviné, les signatures cryptographiques empêchent d'autres serveurs de créer une fausse salle valide », a ajouté M. Kasak.

Des interdictions de MSC pour Room Version 12

Matrix a pris la « décision inhabituelle » d'interdire les MSC en raison du risque d'exploitation. Il s'agit notamment des MSC suivants :

• MSC4289 : précise explicitement que les créateurs de salles ont un pouvoir « infini ». « Le contrôle d'accès nécessite une hiérarchie, et le créateur se trouve au sommet de cette hiérarchie », a expliqué Matrix. Cela signifie également que les administrateurs peuvent promouvoir d'autres utilisateurs au même rang ou de se rétrograder eux-mêmes s'ils perdent le contrôle de leurs salles. « Si les créateurs deviennent malveillants ou disparaissent, la solution consiste à établir un nouveau créateur en mettant à niveau la salle ou en créant une autre salle. »

• MSC4291 : modifie le format des identifiants de salle afin qu'ils soient identiques à l'identifiant de l'événement. Selon Matrix, il s’agit d'une mesure de précaution pour prévenir une catégorie théorique d'attaques dans lesquelles des administrateurs malveillants introduisent de faux événements dans une salle afin de la détourner.

• MSC4297 : protège contre les « réinitialisations d'état » qui ramènent une salle à un état antérieur. Ces réinitialisations peuvent rajouter des utilisateurs à une salle qu'ils ont quittée, ou le serveur peut ne plus reconnaître les utilisateurs précédemment présents.

Ces MSC sont regroupés dans la version 12 de Room, dont la sortie officielle est prévue dans le courant du mois.

Une mise à jour immédiate et plus de vigilance à long terme

Il est conseillé aux utilisateurs de Matrix et aux administrateurs de serveurs de mettre à niveau les clients vers la dernière version et de s'assurer qu'elle prend en charge la prochaine version 12 de Room. Erik Avakian recommande de mettre à jour tous les clients et bots, y compris les applications, intégrations ou outils automatisés connectés à un serveur Matrix. Dans la mesure du possible, il est préférable de limiter les connexions à des sites externes, et les administrateurs et utilisateurs clés doivent être immédiatement informés des changements. « Comme pour tout changement critique, l'adoption d'une approche axée sur les tests évitera tout risque de dysfonctionnement pour les utilisateurs finaux et de perturbation des activités », a-t-il rappelé.

À long terme, Erik Avakian conseille d'être « sélectif » quant aux personnes avec lesquelles l’entreprise se connecte, de n'autoriser la fédération qu'avec des serveurs de confiance et de s’assurer que le véritable « créateur » est le seul à pouvoir effectuer certaines modifications ou actions. « Surveillez régulièrement les événements enregistrés et examinez les modifications importantes apportées aux salles afin de détecter toute activité suspecte. Appliquez toujours les correctifs et les mises à jour, mais uniquement après avoir effectué les tests appropriés. Enfin, selon le responsable, il est important de garder à l'esprit les principes du zero trust. « Traitez les autres serveurs avec prudence, même s'ils font partie de votre réseau, et sécurisez-les en conséquence. »