Lacuna nas atualizações do Molly levanta preocupações de segurança sobre uma biblioteca de chamadas mais antiga do Signal
O Molly está há três meses sem uma versão estável listada, levantando dúvidas sobre se as suas proteções adicionais vêm acompanhadas de correções de segurança atrasadas. A lacuna nas atualizações do Molly merece análise porque a sua versão de julho declara uma biblioteca de chamadas mais antiga do que a versão que corrige uma vulnerabilidade publicada de terminação de chamadas.
Em 2 de novembro de 2026, as evidências públicas sustentam preocupação com uma versão antiga e uma dependência potencialmente afetada. Não estabelecem que atacantes tenham explorado utilizadores do Molly. Tampouco resolvem se a biblioteca personalizada do Molly contém uma correção equivalente.
A tensão central está entre recursos adicionais de segurança e manutenção em tempo oportuno. O Signal fornece o código upstream, ou seja, o software original que o Molly adapta. Os utilizadores do Molly dependem de outro processo de lançamento para receber essas alterações. Um fork focado em segurança, uma variante de software mantida de forma independente, precisa manter esse processo confiável ao lado das suas próprias proteções.
O que a lacuna nas atualizações do Molly realmente mostra
A lista pública de lançamentos no GitHub do Molly identifica a v8.19.2-4, datada de 31 de julho, como a sua versão mais recente. As suas notas descrevem uma correção para uma fuga de DNS, uma divulgação involuntária de consultas de domínios, quando era utilizado um proxy configurado. Isso deixa a versão estável visível mais de três meses atrás da data de apuração deste artigo. O histórico de lançamentos sustenta a alegação central sobre o período.
A lacuna entre lançamentos é verificável; as consequências de segurança exigem uma análise separada.
Essa distinção importa porque as datas de lançamento respondem a uma questão mais restrita do que as manchetes frequentemente sugerem. Elas estabelecem quando um projeto publicou um pacote por um determinado canal. Não revelam automaticamente todas as alterações dentro desse pacote.
Uma versão antiga pode conter uma correção de segurança incorporada seletivamente. Os desenvolvedores chamam isso de backport: aplicar uma correção posterior sem adotar toda a versão mais nova. Por outro lado, um pacote publicado recentemente pode manter uma dependência desatualizada.
Para os leitores, portanto, a questão útil é mais específica do que saber se o Molly parece inativo. É saber se a aplicação instalada contém a correção para a vulnerabilidade em discussão.
A preocupação pública surgiu por meio de uma publicação da comunidade fornecida com o briefing desta reportagem. O seu título alega tanto uma pausa de três meses nas atualizações como uma vulnerabilidade. Essas alegações devem seguir separadamente pelo processo de verificação, mesmo quando aparecem juntas no título de uma discussão.
A lista de lançamentos comprova a primeira alegação. Estabelecer a segunda exige comparar os componentes da aplicação com uma falha documentada e, em seguida, verificar correções equivalentes.
Essa abordagem também limita o que se pode dizer de forma responsável sobre o próprio projeto. Uma página de lançamentos silenciosa não estabelece que os seus mantenedores tenham abandonado o desenvolvimento. Não explica a sua disponibilidade, testes internos ou obstáculos aos lançamentos.
Nenhuma explicação verificada para a pausa é estabelecida aqui. Atribuir uma transformaria um problema observável de manutenção em especulação sobre as pessoas responsáveis.
Ainda assim, os utilizadores não precisam de uma explicação para reconhecer que o pacote disponível está a envelhecer. Um esforço de desenvolvimento privado não oferece proteção implantada até que uma aplicação corrigida chegue aos seus dispositivos.
É por isso que a lacuna importa agora. A questão prática diz respeito ao software que as pessoas podem instalar, e não às intenções por trás de um trabalho que não podem inspecionar.
Para qualquer pessoa que acompanhe a história, a data de julho deve ser o ponto de partida da investigação. O registo de dependências fornece a próxima peça de evidência, mais consequente.
Uma dependência de chamadas mais antiga torna a preocupação concreta
O código-fonte associado ao Molly v8.19.2-4 declara a sua dependência Android do RingRTC como im.molly:ringrtc-android:2.69.5-1. O RingRTC é a biblioteca de software que lida com a funcionalidade de chamadas relacionada ao Signal. A dependência de chamadas marcada fornece um componente específico a examinar.
Um registo de vulnerabilidade publicado, CVE-2026-113380, identifica um problema de terminação de chamadas em versões upstream do RingRTC anteriores à 2.72.0. Um CVE é um identificador público usado para acompanhar uma vulnerabilidade divulgada. O registo descreve interferência no processamento de desligamento quando outro participante da chamada satura uma fila interna. O áudio, e talvez o vídeo, pode continuar envolvido. O aviso sobre terminação de chamadas foi publicado em 20 de outubro.
A dependência declarada dá a esta história uma base técnica que vai além da idade da aplicação.
No entanto, a dependência do Molly utiliza o próprio namespace de pacote e sufixo de versão do projeto. Isso cria um limite importante para a verificação. O seu número fica abaixo da versão upstream corrigida, mas o número por si só não prova conteúdos de código-fonte idênticos.
Uma avaliação conclusiva inspecionaria a biblioteca exata usada para compilar a aplicação distribuída. Ela determinaria se a correção relevante, ou uma alteração funcionalmente equivalente, está presente.
Este artigo não concluiu esse exame ao nível do artefacto. Um artefacto é o ficheiro de software efetivamente distribuído, em vez da listagem de código-fonte que descreve como compilá-lo.
As evidências, portanto, sustentam uma dependência potencialmente afetada e a necessidade de esclarecimento. Elas não sustentam apresentar um ataque bem-sucedido específico ao Molly como demonstrado de forma independente.
A distinção é útil para utilizadores que consideram fazer chamadas sensíveis. Eles precisam de uma resposta sobre o componente em execução nos seus telemóveis. Uma garantia geral sobre encriptação não responderia a essa questão.
A encriptação de ponta a ponta, que protege o conteúdo entre os pontos finais de comunicação, não determina por si só se um ponto final deixa de transmitir quando recebe instrução para tal. Uma chamada pode permanecer encriptada enquanto se comporta de forma contrária às expectativas do participante.
Considere um investigador hipotético que encerra uma entrevista antes de discutir material confidencial com alguém próximo. O limite de privacidade é o momento em que o microfone deixa de enviar áudio.
Se esse limite falhar, uma proteção forte durante a transmissão não restaura o controlo pretendido pelo utilizador. Este cenário ilustra a importância da falha relatada; não é um incidente documentado do Molly.
A mesma distinção importa para chamadas de trabalho, entrevistas com fontes e conversas pessoais. Os utilizadores tomam decisões com base em saber se a participação terminou, muitas vezes sem inspecionar o estado subjacente da aplicação.
Para os desenvolvedores, a responsabilidade imediata é específica. Demonstrar a presença da correção resolveria mais incertezas do que comparar números de versão da aplicação ou repetir alegações amplas de segurança.
O reforço adicional continua a depender de manutenção
O Molly descreve-se como uma variante do Signal focada em segurança. A sua documentação lista proteção por palavra-passe da base de dados, bloqueio automático, limpeza de memória e alternativas para receber notificações. A mesma documentação diz que atualizações de rotina chegam a cada duas semanas, com patches de segurança aplicados quando disponíveis. Estas são as funcionalidades e os compromissos de manutenção declarados pelo projeto, e não uma verificação independente da sua eficácia. Os seus compromissos de segurança estabelecem o padrão em que é pedido aos utilizadores que confiem.
Proteções adicionais e correções oportunas abordam riscos diferentes, e os utilizadores precisam de ambas avaliadas separadamente.
Reforço significa adicionar medidas destinadas a reduzir a exposição ou limitar danos. Um bloqueio da base de dados, por exemplo, diz respeito ao acesso a informações armazenadas num dispositivo. Uma correção de biblioteca de chamadas diz respeito ao comportamento durante a comunicação.
O sucesso numa área não estabelece segurança na outra. Uma lista de funcionalidades não pode responder se um componente vulnerável específico foi corrigido.
Esta é a principal troca na discussão Molly vs Signal. Os utilizadores que escolhem um cliente modificado podem obter controlos que valorizam enquanto aceitam o processo de integração e distribuição de outro projeto.
Essa dependência não torna os forks inerentemente inseguros. Significa que o seu caso de segurança inclui trabalho operacional contínuo, ao lado do desenho das suas funcionalidades adicionais.
Uma correção upstream deve ser revista, integrada, compilada, testada, assinada e entregue. A assinatura associa a identidade de um publicador a um pacote de software, para que os dispositivos possam reconhecer atualizações autorizadas.
Cada etapa pode ser razoável por si só. Juntas, essas etapas determinam quanto tempo os utilizadores esperam antes de uma correção publicada se tornar uma proteção instalada.
O custo é especialmente relevante quando as modificações afetam as mesmas áreas do desenvolvimento upstream. Os desenvolvedores devem preservar as suas alterações enquanto verificam se o novo código se comporta corretamente com elas.
Esse trabalho não deve ser descartado como sobrecarga administrativa. A engenharia de lançamento faz parte do limite de segurança do produto porque os utilizadores dependem do pacote resultante.
Para uma pessoa que pergunta “o Molly Signal é seguro”, a resposta depende, portanto, do risco considerado. A proteção contra acesso casual a mensagens armazenadas é diferente do tratamento confiável de participantes hostis em chamadas.
Uma avaliação útil pergunta quais proteções importam, qual versão está instalada e quais evidências sustentam o seu estado de manutenção. Um único adjetivo não pode combinar essas respostas de forma responsável.
O Signal principal fornece um ponto de referência porque mantém a aplicação original e a biblioteca de chamadas. Essa relação elimina uma etapa de integração downstream, embora não implique ausência de vulnerabilidades.
O Molly, por sua vez, precisa justificar a dependência adicional de manutenção por meio dos benefícios que os seus utilizadores realmente exigem. Essa justificação torna-se mais difícil quando o estado dos componentes permanece incerto.
A comparação justa diz respeito ao comportamento atual e verificável. Deve evitar presumir que um cliente modificado é mais seguro porque adiciona controlos, ou que um cliente original é impecável.
A pressão imediata recai sobre o processo de lançamento do Molly. As suas expectativas declaradas de manutenção tornam a pausa visível consequente, independentemente das razões por trás dela.
A correção upstream muda a prioridade dada à terminação de chamadas
A correção vinculada do RingRTC pelo Signal adiciona uma flag separada de solicitação de terminação e verifica a terminação independentemente do processamento normal da fila. Uma flag é um marcador de estado armazenado que o código pode inspecionar diretamente. A alteração também introduz espera limitada e permite que a limpeza continue após determinados erros. Esses detalhes aparecem na correção upstream de terminação.
A importância técnica está na separação entre solicitar o fim de uma chamada e esperar atrás de outro trabalho. A correção torna a terminação menos dependente de a fila avançar normalmente.
A decisão de um utilizador de deixar de participar precisa de aplicação confiável mesmo quando outro participante gera atividade inesperada.
Uma fila é uma estrutura que mantém trabalho até que o software o processe. Filas são comuns e úteis, mas a sua ordenação pode tornar-se relevante quando ações locais urgentes compartilham processamento com eventos influenciados remotamente.
Neste caso, a questão de segurança diz respeito a quem efetivamente controla o atraso. O participante local espera que a aplicação obedeça à ação de desligar, mesmo em condições anormais.
Isso torna o problema diferente de um defeito comum de usabilidade. Uma animação atrasada é inconveniente. A aplicação atrasada de uma decisão de privacidade pode expor informações que o participante pretendia reter.
A lição mais ampla é uma inferência de engenharia a partir dessa correção. Controles que encerram atividades sensíveis merecem tratamento explícito quando o software lida com entradas concorrentes ou hostis.
Esse princípio se aplica além das mensagens. Um comando para interromper a gravação, a revogação de uma sessão ou a retirada de uma permissão podem gerar expectativas semelhantes. Cada um exige sua própria revisão de implementação; esta vulnerabilidade não estabelece defeitos nesses outros sistemas.
Para esta reportagem, a lição continua centrada em chamadas. A questão relevante é se a biblioteca distribuída do Molly contém o comportamento de encerramento introduzido pela correção.
Uma interface mais recente do aplicativo não responderia a essa questão. Tampouco chamadas comuns bem-sucedidas, já que a operação normal não necessariamente aciona a condição de falha em discussão.
Uma validação útil precisa examinar a própria condição anormal. Ela deve estabelecer que a solicitação local de encerramento resulta em uma limpeza concluída quando o processamento normal fica bloqueado ou sobrecarregado.
É por isso que uma alteração no código-fonte, um registro de compilação e uma verificação de regressão direcionada seriam, juntos, convincentes. Uma verificação de regressão confirma que uma falha identificada anteriormente não retorna.
Essas formas de evidência respondem a perguntas diferentes. O código-fonte estabelece o comportamento pretendido. O registro de compilação conecta esse código ao pacote. Os testes examinam se o comportamento relevante funciona.
Os usuários não deveriam precisar realizar toda essa análise pessoalmente. Uma declaração dos mantenedores identificando a correção e as versões afetadas lhes daria uma base prática para decidir o que instalar.
O mecanismo também explica por que a idade no calendário importa apenas indiretamente. O tempo cria uma oportunidade para divergência, mas a presença ou ausência da correção determina esta preocupação técnica específica.
O que permanece não verificado sobre a exposição do Molly
O registro disponível deixa várias questões em aberto. Esta análise não reproduziu de forma independente a CVE-2026-113380 contra o Molly v8.19.2-4. Tampouco estabeleceu se a biblioteca de chamadas personalizada do Molly contém um backport equivalente.
Também não estabeleceu um ataque bem-sucedido contra um usuário do Molly. Um alerta de vulnerabilidade, uma inferência sobre componente afetado e evidências de exploração são conclusões diferentes.
A conclusão mais fortemente sustentada é uma lacuna documentada entre versões, com uma preocupação específica não resolvida sobre um componente.
Essa conclusão é séria o bastante para justificar escrutínio sem se expandir para alegações sem suporte. Dizer que todos os usuários do Molly foram monitorados iria muito além das evidências.
Da mesma forma, esse problema de chamadas não estabelece que históricos de mensagens armazenados foram descriptografados. O mecanismo relatado diz respeito ao encerramento de uma sessão de comunicação ativa.
Manter o escopo preciso ajuda os usuários a tomar decisões proporcionais. Alguém avaliando a privacidade das chamadas precisa de informações diferentes de alguém investigando armazenamento de mensagens ou acesso à conta.
A descrição do aviso envolve outro participante em uma chamada. Ela não descreve estranhos arbitrários ativando remotamente todos os microfones instalados sem uma interação existente.
Esse limite deve permanecer visível sempre que a história for resumida. Remover as condições de ataque pode fazer um alerta parecer mais dramático, ao mesmo tempo em que o torna menos útil.
A ausência de um exploit reproduzido específico do Molly também não deve se transformar em tranquilização. Os usuários não precisam esperar por danos públicos antes de esperarem evidências de que uma correção relevante foi entregue.
É aqui que uma resposta cautelosa à pergunta “o Molly Signal é seguro” precisa resistir a um veredito binário. As evidências identificam uma questão sobre uma versão e um componente específicos, não um julgamento permanente sobre o projeto.
Também não há base verificada aqui para atribuir o atraso a negligência, financiamento, doença ou abandono. Essas explicações exigem declarações ou registros que as estabeleçam.
Os mantenedores podem enfrentar restrições legítimas, mas os usuários ainda vivenciam as consequências de uma entrega atrasada. Entender uma causa e avaliar uma versão são tarefas distintas.
A comparação entre Molly e Signal deve permanecer igualmente disciplinada. A responsabilidade upstream não garante segurança perfeita, enquanto um reforço adicional de segurança não justifica incertezas sobre correções conhecidas.
Para organizações, isso reforça a necessidade de avaliar compilações exatas de aplicativos em fluxos de trabalho sensíveis. Um nome de produto aprovado é insuficiente quando clientes e versões diferentes contêm softwares diferentes.
Para indivíduos, isso reforça a necessidade de verificar o aplicativo real e o canal de atualização antes de fazer suposições. Um ícone tranquilizador ou uma lista de contatos familiar não identifica a dependência subjacente.
A resposta mais forte reduziria a incerteza com evidências. Um backport documentado enfraqueceria a inferência sobre componente afetado. Uma falha reproduzível a fortaleceria. Ambos melhorariam a discussão.
Três sinais determinarão se a confiança se recupera
A lacuna de atualização do Molly se tornará mais fácil de avaliar quando registros públicos conectarem a correção relevante ao software que os usuários podem obter. Outro debate sobre preferências gerais de privacidade não resolverá essa conexão.
Os próximos avanços úteis são uma versão corrigida, uma explicação técnica explícita e evidências de entrega sustentada.
O primeiro sinal é um pacote Molly disponível publicamente com uma correção claramente documentada na biblioteca de chamadas. A versão 2.72.0 upstream do RingRTC oferece uma versão de referência para essa investigação. Um backport equivalente também pode ser relevante, desde que seu conteúdo seja documentado.
Isso fortaleceria a confiança no pacote específico ao abordar diretamente a questão do componente. Uma nova versão sem informações relevantes sobre dependências deixaria mais trabalho para os revisores.
A distribuição importa tanto quanto a publicação. Os usuários precisam do pacote corrigido pelo canal que realmente utilizam, com informações suficientes para reconhecer que a alteração relevante está incluída.
O segundo sinal é uma explicação dos mantenedores que identifique as compilações afetadas e o status da correção. Essa declaração seria mais útil se conectasse alterações no código-fonte, identificadores de versão e qualquer validação disponível.
Uma declaração que confirme um backport existente enfraqueceria materialmente a inferência de que o pacote de julho mantém essa falha. Uma declaração que confirme a exposição esclareceria quais usuários precisam agir.
Qualquer um dos resultados melhoraria o registro público. Especificidade técnica é mais valiosa do que uma garantia ampla de que a segurança continua sendo prioridade.
O terceiro sinal é o que acontece depois que o problema imediato for resolvido. Nos próximos meses, versões regulares e o tratamento explícito de alterações de segurança mostrariam se a entrega voltou a ser confiável.
Uma única versão de recuperação pode resolver um problema urgente. Ela não pode, por si só, estabelecer como o projeto lidará com a próxima correção.
Atrasos repetidos fortaleceriam a preocupação com a dependência de manutenção. Uma entrega consistente enfraqueceria o argumento de que os usuários devem aceitar incerteza prolongada para manter os controles adicionais do Molly.
Esse sinal final importa porque a confiança envolve expectativas sobre o comportamento futuro. Os usuários não podem inspecionar o código de amanhã hoje, mas podem avaliar se um projeto se comunica com clareza e entrega correções de forma previsível.
Para desenvolvedores que mantêm outros forks voltados à segurança, as mesmas evidências oferecem uma referência prática. Expliquem o status dos componentes, identifiquem os pacotes afetados e tornem visível o caminho entre a correção e a instalação.
Para os leitores, mantenham a decisão ancorada em evidências que podem verificar: sua versão instalada, seus componentes documentados e o status das correções relevantes. Evitem tratar uma lista de recursos como substituta desse registro. Se a privacidade das chamadas é importante para seu trabalho ou segurança pessoal, deem o peso apropriado às questões de manutenção não resolvidas ao escolher um cliente. Acompanhem a próxima versão e suas notas técnicas e, então, revisitem a decisão quando esses registros mudarem. A lacuna de atualização do Molly levanta uma questão concreta que merece uma resposta concreta: o aplicativo no seu dispositivo contém a correção necessária para encerrar uma chamada de forma confiável?
