L’absence de mises à jour de Molly suscite des inquiétudes de sécurité autour d’une ancienne bibliothèque d’appels Signal

Molly n’a publié aucune version stable répertoriée depuis trois mois, ce qui soulève la question de savoir si ses protections supplémentaires s’accompagnent de correctifs de sécurité tardifs. Cet écart de mise à jour mérite attention, car la version de juillet de Molly déclare une bibliothèque d’appels plus ancienne que celle qui corrige une vulnérabilité publiée concernant la terminaison d’appels.

Au 2 novembre 2026, les éléments publics justifient des inquiétudes quant à une version vieillissante et à une dépendance potentiellement affectée. Ils n’établissent pas que des attaquants aient exploité des utilisateurs de Molly. Ils ne permettent pas non plus de déterminer si la bibliothèque personnalisée de Molly contient un correctif équivalent.

La tension centrale oppose les fonctionnalités de sécurité supplémentaires à une maintenance rapide. Signal fournit le code amont, c’est-à-dire le logiciel original que Molly adapte. Les utilisateurs de Molly dépendent d’un autre processus de publication pour recevoir ces changements. Un fork axé sur la sécurité, une variante logicielle maintenue indépendamment, doit conserver la fiabilité de ce processus tout en assurant ses propres protections.

Ce que révèle réellement l’écart de mise à jour de Molly

La liste publique des versions GitHub de Molly identifie v8.19.2-4, datée du 31 juillet, comme sa dernière publication. Ses notes décrivent un correctif pour une fuite DNS, une divulgation involontaire des requêtes de noms de domaine, lorsqu’un proxy configuré était utilisé. La version stable visible accuse donc plus de trois mois de retard par rapport à la date de publication de cet article. L’historique des versions étaye l’affirmation centrale sur le calendrier.

L’écart entre les versions est vérifiable ; ses conséquences en matière de sécurité exigent un examen distinct.

Cette distinction importe, car les dates de publication répondent à une question plus limitée que ne le suggèrent souvent les titres. Elles établissent quand un projet a publié un paquet via un canal particulier. Elles ne révèlent pas automatiquement chaque modification contenue dans ce paquet.

Une version ancienne peut intégrer sélectivement un correctif de sécurité. Les développeurs parlent de rétroportage : appliquer une correction ultérieure sans adopter l’intégralité de la nouvelle version. À l’inverse, un paquet récemment publié peut conserver une dépendance obsolète.

Pour les lecteurs, la question utile est donc plus précise que de savoir si Molly semble inactive. Il s’agit de déterminer si l’application installée contient la correction de la vulnérabilité examinée.

L’inquiétude publique est apparue dans une publication communautaire fournie avec le brief de cet article. Son titre allègue à la fois une interruption de mises à jour de trois mois et une vulnérabilité. Ces affirmations doivent faire l’objet de vérifications distinctes, même lorsqu’elles apparaissent ensemble dans le titre d’une discussion.

La liste des versions étaye la première affirmation. Établir la seconde exige de comparer les composants de l’application à une faille documentée, puis de vérifier l’existence de corrections équivalentes.

Cette approche limite également ce qu’il est raisonnable d’affirmer sur le projet lui-même. Une page de versions inactive ne démontre pas que ses mainteneurs ont abandonné le développement. Elle n’explique ni leur disponibilité, ni leurs tests internes, ni les obstacles à la publication.

Aucune explication vérifiée de cette interruption n’est établie ici. En attribuer une transformerait un problème de maintenance observable en spéculation sur les personnes responsables.

Les utilisateurs n’ont toutefois pas besoin d’explication pour constater que le paquet disponible vieillit. Un effort de développement privé n’offre aucune protection déployée tant qu’une application corrigée n’atteint pas leurs appareils.

C’est pourquoi cet écart importe aujourd’hui. La question pratique concerne le logiciel que les gens peuvent installer, plutôt que les intentions derrière un travail qu’ils ne peuvent pas examiner.

Pour quiconque suit cette affaire, la date de juillet devrait constituer le point de départ de l’enquête. L’enregistrement de la dépendance fournit l’élément de preuve suivant, plus déterminant.

Une ancienne dépendance d’appels rend l’inquiétude concrète

Le code source associé à Molly v8.19.2-4 déclare sa dépendance Android RingRTC comme im.molly:ringrtc-android:2.69.5-1. RingRTC est la bibliothèque logicielle qui gère les fonctionnalités d’appel liées à Signal. La dépendance d’appels balisée fournit un composant précis à examiner.

Un enregistrement de vulnérabilité publié, CVE-2026-113380, identifie un problème de terminaison d’appel dans les versions amont de RingRTC antérieures à 2.72.0. Un CVE est un identifiant public utilisé pour suivre une vulnérabilité divulguée. L’enregistrement décrit une interférence avec le traitement du raccrochage lorsqu’un autre participant à l’appel sature une file interne. L’audio, et peut-être la vidéo, peuvent rester concernés. L’avis sur la terminaison d’appel a été publié le 20 octobre.

La dépendance déclarée donne à cet article une base technique qui dépasse l’ancienneté de l’application.

Cependant, la dépendance de Molly utilise l’espace de noms de paquet et le suffixe de version propres au projet. Cela crée une limite importante de vérification. Son numéro la place sous la version amont corrigée, mais ce seul numéro ne prouve pas que son contenu source est identique.

Une évaluation concluante examinerait la bibliothèque exacte utilisée pour construire l’application distribuée. Elle déterminerait si la correction pertinente, ou une modification fonctionnellement équivalente, est présente.

Cet article n’a pas mené à bien cet examen au niveau de l’artefact. Un artefact est le fichier logiciel effectivement distribué, plutôt que la liste de sources décrivant sa procédure de compilation.

Les éléments disponibles étayent donc l’existence d’une dépendance potentiellement affectée et la nécessité d’une clarification. Ils ne justifient pas de présenter une attaque réussie spécifique à Molly comme démontrée de manière indépendante.

Cette distinction est utile aux utilisateurs envisageant des appels sensibles. Ils ont besoin d’une réponse sur le composant exécuté sur leurs téléphones. Une assurance générale concernant le chiffrement ne répondrait pas à cette question.

Le chiffrement de bout en bout, qui protège le contenu entre les points d’extrémité communicants, ne détermine pas à lui seul si un point d’extrémité cesse de transmettre lorsqu’il en reçoit l’instruction. Un appel peut rester chiffré tout en se comportant à l’encontre des attentes du participant.

Imaginez un chercheur mettant fin à un entretien avant d’aborder un sujet confidentiel avec une personne à proximité. La frontière de confidentialité est le moment où le microphone cesse d’envoyer de l’audio.

Si cette frontière échoue, une protection forte durant la transmission ne rétablit pas le contrôle que l’utilisateur entendait exercer. Ce scénario illustre l’importance de la faille signalée ; il ne s’agit pas d’un incident Molly documenté.

La même distinction compte pour les appels professionnels, les entretiens avec des sources et les conversations personnelles. Les utilisateurs prennent des décisions selon qu’ils ont effectivement cessé de participer, souvent sans examiner l’état sous-jacent de l’application.

Pour les développeurs, l’enjeu immédiat est précis. Démontrer la présence de la correction résoudrait davantage d’incertitudes que comparer les numéros de version de l’application ou répéter de larges affirmations sur la sécurité.

Un renforcement supplémentaire dépend toujours de la maintenance

Molly se présente comme une variante de Signal axée sur la sécurité. Sa documentation liste la protection par phrase secrète de la base de données, le verrouillage automatique, l’effacement de la mémoire et des alternatives pour recevoir les notifications. Cette même documentation indique que les mises à jour de routine arrivent toutes les deux semaines, avec application de correctifs de sécurité lorsqu’ils sont disponibles. Il s’agit des fonctionnalités et engagements de maintenance déclarés par le projet, et non d’une vérification indépendante de leur efficacité. Ses engagements de sécurité établissent le niveau de confiance demandé aux utilisateurs.

Les protections supplémentaires et les correctifs rapides répondent à des risques différents, et les utilisateurs doivent évaluer les deux séparément.

Le renforcement consiste à ajouter des mesures destinées à réduire l’exposition ou à limiter les dommages. Un verrouillage de base de données, par exemple, concerne l’accès aux informations stockées sur un appareil. Une correction de bibliothèque d’appels concerne le comportement pendant les communications.

La réussite dans un domaine n’établit pas la sécurité dans l’autre. Une liste de fonctionnalités ne peut pas répondre à la question de savoir si un composant vulnérable particulier a été corrigé.

C’est le compromis central de la discussion Molly contre Signal. Les utilisateurs qui choisissent un client modifié peuvent obtenir des contrôles auxquels ils accordent de la valeur, tout en acceptant le processus d’intégration et de distribution d’un autre projet.

Cette dépendance ne rend pas les forks intrinsèquement dangereux. Elle signifie que leur argument de sécurité comprend un travail opérationnel continu, en plus de la conception de leurs fonctionnalités supplémentaires.

Une correction amont doit être examinée, intégrée, compilée, testée, signée et distribuée. La signature associe l’identité d’un éditeur à un paquet logiciel afin que les appareils puissent reconnaître les mises à jour autorisées.

Chaque étape peut être raisonnable prise isolément. Ensemble, elles déterminent combien de temps les utilisateurs attendent avant qu’une correction publiée devienne une protection installée.

Le coût est particulièrement pertinent lorsque les modifications touchent les mêmes domaines que le développement amont. Les développeurs doivent préserver leurs changements tout en vérifiant que le nouveau code fonctionne correctement avec eux.

Ce travail ne doit pas être écarté comme une simple surcharge administrative. L’ingénierie de publication fait partie de la frontière de sécurité du produit, car les utilisateurs dépendent du paquet qui en résulte.

Pour une personne demandant « Molly Signal est-il sûr », la réponse dépend donc du risque considéré. La protection contre un accès occasionnel aux messages stockés diffère de la gestion fiable de participants malveillants à un appel.

Une évaluation utile demande quelles protections comptent, quelle version est installée et quels éléments étayent son état de maintenance. Un seul adjectif ne peut pas combiner ces réponses de manière responsable.

Signal principal fournit un point de référence, car il maintient l’application originale et la bibliothèque d’appels. Cette relation supprime une étape d’intégration en aval, sans pour autant impliquer l’absence de vulnérabilités.

Molly, de son côté, doit justifier cette dépendance de maintenance supplémentaire par les avantages dont ses utilisateurs ont réellement besoin. Cette justification devient plus difficile lorsque l’état des composants reste incertain.

La comparaison équitable porte sur un comportement actuel et vérifiable. Elle doit éviter de supposer qu’un client modifié est plus sûr parce qu’il ajoute des contrôles, ou qu’un client original est irréprochable.

La pression immédiate repose sur le processus de publication de Molly. Ses attentes de maintenance déclarées rendent cette interruption visible conséquente, quelles qu’en soient les raisons.

Le correctif amont modifie la priorité donnée à la terminaison des appels

La correction liée de RingRTC par Signal ajoute un indicateur distinct de demande de terminaison et vérifie la terminaison indépendamment du traitement ordinaire de la file. Un indicateur est un marqueur d’état stocké que le code peut inspecter directement. La modification introduit également une attente bornée et permet au nettoyage de se poursuivre après certaines erreurs. Ces détails apparaissent dans le correctif de terminaison amont.

L’importance technique réside dans la séparation entre la demande de fin d’appel et l’attente derrière d’autres tâches. La correction rend la terminaison moins dépendante du déroulement normal de la file.

La décision d’un utilisateur de cesser de participer doit être appliquée de manière fiable, même lorsqu’un autre participant génère une activité inattendue.

Une file est une structure qui conserve des tâches jusqu’à leur traitement par le logiciel. Les files sont courantes et utiles, mais leur ordre peut devenir déterminant lorsque des actions locales urgentes partagent le traitement avec des événements influencés à distance.

Dans ce cas, la question de sécurité concerne la personne qui contrôle effectivement le délai. Le participant local s’attend à ce que l’application respecte l’action de raccrochage, même dans des conditions anormales.

Cela rend le problème différent d’un simple défaut d’utilisabilité. Une animation retardée est gênante. L’application tardive d’une décision de confidentialité peut exposer des informations que le participant souhaitait garder privées.

L’enseignement plus large est une déduction d’ingénierie tirée de cette correction. Les contrôles qui mettent fin à une activité sensible méritent un traitement explicite lorsque le logiciel gère des entrées concurrentes ou hostiles.

Ce principe s’applique au-delà de la messagerie. Une commande d’arrêt d’enregistrement, la révocation d’une session ou le retrait d’une autorisation peuvent susciter des attentes similaires. Chacun exige son propre examen de mise en œuvre ; cette vulnérabilité n’établit pas l’existence de défauts dans ces autres systèmes.

Pour cette analyse, la leçon reste centrée sur les appels. La question pertinente est de savoir si la bibliothèque distribuée par Molly contient le comportement de terminaison introduit par la correction.

Une interface d’application plus récente ne permettrait pas de trancher cette question. Des appels ordinaires réussis non plus, car un fonctionnement normal ne sollicite pas nécessairement la condition de défaillance examinée ici.

Une validation utile doit étudier la condition anormale elle-même. Elle devrait établir que la demande locale de terminaison aboutit à un nettoyage complet lorsque le traitement ordinaire ralentit ou est surchargé.

C’est pourquoi une modification du code source, un enregistrement de compilation et un test de régression ciblé seraient conjointement convaincants. Un test de régression vérifie qu’une défaillance précédemment identifiée ne réapparaît pas.

Ces formes de preuve répondent à des questions différentes. Le code source établit le comportement prévu. L’enregistrement de compilation relie ce code au paquet. Les tests examinent si le comportement pertinent fonctionne.

Les utilisateurs ne devraient pas avoir à effectuer eux-mêmes toute cette analyse. Une déclaration des mainteneurs identifiant la correction et les versions concernées leur donnerait une base pratique pour décider quoi installer.

Le mécanisme explique également pourquoi l’ancienneté calendaire n’importe qu’indirectement. Le temps crée une possibilité de divergence, mais la présence ou l’absence de la correction détermine cette préoccupation technique particulière.

Ce qui reste non vérifié concernant l’exposition de Molly

Les éléments disponibles laissent plusieurs questions ouvertes. Cette analyse n’a pas reproduit indépendamment CVE-2026-113380 contre Molly v8.19.2-4. Elle n’a pas établi si la bibliothèque d’appel personnalisée de Molly contient un correctif rétroporté équivalent.

Elle n’a pas non plus établi qu’une attaque a effectivement réussi contre un utilisateur de Molly. Un avertissement de vulnérabilité, une déduction concernant un composant affecté et des preuves d’exploitation sont des constatations distinctes.

La conclusion la mieux étayée est l’existence d’un écart de version documenté, avec une préoccupation non résolue concernant un composant précis.

Cette conclusion est suffisamment sérieuse pour justifier un examen approfondi, sans dériver vers des affirmations non étayées. Dire que chaque utilisateur de Molly a été surveillé irait bien au-delà des éléments disponibles.

De même, ce problème d’appel n’établit pas que les historiques de messages stockés ont été déchiffrés. Le mécanisme signalé concerne la terminaison d’une session de communication active.

Maintenir un périmètre précis aide les utilisateurs à prendre des décisions proportionnées. Une personne examinant la confidentialité des appels a besoin d’informations différentes de celles d’une personne enquêtant sur le stockage des messages ou l’accès au compte.

La description de l’avis implique un autre participant à un appel. Elle ne décrit pas des inconnus pouvant activer à distance chaque microphone installé sans interaction existante.

Cette limite doit rester visible chaque fois que l’analyse est résumée. Retirer les conditions d’attaque peut rendre un avertissement plus dramatique, tout en le rendant moins utile.

L’absence d’un exploit spécifique à Molly reproduit ne doit pas non plus devenir un motif de réassurance. Les utilisateurs n’ont pas besoin d’attendre des préjudices publics avant d’exiger la preuve qu’une correction pertinente a été livrée.

C’est ici qu’une réponse prudente à la question « Molly Signal est-il sûr ? » doit résister à un verdict binaire. Les éléments identifient une question concernant une version et un composant particuliers, non un jugement permanent sur le projet.

Il n’existe pas non plus ici de base vérifiée permettant d’attribuer le retard à de la négligence, au financement, à la maladie ou à l’abandon. Ces explications exigent des déclarations ou des documents qui les établissent.

Les mainteneurs peuvent être confrontés à des contraintes légitimes, mais les utilisateurs subissent tout de même les conséquences d’une livraison tardive. Comprendre une cause et évaluer une version sont deux tâches distinctes.

La comparaison entre Molly et Signal doit rester tout aussi rigoureuse. La propriété en amont ne garantit pas une sécurité parfaite, tandis qu’un renforcement supplémentaire ne justifie pas l’incertitude concernant des corrections connues.

Pour les organisations, cela plaide en faveur de l’évaluation de versions exactes d’applications dans les flux de travail sensibles. Un nom de produit approuvé est insuffisant lorsque différents clients et versions contiennent des logiciels différents.

Pour les particuliers, cela plaide en faveur de la vérification de l’application réelle et du canal de mise à jour avant de formuler des hypothèses. Une icône rassurante ou une liste de contacts familière n’identifie pas la dépendance sous-jacente.

La réponse la plus solide réduirait l’incertitude par des preuves. Un rétroport documenté affaiblirait la déduction selon laquelle le composant est affecté. Une défaillance reproductible la renforcerait. Les deux amélioreraient le débat.

Trois signaux détermineront si la confiance se rétablit

L’écart de mise à jour de Molly deviendra plus facile à évaluer lorsque des documents publics relieront la correction pertinente à un logiciel que les utilisateurs peuvent obtenir. Un nouveau débat sur les préférences générales en matière de confidentialité ne résoudra pas ce lien.

Les prochaines évolutions utiles sont une version corrigée, une explication technique explicite et des preuves de livraison durable.

Le premier signal est un paquet Molly publiquement disponible, accompagné d’une correction clairement documentée de la bibliothèque d’appel. La version 2.72.0 de RingRTC en amont fournit une version de référence pour cette enquête. Un rétroport équivalent peut également compter, à condition que son contenu soit documenté.

Cela renforcerait la confiance dans le paquet concerné en répondant directement à la question du composant. Une nouvelle version sans informations pertinentes sur les dépendances laisserait davantage de travail aux examinateurs.

La distribution compte autant que la publication. Les utilisateurs ont besoin du paquet corrigé via le canal qu’ils utilisent réellement, avec suffisamment d’informations pour reconnaître que la modification pertinente y est incluse.

Le deuxième signal est une explication des mainteneurs identifiant les versions affectées et l’état de la correction. Une telle déclaration serait particulièrement utile si elle reliait les modifications du code source, les identifiants de version et toute validation disponible.

Une déclaration confirmant un rétroport existant affaiblirait sensiblement la déduction selon laquelle le paquet de juillet conserve ce défaut. Une déclaration confirmant l’exposition préciserait quels utilisateurs doivent agir.

Dans les deux cas, les documents publics en seraient améliorés. La précision technique a plus de valeur qu’une assurance générale selon laquelle la sécurité reste une priorité.

Le troisième signal est ce qui se produit après le traitement du problème immédiat. Au cours des prochains mois, des versions régulières et une gestion explicite des modifications de sécurité montreraient si la livraison est redevenue fiable.

Une version de rattrapage peut résoudre un problème urgent. Elle ne peut pas, à elle seule, établir la manière dont le projet gérera la prochaine correction.

Des retards répétés renforceraient les inquiétudes concernant la dépendance de maintenance. Une livraison cohérente affaiblirait l’argument selon lequel les utilisateurs doivent accepter une incertitude prolongée pour conserver les contrôles supplémentaires de Molly.

Ce dernier signal compte parce que la confiance repose sur des attentes concernant le comportement futur. Les utilisateurs ne peuvent pas inspecter le code de demain aujourd’hui, mais ils peuvent évaluer si un projet communique clairement et livre les corrections de façon prévisible.

Pour les développeurs qui maintiennent d’autres forks axés sur la sécurité, les mêmes éléments constituent une référence pratique. Expliquez l’état des composants, identifiez les paquets affectés et rendez visible le chemin entre la correction et l’installation.

Pour les lecteurs, gardez la décision ancrée dans des éléments que vous pouvez vérifier : votre version installée, ses composants documentés et l’état des corrections pertinentes. Évitez de considérer une liste de fonctionnalités comme un substitut à ces éléments. Si la confidentialité des appels est importante pour votre travail ou votre sécurité personnelle, accordez un poids approprié aux questions de maintenance non résolues lors du choix d’un client. Suivez la prochaine version et ses notes techniques, puis réévaluez votre décision lorsque ces documents évolueront. L’écart de mise à jour de Molly soulève une question concrète qui mérite une réponse concrète : l’application sur votre appareil contient-elle la correction nécessaire pour mettre fin à un appel de manière fiable ?