Molly 更新缺口引发对旧版 Signal 通话库安全性的担忧

Molly 已连续三个月没有列出的稳定版发布，引发了人们对其额外保护措施是否以延迟安全修复为代价的疑问。Molly 的更新缺口值得审视，因为其 7 月版本声明使用的通话库早于已修复公开通话终止漏洞的版本。

截至 2026 年 11 月 2 日，公开证据支持人们担忧其发布版本正在老化，并可能依赖受影响的组件。但这些证据并不能证明攻击者已利用 Molly 用户，也无法确定 Molly 的定制库是否包含等效修复。

核心矛盾在于额外安全功能与及时维护之间。Signal 提供上游代码，也就是 Molly 所改造的原始软件。Molly 用户需要依赖另一套发布流程来获得这些变更。作为独立维护的软件变体，注重安全的分支版本必须在实现自身保护措施的同时，确保这一流程可靠。

Molly 更新缺口实际说明了什么

Molly 的公开 GitHub 发布列表显示，最新版本为 7 月 31 日发布的 v8.19.2-4。其发布说明称，修复了在使用已配置代理时发生的 DNS 泄漏，即域名查询被意外暴露的问题。这意味着可见的稳定版本已比本文报道日期落后三个多月。发布历史支持这一核心时间判断。

发布缺口可以核实；其安全后果则需要单独审查。

这一区别很重要，因为发布日期回答的问题比标题常常暗示的更为有限。它们只能表明项目何时通过特定渠道发布了一个软件包，并不会自动揭示该软件包包含的所有变更。

旧版本可能包含选择性引入的安全修复。开发者将此称为回移：在不采用整个较新版本的情况下应用后续修正。反过来，近期发布的软件包也可能仍保留过时依赖项。

因此，对读者而言，更有用的问题并非 Molly 是否看起来处于停滞状态，而是已安装的应用是否包含针对所讨论漏洞的修复。

公众担忧源于随本文简报提供的一篇社区帖子。其标题同时声称已停更三个月且存在漏洞。即使它们同时出现在讨论标题中，这些说法也应分别经过核实。

发布列表证实了第一项说法。要确认第二项，则需要将应用组件与已记录的漏洞进行比对，再检查是否存在等效修复。

这种方法也限制了我们能够对项目本身作出的负责任表述。一个沉寂的发布页面不能证明维护者已停止开发，也无法说明他们的可用时间、内部测试或发布障碍。

本文无法证实此次停更的原因。对此作出归因，会将可观察到的维护问题变成对相关负责人的猜测。

不过，用户无需等待解释，便能意识到当前可获得的软件包正在老化。私下进行的开发工作，在修复后的应用到达用户设备之前，无法提供已部署的保护。

这正是这一缺口此刻重要的原因。实际问题涉及人们能够安装的软件，而非他们无法审查的工作背后的意图。

对于关注此事的人来说，7 月这个日期应是调查的起点。依赖项记录则提供了下一项、也更具影响力的证据。

较旧的通话依赖项使担忧具体化

与 Molly v8.19.2-4 相关的源代码将其 Android RingRTC 依赖项声明为 im.molly:ringrtc-android:2.69.5-1。RingRTC 是处理 Signal 相关通话功能的软件库。带标签的通话依赖项提供了一个可供具体审查的组件。

已发布的漏洞记录 CVE-2026-113380 指出，上游 RingRTC 2.72.0 之前的版本存在通话终止问题。CVE 是用于跟踪已披露漏洞的公开标识符。该记录描述了当另一名通话参与者使内部队列饱和时，对挂断处理造成的干扰。音频，甚至可能包括视频，可能仍在传输。通话终止公告于 10 月 20 日发布。

声明的依赖项让这篇报道的技术依据超越了应用版本的老旧程度。

不过，Molly 的依赖项使用了项目自己的软件包命名空间和版本后缀。这构成了重要的核实边界。其版本号低于上游修复版本，但仅凭版本号并不能证明源代码内容完全相同。

要作出确切评估，需要检查用于构建已分发应用的确切库，并确定其中是否存在相关修复，或功能等效的变更。

本文尚未完成这种制品级别的检查。制品指实际分发的软件文件，而不是描述如何构建它的源代码清单。

因此，现有证据支持“可能受影响的依赖项”和“需要澄清”这两个判断，但不足以将针对 Molly 的成功攻击描述为已被独立证实。

这一区别对考虑进行敏感通话的用户很有帮助。他们需要知道手机上运行的组件是否受到影响。关于加密的笼统保证无法回答这个问题。

端到端加密保护通信端点之间的内容，但其本身并不能决定端点是否会在收到指令后停止传输。一次通话可以保持加密，同时其行为仍违背参与者的预期。

设想一名研究人员在与身边有人讨论机密材料前结束采访。隐私边界就在麦克风停止发送音频的那一刻。

若这一边界失效，传输过程中的强保护也无法恢复用户预期的控制权。这个场景说明了所报告漏洞的重要性；它并非已记录的 Molly 事件。

同样的区别也适用于工作通话、消息源采访和私人对话。用户通常根据参与是否已结束来作出决定，而不会检查底层应用状态。

对开发者而言，眼下的责任十分明确。证明修复已存在，比比较应用版本号或重复笼统的安全声明更能消除不确定性。

额外加固仍依赖于维护

Molly 将自身描述为注重安全的 Signal 变体。其文档列出了数据库口令保护、自动锁定、内存擦除以及接收通知的替代方案。同一文档称，常规更新每两周发布一次，并会在安全补丁可用时加以应用。这些是项目宣称的功能和维护承诺，而非对其有效性的独立验证。其安全承诺确立了用户被要求信任的标准。

额外保护与及时修复应对的是不同风险，用户需要分别评估两者。

加固是指增加旨在降低暴露风险或限制损害的措施。例如，数据库锁涉及访问存储在设备上的信息；通话库修复则涉及通信期间的行为。

一个领域的成功并不能证明另一个领域的安全。功能列表无法回答某个存在漏洞的特定组件是否已被修复。

这正是 Molly 与 Signal 讨论中的核心权衡。选择修改版客户端的用户可以获得他们重视的控制功能，同时也接受了另一个项目的集成与分发流程。

这种依赖并不意味着分支版本天然不安全，而是表示其安全性还取决于持续的运营工作，以及额外功能本身的设计。

上游修复必须经过审查、集成、构建、测试、签名和交付。签名会将发布者身份附加到软件包上，使设备能够识别获授权的更新。

每一个阶段本身都可能合理。它们共同决定了用户要等待多久，已发布的修复才能成为设备上实际安装的保护。

当修改涉及与上游开发相同的领域时，这一成本尤为相关。开发者必须保留自己的变更，同时确认新代码能与这些变更正确协作。

这项工作不应被轻视为行政开销。发布工程构成产品安全边界的一部分，因为用户依赖最终生成的软件包。

因此，对于询问“is Molly Signal safe”的人而言，答案取决于所考虑的风险。防范他人随意访问存储消息，与可靠应对恶意通话参与者并不是一回事。

有用的评估会询问哪些保护措施重要、安装了哪个版本，以及哪些证据支持其维护状态。单个形容词无法负责任地整合这些答案。

主线 Signal 提供了一个参照点，因为它维护原始应用和通话库。这种关系消除了一个下游集成步骤，尽管这并不意味着它没有漏洞。

与此同时，Molly 必须通过用户实际需要的收益来证明额外维护依赖的合理性。当组件状态仍不明确时，这种证明会更加困难。

公平的比较应聚焦于当前可核实的行为。它不应假定修改版客户端因增加控制功能就更安全，也不应假定原始客户端毫无缺陷。

直接压力落在 Molly 的发布流程上。无论背后原因如何，其宣称的维护预期都使可见的停更具有重要影响。

上游修复改变了通话终止的优先级处理方式

Signal 关联的 RingRTC 修复增加了一个独立的终止请求标志，并将终止检查与普通队列处理分开进行。标志是代码可以直接检查的已存储状态标记。该变更还引入了有界等待，并允许清理工作在某些错误后继续进行。这些细节可见于上游终止修复。

技术意义在于，将请求结束通话与等待其他工作处理分离。该修复使终止操作较少依赖于队列是否正常推进。

即使另一名参与者产生意外活动，用户停止参与的决定也需要得到可靠执行。

队列是一种在软件处理前暂存工作的结构。队列很常见且很有用，但当紧急的本地操作与受远程影响的事件共用处理流程时，其排序便可能产生重要影响。

在这种情况下，安全问题涉及谁实际上控制了延迟。本地参与者期望应用即使在异常条件下，也能遵从挂断操作。

这使得该问题不同于一般的可用性缺陷。动画延迟只是不便；而隐私决定的执行延迟，可能会暴露参与者原本希望保密的信息。

从这次修正中可以推导出更广泛的工程经验：当软件需要处理相互冲突或带有敌意的输入时，终止敏感活动的控制机制应获得明确处理。

这一原则并不局限于消息通信。停止录音命令、会话撤销或权限收回也可能承载类似预期。每一种情况都需要独立的实现审查；这一漏洞并不能证明其他系统也存在缺陷。

就本报道而言，重点仍在通话。相关问题是，Molly 的分布式库中是否包含此次修正引入的终止行为。

较新的应用界面无法回答这个问题。普通通话成功也无法回答，因为正常运行未必会触发当前讨论的故障条件。

有价值的验证需要审查异常条件本身。它应确认：当常规处理停滞或过载时，本地终止请求仍会完成清理工作。

这正是源代码变更、构建记录和针对性的回归检查结合起来具有说服力的原因。回归检查用于验证此前已识别的故障不会再次出现。

这些证据形式回答的是不同问题。源代码说明预期行为；构建记录将该源代码关联到软件包；测试则检验相关行为是否实际有效。

用户不应必须亲自完成所有这些分析。维护者若能声明修正内容及受影响版本，就能为用户决定安装什么提供实际依据。

这一机制也解释了为何日历时间的久远程度仅具有间接意义。时间会创造分歧出现的机会，但是否包含修正才决定这一特定技术问题是否存在。

Molly 的受影响情况仍有哪些未获验证之处

现有记录仍留下若干未解问题。本次审查尚未独立复现针对 Molly v8.19.2-4 的 CVE-2026-113380。也未能确认 Molly 定制的通话库是否包含等效的回移修复。

同样，也尚未确认针对 Molly 用户的成功攻击。漏洞警告、受影响组件的推断以及遭到利用的证据，是三种不同的发现。

现有证据最有力支持的结论是：存在有记录的版本差距，并且对某个具体组件仍有未解决的担忧。

这一结论足以构成审查理由，但不应扩展为缺乏证据支撑的说法。声称每一位 Molly 用户都已受到监控，将远远超出证据范围。

同样，这一通话问题并不能证明已存储的消息历史遭到解密。报告所述机制涉及的是活动通信会话的终止。

保持范围精确有助于用户作出相称的决定。审查通话隐私的人，需要的信息不同于调查消息存储或账户访问问题的人。

该公告的描述涉及通话中的另一名参与者。它并未描述陌生人无需既有互动，便可远程激活所有已安装应用的麦克风。

无论何时概述这一事件，都应保留这一边界。省略攻击条件会让警告听起来更戏剧化，却也更缺乏实用性。

未复现 Molly 特有的漏洞利用，也不应被视为令人放心的理由。用户无需等到公开伤害发生，才有理由期待看到相关修正已经发布的证据。

正因如此，对“is Molly Signal safe”的谨慎回答必须避免二元判断。现有证据指出的是某个特定版本和组件的问题，而不是对该项目作出永久性评判。

这里同样没有经过验证的依据，可将延迟归咎于疏忽、资金不足、疾病或项目被放弃。此类解释需要能够证明它们的声明或记录。

维护者可能面临合理限制，但用户仍会承受交付延迟的后果。理解原因与评估某个版本是两项不同任务。

Molly 与 Signal 的比较也应保持同样严谨。上游所有权并不保证绝对安全；额外加固也不能成为对已知修正存在不确定性的借口。

对于组织而言，这意味着在敏感工作流中应评估确切的应用构建版本。当不同客户端和版本包含不同软件时，仅凭获批准的产品名称并不足够。

对于个人而言，这意味着在作出假设前，应检查实际应用及其更新渠道。令人安心的图标或熟悉的联系人列表，并不能识别其底层依赖项。

最有力的回应应通过证据缩小不确定性。有记录的回移修复将削弱受影响组件的推断；可复现的故障则会强化这一推断。两者都会改善讨论质量。

三个信号将决定信心能否恢复

当公开记录能够将相关修正与用户可获取的软件联系起来时，Molly 的更新差距将更容易评估。围绕一般隐私偏好的另一场讨论，无法解决这种关联。

接下来最有价值的发展包括：修正后的版本、明确的技术说明，以及持续交付的证据。

第一个信号是公开可获取的 Molly 软件包，其中应清晰记录通话库修正。上游 RingRTC version 2.72.0 为该调查提供了参考版本。等效的回移修复同样可能重要，前提是其内容得到记录。

这将通过直接回应组件问题，增强对该特定软件包的信心。若新版本未提供相关依赖信息，审查者仍需进行更多工作。

发布之外，分发也同样重要。用户需要通过自己实际使用的渠道获得修正后的软件包，并拥有足够信息来确认其中包含相关变更。

第二个信号是维护者的说明，明确指出受影响的构建版本及修正状态。如果该说明能够关联源代码变更、发布标识符和任何可用验证结果，其价值将最大。

确认已有回移修复的声明，将实质性削弱“7 月软件包仍保留该缺陷”的推断。确认存在受影响情况的声明，则会明确哪些用户需要采取行动。

无论结果如何，都会改善公开记录。技术细节比笼统保证“安全仍是优先事项”更有价值。

第三个信号是紧急问题解决之后的后续表现。在未来数月内，规律发布版本并明确处理安全变更，将显示交付是否重新变得可靠。

一次补救性发布可以解决紧急问题。但它本身无法证明项目将如何应对下一次修正。

反复延迟将强化对维护依赖关系的担忧。持续稳定的交付则会削弱这样一种观点：用户必须接受长期不确定性，才能保留 Molly 的额外控制功能。

这一最终信号之所以重要，是因为信任涉及对未来行为的预期。用户今天无法检查明天的代码，但可以评估项目是否沟通清晰，以及是否能可预测地交付修正。

对于维护其他安全导向分支的开发者而言，同样的证据提供了实用基准：说明组件状态，识别受影响的软件包，并让从修正到安装的路径清晰可见。

对于读者而言，应将决定锚定在可核查的证据上：已安装的版本、其文档化的组件，以及相关修正的状态。不要将功能列表当作这类记录的替代品。如果通话隐私对你的工作或人身安全至关重要，在选择客户端时，应对未解决的维护问题给予恰当权重。关注下一次发布及其技术说明，并在这些记录发生变化时重新评估决定。Molly 的更新差距提出了一个值得获得具体答案的具体问题：你设备上的应用是否包含可靠结束通话所需的修正？