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 討論中的核心取捨。選用修改版客戶端的用戶，可獲得他們重視的控制功能，同時接受另一項目的整合及發行流程。
這種依賴關係並不代表軟件分支天生不安全。它意味其安全論據除了額外功能的設計外，也包括持續的營運工作。
上游修正必須經過審閱、整合、建構、測試、簽署及交付。簽署會將發布者身分附加至軟件套件，使裝置可辨識獲授權的更新。
每個階段本身都可能合理。合併而言，這些階段決定用戶在已發布修正成為已安裝保護前要等多久。
當修改涉及與上游開發相同的領域時，這項成本尤其相關。開發者必須保留自身變更，同時檢查新程式碼能否與之正確運作。
這項工作不應被視為行政負擔。發布工程構成產品安全邊界的一部分，因為用戶依賴最終產生的套件。
因此，對於問「Molly Signal 是否安全」的人，答案取決於所考慮的風險。防止他人隨意存取已儲存訊息，與可靠處理惡意通話參與者是不同的事情。
有用的評估會問：哪些保護措施重要、安裝的是哪個版本，以及哪些證據支持其維護狀態。單一形容詞無法負責任地整合這些答案。
主線 Signal 提供參考點，因為它維護原始應用程式及通話函式庫。這種關係省卻下游整合步驟，但不代表完全沒有漏洞。
與此同時，Molly 必須透過用戶實際需要的好處，證明額外維護依賴關係的合理性。當元件狀態仍不明確時，這項證明更為困難。
公平的比較關乎目前可核實的行為。它不應假定修改版客戶端因加入控制功能而較安全，也不應假定原始客戶端毫無缺陷。
眼前壓力落在 Molly 的發布流程上。無論背後原因為何，其聲明的維護期望令可見的停頓具有重要性。
上游修正改變通話終止的優先次序
Signal 所連結的 RingRTC 修正加入獨立的終止請求旗標，並使終止檢查不依賴一般佇列處理。旗標是程式碼可直接檢查的已儲存狀態標記。這項變更亦加入有界等待，並容許在某些錯誤後繼續清理。這些細節見於上游的終止修正。
其技術意義在於，把要求結束通話與等待其他工作處理分開。這項修正令終止較少依賴佇列按正常方式推進。
即使另一名參與者產生非預期活動，用戶停止參與的決定亦需要可靠執行。
佇列是一種保存工作直至軟件處理的結構。佇列很常見且實用，但當緊急的本機操作與受遠端影響的事件共用處理流程時，其排序可能變得關鍵。
在這個情況下，安全問題關乎誰能實際控制延遲。本機參與者期望應用程式會遵從掛斷操作，即使在異常情況下亦然。
這使問題有別於一般的易用性缺陷。動畫延遲只是不便；延遲執行私隱決定，則可能令通話參與者原本想保密的資訊外洩。
從這次修正可得出更廣泛的工程推論：當軟件要處理相互競爭或惡意的輸入時，終止敏感活動的控制項應獲明確處理。
這項原則不僅適用於訊息通訊。停止錄音指令、撤銷工作階段或撤回權限，也可能帶有類似的預期。每一種情況都需要獨立檢視其實作；此漏洞並不代表那些其他系統亦存在缺陷。
就此報道而言，重點仍在通話。相關問題是 Molly 的分散式函式庫是否包含這次修正所引入的終止行為。
較新的應用程式介面不足以解答這個問題。一般通話能成功進行亦不能，因為正常運作未必會觸發目前討論的故障情況。
有用的驗證必須檢查異常情況本身。它應證實，當一般處理程序停滯或負荷過重時，本機的終止要求仍會完成清理工作。
因此，原始碼變更、建置記錄及針對性的迴歸檢查，如能一併提供便具說服力。迴歸檢查可驗證先前識別的故障不會重現。
這些形式的證據回答的是不同問題。原始碼確立預期行為；建置記錄將該原始碼連結至套件；測試則檢視相關行為是否正常運作。
用戶不應被迫親自完成所有這些分析。維護者如發表聲明，指出修正內容及受影響版本，便可讓用戶有實際依據決定應安裝甚麼。
該機制亦說明，日曆上的時間長度只屬間接因素。時間會造成版本分歧的機會，但有沒有納入修正才決定這項特定技術疑慮是否存在。
關於 Molly 是否受影響，仍有哪些未經驗證之處
現有記錄仍留下數個未解問題。本審查並未獨立重現 CVE-2026-113380 對 Molly v8.19.2-4 的影響，亦未確定 Molly 經客製化的通話函式庫是否包含等效的回移修正。
本審查亦未證實曾有針對 Molly 用戶的成功攻擊。漏洞警告、受影響元件的推論，以及遭利用的證據，是不同層次的發現。
現有證據最有力支持的結論是：存在已記錄的發行版本落差，並有一項尚未解決的特定元件疑慮。
這個結論足以支持進一步審視，但不應延伸為缺乏依據的說法。聲稱每一位 Molly 用戶都曾遭監聽，將遠超出證據所能支持的範圍。
同樣地，這項通話問題並不代表已儲存的訊息紀錄遭解密。已報告的機制涉及終止一個正在進行的通訊工作階段。
保持範圍精確，有助用戶作出合乎比例的決定。檢視通話私隱的人，需要的資訊與調查訊息儲存或帳戶存取的人並不相同。
公告的描述涉及通話中的另一名參與者。它並未描述陌生人可在沒有既有互動的情況下，遙距啟動每一部已安裝應用程式的咪高峰。
每次概述此事件時，都應清楚保留這項界線。移除攻擊條件，可能令警告聽來更戲劇化，卻也更不實用。
沒有重現針對 Molly 的特定漏洞利用，也不應被視為令人安心的理由。用戶不必等到公開傷害出現，才合理期待有證據顯示相關修正已經推出。
這正是審慎回答「Molly Signal 是否安全」時，必須避免二元結論的地方。證據指出的是某個特定版本及元件的問題，而非對該專案作出永久判斷。
同樣沒有經驗證的依據，可將延遲歸因於疏忽、資金、疾病或放棄維護。這些解釋需要能夠證明的聲明或記錄。
維護者可能面對合理的限制，但用戶仍會承受延遲交付的後果。理解原因與評估一個版本，是兩項不同工作。
Molly 與 Signal 的比較亦應保持同樣嚴謹。上游擁有權並不保證絕對安全，而額外的強化措施亦不能為已知修正的不確定性開脫。
對機構而言，這意味著在敏感工作流程中，應評估確切的應用程式建置版本。不同客戶端及版本包含不同軟件時，僅憑獲批准的產品名稱並不足夠。
對個人而言，這意味著在作出假設前，應檢查實際使用的應用程式及更新渠道。一個令人安心的圖示或熟悉的聯絡人清單，並不能識別其底層相依元件。
最有力的回應，是以證據縮窄不確定性。有記錄的回移修正會削弱受影響元件的推論；可重現的故障則會強化該推論。兩者都會改善討論。
三項訊號將決定信心能否恢復
當公開記錄將相關修正連結至用戶實際可取得的軟件時，Molly 的更新落差將更容易評估。再多關於一般私隱偏好的辯論，也無法解決這項連結問題。
下一步有用的發展，是推出已修正的版本、提供明確的技術說明，以及持續交付的證據。
第一項訊號，是公開提供的 Molly 套件，並清楚記錄其通話函式庫修正。上游 RingRTC 版本 2.72.0 為這項調查提供參考版本。如有記錄其內容，等效的回移修正亦同樣重要。
這會直接處理元件問題，從而增強對該特定套件的信心。沒有相關相依元件資訊的新版本，仍會令審查者需要做更多工作。
除了發布，分發亦同樣重要。用戶需要透過自己實際使用的渠道取得已修正套件，並有足夠資訊辨識其中已包含相關變更。
第二項訊號，是維護者說明受影響建置版本及修正狀態。若該聲明能連結原始碼變更、發行識別碼及任何可取得的驗證資料，便最為有用。
確認已有回移修正的聲明，會實質削弱 7 月套件仍保留此缺陷的推論。確認存在影響的聲明，則可釐清哪些用戶需要採取行動。
無論結果如何，都會改善公開記錄。技術細節比泛稱安全仍是優先事項的保證更有價值。
第三項訊號，是即時問題獲處理後的發展。在未來數月，如能定期發布版本並明確處理安全變更，將顯示交付是否再次變得可靠。
一次追趕進度的發布可以解決緊急問題，但單靠一次發布，無法確立專案將如何處理下一項修正。
反覆延遲會加深人們對維護相依性的憂慮；持續交付則會削弱一種說法，即用戶若要保留 Molly 的額外控制功能，便必須接受長期不確定性。
最後這項訊號很重要，因為信任牽涉對未來行為的預期。用戶今天無法檢查明天的程式碼，卻可以評估專案是否清楚溝通，並可預期地交付修正。
對維護其他以安全為重點的分支版本的開發者而言，同一類證據提供了實用基準：說明元件狀態、識別受影響套件，並讓從修正到安裝的路徑清晰可見。
對讀者而言，請把決定錨定在可查核的證據上：已安裝的版本、其有記錄的元件，以及相關修正的狀態。不要將功能清單當作該記錄的替代品。若通話私隱對你的工作或人身安全十分重要，選擇客戶端時應適當重視尚未解決的維護問題。留意下一個版本及其技術說明，並在那些記錄改變時重新檢視決定。Molly 的更新落差提出了一個具體問題，值得一個具體答案：你裝置上的應用程式，是否包含可靠結束通話所需的修正？
