Molly, fork de Signal, reste inactif trois mois et montre une vulnérabilité

Présentation de Molly

Molly est un dérivé du client de messagerie chiffrée Signal. Le projet reprend le code source ouvert de Signal, ajoute une interface personnalisée et cible des utilisateurs souhaitant une alternative communautaire. Le dépôt public indique que le dernier commit visible date d’il y a trois mois, ce qui correspond à la période d’inactivité mentionnée dans le titre.

Cycle de mise à jour et état actuel

Le processus de mise à jour d’un fork repose sur le suivi des versions officielles de Signal et sur l’intégration de correctifs de sécurité. Aucun nouveau commit n’a été publié depuis plus de 90 jours, ce qui signifie que les correctifs publiés par l’équipe principale de Signal pendant cette période n’ont pas été incorporés dans Molly. L’absence de synchronisation avec le référentiel principal expose le fork à toutes les vulnérabilités découvertes dans les versions intermédiaires de Signal.

Conséquences sécuritaires d’une version non maintenue

Signal utilise le protocole Double Ratchet, la cryptographie à courbe elliptique Curve25519 et le chiffrement AES‑256‑GCM. Ces mécanismes restent robustes tant que le code d’implémentation est à jour. Un fork qui ne reçoit pas les correctifs de l’implémentation du Double Ratchet peut conserver des bugs de génération de clés ou des fuites de métadonnées. De plus, les mises à jour récentes de Signal ont introduit des protections contre les attaques de type replay et des améliorations du protocole sealed‑sender ; leur absence dans Molly crée une surface d’attaque élargie. La mention d’une « vulnérabilité » sans identifiant indique que la communauté a détecté au moins un problème exploitable, mais le manque de détails empêche d’évaluer son impact exact.

Analyse des limites d’information

La source consultée ne fournit aucun détail technique sur la vulnérabilité ni sur les versions de dépendances utilisées (libsignal‑protocol, OpenSSL, etc.). En l’absence de ces données, il est impossible de quantifier le risque ni de proposer des mesures correctives précises. Le constat principal reste que le projet ne suit pas un cycle de maintenance compatible avec les exigences de sécurité d’une messagerie chiffrée. Les utilisateurs doivent donc considérer la migration vers le client officiel de Signal ou un autre fork activement maintenu.