La brecha de actualizaciones de Molly genera preocupaciones de seguridad sobre una biblioteca de llamadas antigua de Signal
Molly lleva tres meses sin una versión estable publicada, lo que plantea dudas sobre si sus protecciones adicionales implican retrasos en las correcciones de seguridad. La brecha de actualizaciones de Molly merece escrutinio porque su versión de julio declara una biblioteca de llamadas anterior a la versión que corrige una vulnerabilidad publicada de finalización de llamadas.
A fecha del 2 de noviembre de 2026, la evidencia pública respalda la preocupación por una versión envejecida y una dependencia potencialmente afectada. No establece que atacantes hayan explotado a usuarios de Molly. Tampoco resuelve si la biblioteca personalizada de Molly contiene una corrección equivalente.
La tensión central está entre las funciones de seguridad adicionales y un mantenimiento oportuno. Signal proporciona el código upstream, es decir, el software original que Molly adapta. Los usuarios de Molly dependen de otro proceso de lanzamiento para recibir esos cambios. Un fork centrado en la seguridad, una variante de software mantenida de forma independiente, debe mantener ese proceso fiable junto con sus propias protecciones.
Lo que realmente muestra la brecha de actualizaciones de Molly
La lista pública de versiones de Molly en GitHub identifica v8.19.2-4, con fecha del 31 de julio, como su versión más reciente. Sus notas describen una corrección para una fuga de DNS, una divulgación involuntaria de búsquedas de dominios, al usar un proxy configurado. Esto sitúa la versión estable visible con más de tres meses de retraso respecto a la fecha de publicación de este artículo. El historial de versiones respalda la afirmación central sobre el calendario.
La brecha entre versiones es verificable; sus consecuencias de seguridad requieren un examen independiente.
Esta distinción importa porque las fechas de lanzamiento responden a una pregunta más limitada de lo que suelen sugerir los titulares. Establecen cuándo un proyecto publicó un paquete a través de un canal concreto. No revelan automáticamente todos los cambios dentro de ese paquete.
Una versión antigua puede contener una corrección de seguridad importada selectivamente. Los desarrolladores llaman a esto un backport: aplicar una corrección posterior sin adoptar toda la versión más reciente. A la inversa, un paquete publicado recientemente puede conservar una dependencia obsoleta.
Por tanto, para los lectores, la pregunta útil es más específica que si Molly parece inactivo. Es si la aplicación instalada contiene la corrección para la vulnerabilidad en cuestión.
La preocupación pública surgió a través de una publicación comunitaria proporcionada junto con el encargo de esta historia. Su título alega tanto una pausa de tres meses en las actualizaciones como una vulnerabilidad. Estas afirmaciones deben seguir vías de verificación separadas, incluso cuando aparezcan juntas en un titular de discusión.
La lista de versiones respalda la primera afirmación. Establecer la segunda exige comparar los componentes de la aplicación con un fallo documentado y comprobar después si existen correcciones equivalentes.
Este enfoque también limita lo que puede afirmarse responsablemente sobre el proyecto en sí. Una página de versiones silenciosa no establece que sus mantenedores hayan abandonado el desarrollo. No explica su disponibilidad, sus pruebas internas ni los obstáculos para publicar versiones.
Aquí no se establece ninguna explicación verificada para la pausa. Atribuirle una convertiría un problema de mantenimiento observable en especulación sobre las personas responsables.
Aun así, los usuarios no necesitan una explicación antes de reconocer que el paquete disponible está envejeciendo. Un esfuerzo de desarrollo privado no ofrece protección desplegada hasta que una aplicación corregida llega a sus dispositivos.
Por eso la brecha importa ahora. La cuestión práctica se refiere al software que las personas pueden instalar, no a las intenciones detrás de un trabajo que no pueden inspeccionar.
Para cualquiera que siga esta historia, la fecha de julio debería ser el punto de partida de la investigación. El registro de dependencias aporta la siguiente pieza de evidencia, más trascendental.
Una dependencia de llamadas antigua concreta la preocupación
El código fuente asociado a Molly v8.19.2-4 declara su dependencia Android de RingRTC como im.molly:ringrtc-android:2.69.5-1. RingRTC es la biblioteca de software que gestiona la funcionalidad de llamadas relacionada con Signal. La dependencia de llamadas etiquetada proporciona un componente específico que examinar.
Un registro de vulnerabilidad publicado, CVE-2026-113380, identifica un problema de finalización de llamadas en las versiones upstream de RingRTC anteriores a 2.72.0. Un CVE es un identificador público utilizado para rastrear una vulnerabilidad divulgada. El registro describe interferencias con el procesamiento de colgar cuando otro participante de la llamada satura una cola interna. El audio, y quizá el vídeo, pueden seguir involucrados. El aviso sobre finalización de llamadas se publicó el 20 de octubre.
La dependencia declarada proporciona a esta historia una base técnica que va más allá de la antigüedad de la aplicación.
Sin embargo, la dependencia de Molly utiliza el propio espacio de nombres del paquete del proyecto y un sufijo de versión. Eso crea un límite importante para la verificación. Su número la sitúa por debajo de la versión upstream corregida, pero el número por sí solo no demuestra contenidos de código fuente idénticos.
Una evaluación concluyente inspeccionaría la biblioteca exacta utilizada para compilar la aplicación distribuida. Determinaría si está presente la corrección pertinente, o un cambio funcionalmente equivalente.
Este artículo no ha completado ese examen a nivel de artefacto. Un artefacto es el archivo de software realmente distribuido, en lugar del listado de código fuente que describe cómo compilarlo.
Por tanto, la evidencia respalda una dependencia potencialmente afectada y la necesidad de aclaraciones. No respalda presentar un ataque exitoso específico contra Molly como demostrado de forma independiente.
La distinción resulta útil para usuarios que consideran realizar llamadas sensibles. Necesitan una respuesta sobre el componente que se ejecuta en sus teléfonos. Una tranquilidad general sobre el cifrado no respondería a esa pregunta.
El cifrado de extremo a extremo, que protege el contenido entre los extremos que se comunican, no determina por sí solo si un extremo deja de transmitir cuando se le indica. Una llamada puede seguir cifrada mientras se comporta de forma contraria a las expectativas del participante.
Pensemos en un investigador hipotético que termina una entrevista antes de hablar de material confidencial con alguien cercano. El límite de privacidad es el momento en que el micrófono deja de enviar audio.
Si ese límite falla, una protección sólida durante la transmisión no restablece el control que pretendía el usuario. Este escenario ilustra la importancia del fallo reportado; no es un incidente documentado de Molly.
La misma distinción importa para llamadas laborales, entrevistas con fuentes y conversaciones personales. Los usuarios toman decisiones basándose en si su participación ha terminado, a menudo sin inspeccionar el estado subyacente de la aplicación.
Para los desarrolladores, la carga inmediata es específica. Demostrar la presencia de la corrección resolvería más incertidumbre que comparar números de versión de aplicaciones o repetir afirmaciones amplias de seguridad.
El endurecimiento adicional sigue dependiendo del mantenimiento
Molly se describe como una variante de Signal centrada en la seguridad. Su documentación enumera protección con frase de contraseña para la base de datos, bloqueo automático, borrado de memoria y alternativas para recibir notificaciones. La misma documentación indica que las actualizaciones rutinarias llegan cada dos semanas, con parches de seguridad aplicados cuando están disponibles. Estas son las funciones y compromisos de mantenimiento declarados por el proyecto, no una verificación independiente de su eficacia. Sus compromisos de seguridad establecen el estándar en el que se pide a los usuarios que confíen.
Las protecciones adicionales y las correcciones oportunas abordan riesgos distintos, y los usuarios necesitan evaluar ambas por separado.
El endurecimiento consiste en añadir medidas destinadas a reducir la exposición o limitar los daños. Un bloqueo de base de datos, por ejemplo, se refiere al acceso a la información almacenada en un dispositivo. Una corrección de una biblioteca de llamadas se refiere al comportamiento durante la comunicación.
El éxito en un área no establece la seguridad en otra. Una lista de funciones no puede responder si se ha corregido un componente vulnerable concreto.
Este es el equilibrio central en la discusión Molly vs Signal. Los usuarios que eligen un cliente modificado pueden obtener controles que valoran, mientras aceptan el proceso de integración y distribución de otro proyecto.
Esa dependencia no hace que los forks sean inherentemente inseguros. Significa que su argumento de seguridad incluye trabajo operativo continuo, junto con el diseño de sus funciones adicionales.
Una corrección upstream debe revisarse, integrarse, compilarse, probarse, firmarse y distribuirse. La firma vincula la identidad de un editor a un paquete de software para que los dispositivos puedan reconocer actualizaciones autorizadas.
Cada etapa puede ser razonable por sí sola. Juntas, esas etapas determinan cuánto esperan los usuarios antes de que una corrección publicada se convierta en una protección instalada.
El coste es especialmente relevante cuando las modificaciones afectan las mismas áreas que el desarrollo upstream. Los desarrolladores deben conservar sus cambios mientras comprueban que el código nuevo se comporta correctamente con ellos.
Ese trabajo no debería descartarse como carga administrativa. La ingeniería de versiones forma parte del límite de seguridad del producto porque los usuarios dependen del paquete resultante.
Para alguien que pregunta «¿es seguro Molly Signal?», la respuesta depende por tanto del riesgo considerado. La protección frente al acceso casual a mensajes almacenados es distinta del manejo fiable de participantes hostiles en llamadas.
Una evaluación útil pregunta qué protecciones importan, qué versión está instalada y qué evidencia respalda su estado de mantenimiento. Un único adjetivo no puede combinar esas respuestas de manera responsable.
Signal principal proporciona un punto de referencia porque mantiene la aplicación original y la biblioteca de llamadas. Esa relación elimina un paso de integración posterior, aunque no implica estar libre de vulnerabilidades.
Mientras tanto, Molly debe justificar la dependencia adicional de mantenimiento mediante los beneficios que sus usuarios realmente requieren. Esa justificación se vuelve más difícil cuando el estado de los componentes sigue siendo incierto.
La comparación justa se refiere al comportamiento actual y verificable. Debe evitar asumir que un cliente modificado es más seguro porque añade controles, o que un cliente original es impecable.
La presión inmediata recae sobre el proceso de publicación de Molly. Sus expectativas de mantenimiento declaradas hacen que la pausa visible sea importante, independientemente de las razones que la expliquen.
La corrección upstream cambia la prioridad de finalización de llamadas
La corrección vinculada de RingRTC de Signal añade una bandera independiente de solicitud de finalización y comprueba la terminación de forma independiente del procesamiento ordinario de la cola. Una bandera es un marcador de estado almacenado que el código puede inspeccionar directamente. El cambio también introduce una espera limitada y permite que la limpieza continúe tras ciertos errores. Estos detalles aparecen en la corrección de finalización upstream.
La importancia técnica reside en la separación entre solicitar el fin de una llamada y esperar detrás de otro trabajo. La corrección hace que la finalización dependa menos de que la cola avance con normalidad.
La decisión de un usuario de dejar de participar necesita una aplicación fiable incluso cuando otro participante genera actividad inesperada.
Una cola es una estructura que mantiene trabajo hasta que el software lo procesa. Las colas son habituales y útiles, pero su orden puede volverse relevante cuando acciones locales urgentes comparten procesamiento con eventos influidos remotamente.
En este caso, la cuestión de seguridad se refiere a quién controla efectivamente el retraso. El participante local espera que la aplicación obedezca la acción de colgar, incluso en condiciones anómalas.
Eso hace que el problema sea distinto de un defecto de usabilidad común. Una animación retrasada es inconveniente. La aplicación tardía de una decisión de privacidad puede exponer información que el participante pretendía ocultar.
La lección más amplia es una inferencia de ingeniería derivada de esta corrección. Los controles que ponen fin a una actividad sensible merecen un tratamiento explícito cuando el software maneja entradas en conflicto u hostiles.
Ese principio se aplica más allá de la mensajería. Un comando para detener la grabación, la revocación de una sesión o la retirada de un permiso pueden implicar expectativas similares. Cada caso requiere su propia revisión de implementación; esta vulnerabilidad no establece defectos en esos otros sistemas.
Para esta historia, la lección sigue centrada en las llamadas. La pregunta pertinente es si la biblioteca distribuida de Molly contiene el comportamiento de finalización introducido por la corrección.
Una interfaz de aplicación más reciente no resolvería esa cuestión. Tampoco lo harían unas llamadas normales realizadas con éxito, ya que el funcionamiento ordinario no necesariamente activa la condición de fallo que se analiza.
Una validación útil debe examinar la condición anómala en sí misma. Debe establecer que la solicitud local de finalización produce una limpieza completa cuando el procesamiento ordinario se bloquea o se sobrecarga.
Por eso, un cambio de código fuente, un registro de compilación y una comprobación de regresión específica resultarían convincentes en conjunto. Una comprobación de regresión verifica que un fallo identificado previamente no reaparece.
Estas formas de evidencia responden a preguntas diferentes. El código fuente establece el comportamiento previsto. El registro de compilación vincula ese código con el paquete. Las pruebas examinan si el comportamiento pertinente funciona.
Los usuarios no deberían tener que realizar personalmente todo ese análisis. Una declaración del mantenedor que identifique la corrección y las versiones afectadas les daría una base práctica para decidir qué instalar.
El mecanismo también explica por qué la antigüedad en el calendario solo importa de forma indirecta. El tiempo crea una oportunidad para la divergencia, pero la presencia o ausencia de la corrección determina esta preocupación técnica concreta.
Lo que sigue sin verificarse sobre la exposición de Molly
El registro disponible deja varias preguntas abiertas. Esta revisión no ha reproducido de forma independiente CVE-2026-113380 contra Molly v8.19.2-4. Tampoco ha establecido si la biblioteca de llamadas personalizada de Molly contiene una corrección retroportada equivalente.
Tampoco ha establecido un ataque exitoso contra un usuario de Molly. Una advertencia de vulnerabilidad, una inferencia sobre un componente afectado y evidencia de explotación son hallazgos diferentes.
La conclusión más sólida respaldada es una brecha documentada entre versiones con una preocupación específica sin resolver sobre un componente.
Esa conclusión es lo bastante seria como para justificar un examen minucioso sin extenderse a afirmaciones sin respaldo. Decir que todos los usuarios de Molly han sido vigilados iría mucho más allá de la evidencia.
Del mismo modo, este problema de llamadas no establece que se hayan descifrado historiales de mensajes almacenados. El mecanismo informado se refiere a la finalización de una sesión de comunicación activa.
Mantener el alcance preciso ayuda a los usuarios a tomar decisiones proporcionadas. Quien revisa la privacidad de las llamadas necesita información distinta de quien investiga el almacenamiento de mensajes o el acceso a una cuenta.
La descripción del aviso implica a otro participante en una llamada. No describe a desconocidos arbitrarios activando de forma remota todos los micrófonos instalados sin una interacción existente.
Ese límite debe seguir siendo visible cada vez que se resuma la historia. Eliminar las condiciones del ataque puede hacer que una advertencia suene más dramática, pero también menos útil.
La ausencia de un exploit específico de Molly reproducido tampoco debería convertirse en tranquilidad. Los usuarios no necesitan esperar a que haya daños públicos antes de esperar evidencia de que se ha distribuido una corrección pertinente.
Aquí es donde una respuesta cauta a «¿es seguro Molly Signal?» debe resistirse a un veredicto binario. La evidencia identifica una cuestión sobre una versión y un componente concretos, no un juicio permanente sobre el proyecto.
Tampoco existe aquí una base verificada para atribuir el retraso a negligencia, financiación, enfermedad o abandono. Esas explicaciones requieren declaraciones o registros que las demuestren.
Los mantenedores pueden afrontar limitaciones legítimas, pero los usuarios siguen experimentando las consecuencias de una entrega tardía. Comprender una causa y evaluar una versión son tareas distintas.
La comparación entre Molly y Signal debe mantenerse igual de rigurosa. La propiedad upstream no garantiza una seguridad perfecta, mientras que un refuerzo adicional no excusa la incertidumbre sobre correcciones conocidas.
Para las organizaciones, esto aboga por evaluar compilaciones exactas de aplicaciones en flujos de trabajo sensibles. Un nombre de producto aprobado es insuficiente cuando distintos clientes y versiones contienen software diferente.
Para las personas, aboga por comprobar la aplicación real y el canal de actualización antes de hacer suposiciones. Un icono tranquilizador o una lista de contactos familiar no identifica la dependencia subyacente.
La respuesta más sólida reduciría la incertidumbre con evidencia. Una corrección retroportada documentada debilitaría la inferencia sobre el componente afectado. Un fallo reproducible la reforzaría. Ambas cosas mejorarían la discusión.
Tres señales determinarán si se recupera la confianza
La brecha de actualización de Molly será más fácil de evaluar cuando los registros públicos vinculen la corrección pertinente con el software que los usuarios pueden obtener. Otro debate sobre preferencias generales de privacidad no resolverá esa conexión.
Los próximos avances útiles son una versión corregida, una explicación técnica explícita y evidencia de una entrega sostenida.
La primera señal es un paquete de Molly disponible públicamente con una corrección de la biblioteca de llamadas claramente documentada. La versión upstream de RingRTC 2.72.0 proporciona una versión de referencia para esa investigación. Una corrección retroportada equivalente también puede ser relevante, siempre que su contenido esté documentado.
Eso reforzaría la confianza en el paquete específico al abordar directamente la cuestión del componente. Una nueva versión sin información pertinente sobre dependencias dejaría más trabajo a los revisores.
La distribución importa junto con la publicación. Los usuarios necesitan el paquete corregido a través del canal que realmente utilizan, con información suficiente para reconocer que incluye el cambio pertinente.
La segunda señal es una explicación del mantenedor que identifique las compilaciones afectadas y el estado de la corrección. Esa declaración sería más útil si conectara cambios de código fuente, identificadores de versión y cualquier validación disponible.
Una declaración que confirme una corrección retroportada existente debilitaría de forma material la inferencia de que el paquete de julio conserva este defecto. Una declaración que confirme la exposición aclararía qué usuarios deben actuar.
Cualquiera de los dos resultados mejoraría el registro público. La especificidad técnica es más valiosa que una garantía amplia de que la seguridad sigue siendo una prioridad.
La tercera señal es lo que ocurra después de abordar el problema inmediato. Durante los próximos meses, las versiones regulares y el tratamiento explícito de los cambios de seguridad mostrarían si la entrega se ha vuelto fiable de nuevo.
Una única versión de recuperación puede resolver un problema urgente. Por sí sola, no puede establecer cómo gestionará el proyecto la próxima corrección.
Los retrasos repetidos reforzarían la preocupación sobre la dependencia de mantenimiento. Una entrega constante debilitaría el argumento de que los usuarios deben aceptar una incertidumbre prolongada para conservar los controles adicionales de Molly.
Esta señal final importa porque la confianza implica expectativas sobre el comportamiento futuro. Los usuarios no pueden inspeccionar hoy el código de mañana, pero sí pueden evaluar si un proyecto se comunica con claridad y entrega correcciones de forma predecible.
Para los desarrolladores que mantienen otras bifurcaciones centradas en la seguridad, la misma evidencia ofrece un punto de referencia práctico. Expliquen el estado de los componentes, identifiquen los paquetes afectados y hagan visible el camino desde la corrección hasta la instalación.
Para los lectores, mantengan la decisión anclada en evidencia que puedan comprobar: su versión instalada, sus componentes documentados y el estado de las correcciones pertinentes. Eviten tratar una lista de funciones como sustituto de ese registro. Si la privacidad de las llamadas importa para su trabajo o seguridad personal, den a las cuestiones de mantenimiento sin resolver el peso adecuado al elegir un cliente. Sigan la próxima versión y sus notas técnicas, y vuelvan a evaluar la decisión cuando esos registros cambien. La brecha de actualización de Molly plantea una pregunta concreta que merece una respuesta concreta: ¿contiene la aplicación de su dispositivo la corrección necesaria para finalizar una llamada de forma fiable?
