Mollyの更新間隔が、古いSignal通話ライブラリをめぐるセキュリティ懸念を招く
Mollyでは、掲載されている安定版リリースが3か月間出ておらず、追加の保護機能がセキュリティ修正の遅れを伴っていないかという疑問が生じている。Mollyの更新間隔は精査に値する。7月のリリースでは、公開済みの通話終了脆弱性に対処したバージョンより古い通話ライブラリが宣言されているためだ。
2026年11月2日時点で、公開情報はリリースの老朽化と、影響を受ける可能性のある依存関係への懸念を裏付けている。ただし、攻撃者がMollyのユーザーを悪用したことまでは示していない。また、Mollyがカスタマイズしたライブラリに同等の修正が含まれているかどうかも確定していない。
中心にある緊張関係は、追加のセキュリティ機能と迅速なメンテナンスの間にある。Signalはアップストリームのコード、すなわちMollyが適応させる元のソフトウェアを提供している。Mollyのユーザーは、それらの変更を受け取るために別のリリースプロセスに依存している。独自に保守されるソフトウェアの派生版であるセキュリティ重視のフォークは、独自の保護機能と並行して、そのプロセスの信頼性を維持しなければならない。
Mollyの更新間隔が実際に示すこと
Mollyの公開GitHubリリース一覧では、7月31日付のv8.19.2-4が最新リリースとして示されている。そのノートには、設定済みプロキシの使用時に発生するDNSリーク、すなわちドメイン検索の意図しない開示への修正が記載されている。このため、確認できる安定版リリースは本記事の報道日時点で3か月以上前のものとなる。リリース履歴は、この時期に関する中心的な主張を裏付けている。
リリース間隔は検証可能だが、セキュリティ上の影響については別途検証が必要である。
この区別は重要だ。リリース日が答える問いは、見出しがしばしば示唆するものより狭いからである。リリース日は、プロジェクトが特定のチャネルを通じてパッケージを公開した時期を示す。一方で、そのパッケージ内のすべての変更を自動的に明らかにするわけではない。
古いリリースに、選択的に取り込まれたセキュリティ修正が含まれている可能性はある。開発者はこれをバックポート、すなわち新しいリリース全体を採用せずに後の修正を適用すること、と呼ぶ。反対に、最近公開されたパッケージが古い依存関係を保持している可能性もある。
したがって読者にとって有用な問いは、Mollyが非アクティブに見えるかどうかより具体的だ。インストール済みのアプリケーションに、議論されている脆弱性への修正が含まれているかどうかである。
公開上の懸念は、本件のブリーフとともに提供されたコミュニティ投稿を通じて浮上した。そのタイトルは、3か月間の更新停止と脆弱性の両方を主張している。これらの主張は、議論の見出しで並んでいても、検証では別々に扱うべきである。
リリース一覧は最初の主張を裏付ける。2つ目を立証するには、アプリケーションの構成要素を文書化された欠陥と照合し、同等の修正があるかを確認する必要がある。
この手法は、プロジェクト自体について責任を持って言える範囲も限定する。更新のないリリースページは、保守担当者が開発を放棄したことを立証しない。担当者の稼働状況、内部テスト、リリースの障害についても説明しない。
ここでは、この中断について検証済みの説明は確立されていない。理由を断定すれば、観察可能な保守上の問題を、責任者に関する憶測へと変えてしまう。
それでもユーザーは、利用可能なパッケージが古くなっていることを認識するために説明を待つ必要はない。修正版アプリケーションが端末に届くまでは、非公開の開発作業は展開済みの保護を提供しない。
だからこそ、この間隔は今重要である。実際の問いは、確認できない作業の背後にある意図ではなく、人々がインストールできるソフトウェアに関するものだ。
この話題を追う人にとって、調査の出発点は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派生版と説明している。そのドキュメントには、データベースのパスフレーズ保護、自動ロック、メモリ消去、通知受信の代替手段が記載されている。同じドキュメントは、通常の更新を2週間ごとに提供し、利用可能な場合はセキュリティパッチを適用するとしている。これらはプロジェクトが表明する機能と保守上の約束であり、その有効性を独立して検証したものではない。セキュリティ上の約束は、ユーザーに信頼を求める基準を示している。
追加の保護と迅速な修正は異なるリスクに対処するものであり、ユーザーには両方を個別に評価する必要がある。
強化とは、露出を減らしたり被害を限定したりするための対策を加えることを意味する。たとえばデータベースロックは、端末に保存された情報へのアクセスに関わる。通話ライブラリの修正は、通信中の挙動に関わる。
一方の領域で成功しても、他方の安全性は立証されない。機能一覧では、特定の脆弱なコンポーネントが修正済みかどうかには答えられない。
これがMolly対Signalの議論における中心的なトレードオフである。改変されたクライアントを選ぶユーザーは、価値を置く制御機能を得られる一方、別プロジェクトの統合および配布プロセスを受け入れることになる。
この依存関係は、フォークを本質的に安全でないものにするわけではない。そのセキュリティ上の根拠には、追加機能の設計に加え、継続的な運用作業が含まれることを意味する。
アップストリームの修正は、レビュー、統合、ビルド、テスト、署名、配信を経なければならない。署名はソフトウェアパッケージに発行者の識別情報を付加し、端末が認可された更新を認識できるようにする。
各段階は、それぞれ単独で見れば合理的であり得る。しかし、それらを合わせると、公開済みの修正がインストール済みの保護となるまでにユーザーが待つ時間を決定する。
変更がアップストリーム開発と同じ領域に触れる場合、そのコストは特に重要になる。開発者は自らの変更を維持しながら、新しいコードがそれらと正しく動作することを確認しなければならない。
この作業を単なる管理上の負担として軽視すべきではない。ユーザーは完成したパッケージに依存するため、リリースエンジニアリングは製品のセキュリティ境界の一部を成す。
「Molly Signalは安全か」と問う人にとって、答えは考慮するリスクに依存する。保存済みメッセージへの安易なアクセスに対する保護と、悪意ある通話参加者への信頼できる対応は別のものである。
有用な評価では、どの保護が重要か、どのバージョンがインストールされているか、その保守状態をどの証拠が裏付けているかを問う。一つの形容詞にそれらの答えを責任を持ってまとめることはできない。
メインラインのSignalは、元のアプリケーションと通話ライブラリを保守しているため、比較の基準点となる。この関係により下流での統合作業は不要になるが、脆弱性がないことを意味するわけではない。
一方でMollyは、ユーザーが実際に必要とする利点を通じて、追加の保守依存性を正当化しなければならない。コンポーネントの状態が不確かなままであれば、その正当化は難しくなる。
公正な比較は、現在確認可能な挙動に関するものであるべきだ。追加の制御を持つから改変クライアントの方が安全だと仮定したり、元のクライアントに欠陥がないと仮定したりするべきではない。
当面の圧力はMollyのリリースプロセスにかかっている。中断の理由が何であれ、同プロジェクトが表明する保守上の期待に照らせば、目に見える停止には意味がある。
アップストリームの修正は、通話終了が優先される仕組みを変える
Signalに関連付けられたRingRTCの修正は、個別の終了要求フラグを追加し、通常のキュー処理とは独立して終了を確認する。フラグは、コードが直接確認できる保存済みの状態マーカーである。この変更では、待機時間の上限も導入され、特定のエラー後もクリーンアップを継続できるようになっている。これらの詳細はアップストリームの終了修正に記載されている。
技術的な重要性は、通話終了を要求することと、ほかの処理の後ろで待つことを分離した点にある。この修正により、終了はキューが通常どおり進行することへの依存度が低くなる。
別の参加者が予期しない活動を発生させた場合でも、ユーザーが参加を停止するという決定は確実に実行される必要がある。
キューとは、ソフトウェアが処理するまで作業を保持する構造である。キューは一般的で有用だが、緊急のローカル操作がリモートから影響を受けるイベントと処理を共有する場合、その順序は重大になり得る。
この場合、セキュリティ上の問いは、誰が遅延を実質的に制御するのかに関わる。ローカルの参加者は、異常な状況下でも、アプリケーションが通話終了操作に従うことを期待する。
そのため、この問題は通常の使い勝手の欠陥とは異なる。アニメーションの遅延は不便だが、プライバシー上の判断の適用が遅れれば、参加者が伏せるつもりだった情報が露出する可能性がある。
この修正から導かれる、より広い教訓は技術的な推論である。ソフトウェアが競合する入力や悪意ある入力を扱う場合、機微な活動を終了させる制御には明示的な対応が必要だ。
この原則はメッセージングに限られない。録音停止コマンド、セッションの失効、権限の取り消しにも、同様の期待が伴いうる。それぞれには個別の実装レビューが必要であり、この脆弱性が他のシステムに欠陥があることを示すものではない。
本件で焦点となる教訓は、引き続き通話機能である。重要なのは、Mollyの分散ライブラリに、この修正で導入された終了処理が含まれているかどうかだ。
アプリケーションのインターフェースが新しくても、この問いへの答えにはならない。通常の通話が成功しても同様であり、通常動作では、ここで議論している障害条件が必ずしも再現されない。
有用な検証には、異常状態そのものの確認が必要だ。通常の処理が停止したり過負荷になったりした場合にも、ローカルでの終了要求が完全なクリーンアップにつながることを確立すべきである。
だからこそ、ソースコードの変更、ビルド記録、対象を絞った回帰テストがそろえば説得力を持つ。回帰テストは、以前に特定された障害が再発しないことを検証する。
こうした証拠は、それぞれ異なる問いに答える。ソースは意図された動作を示す。ビルド記録は、そのソースとパッケージを結び付ける。テストは、該当する動作が機能するかを調べる。
利用者がこうした分析をすべて自ら行う必要はない。修正内容と影響を受けるリリースを特定するメンテナーの声明があれば、何をインストールすべきかを判断する実用的な根拠になる。
この仕組みは、カレンダー上の経過時間が間接的にしか重要でない理由も説明する。時間は乖離が生じる機会を作るが、この特定の技術的懸念を左右するのは修正の有無である。
Mollyの影響について、なお未検証の点
利用可能な記録には、いくつか未解決の問いが残る。このレビューでは、Molly v8.19.2-4に対してCVE-2026-113380を独自に再現していない。また、Mollyがカスタマイズした通話ライブラリに同等のバックポートが含まれるかも確認していない。
Molly利用者に対する攻撃の成功も立証されていない。脆弱性警告、影響を受けるコンポーネントに関する推論、悪用の証拠は、それぞれ異なる結論である。
現時点で最も強く裏付けられる結論は、特定コンポーネントに関する未解決の懸念を伴う、文書化されたリリース上の隔たりである。
この結論は精査を正当化するほど重大だが、裏付けのない主張へ広げるべきではない。すべてのMolly利用者が監視されていると述べるのは、証拠を大きく超える。
同様に、この通話の問題は、保存済みメッセージ履歴が復号されたことを示すものではない。報告された仕組みは、アクティブな通信セッションの終了に関するものである。
範囲を正確に保つことで、利用者は釣り合いの取れた判断をしやすくなる。通話のプライバシーを見直す人に必要な情報は、メッセージ保存やアカウントアクセスを調査する人の情報とは異なる。
勧告の説明には、通話中の別の参加者が関与する。既存のやり取りなしに、任意の第三者がリモートからすべてのインストール済みマイクを起動できるとは説明していない。
記事を要約する際にも、この境界は明確にしておくべきだ。攻撃条件を省くと、警告はより劇的に聞こえる一方で、有用性は下がる。
Molly固有のエクスプロイトが再現されていないことも、安心材料にすべきではない。利用者は、関連する修正が提供済みであるという証拠を期待するために、公に被害が発生するのを待つ必要はない。
ここで「Molly Signalは安全か」という問いに慎重に答えるには、二者択一の判定を避けなければならない。証拠が示しているのは、特定のリリースとコンポーネントに関する問いであり、プロジェクト全体に対する恒久的な評価ではない。
また、遅延の原因を怠慢、資金不足、病気、放棄に帰する検証済みの根拠もない。そうした説明には、それを立証する声明や記録が必要である。
メンテナーが正当な制約に直面することはあり得るが、利用者は配信遅延の影響を受ける。原因を理解することと、リリースを評価することは別の作業だ。
MollyとSignalの比較も、同様に規律を保つべきである。上流側の所有は完全な安全性を保証せず、追加の強化策が既知の修正に関する不確実性を正当化するわけでもない。
組織にとっては、機微なワークフローで正確なアプリケーションビルドを評価すべきだという示唆になる。クライアントやリリースごとに異なるソフトウェアが含まれる以上、承認済みの製品名だけでは不十分だ。
個人にとっては、前提を置く前に実際のアプリケーションと更新チャネルを確認すべきことを意味する。安心感を与えるアイコンや見慣れた連絡先リストは、基盤となる依存関係を示すものではない。
最も有効な対応は、証拠によって不確実性を狭めることだ。文書化されたバックポートは、影響を受けるコンポーネントという推論を弱める。再現可能な障害はそれを強める。どちらも議論の質を高める。
信頼回復を左右する3つのシグナル
関連する修正と、利用者が取得できるソフトウェアとのつながりが公開記録で示されれば、Mollyの更新上の隔たりは評価しやすくなる。一般的なプライバシー設定をめぐる議論を重ねても、そのつながりは解決しない。
次に有用となる展開は、修正済みリリース、明示的な技術説明、そして継続的な提供の証拠である。
第1のシグナルは、通話ライブラリの修正が明確に文書化された、公開入手可能なMollyパッケージだ。上流のRingRTC version 2.72.0 は、その調査の参照リリースとなる。内容が文書化されていれば、同等のバックポートも重要になり得る。
これは、コンポーネントの問いに直接取り組むことで、特定パッケージへの信頼を高める。関連する依存関係情報のない新バージョンでは、レビュー担当者に残る作業が増える。
公開と並んで配布も重要だ。利用者は、実際に使っているチャネルを通じて修正済みパッケージを入手し、関連する変更が含まれると認識できる十分な情報を必要とする。
第2のシグナルは、影響を受けるビルドと修正の状況を特定するメンテナーの説明である。その説明は、ソース変更、リリース識別子、利用可能な検証を結び付けるものであれば、最も有用となる。
既存のバックポートを確認する声明は、7月のパッケージにこの欠陥が残っているという推論を実質的に弱める。影響を確認する声明は、どの利用者が対応を必要とするかを明確にする。
どちらの結果でも公開記録は改善される。セキュリティを引き続き優先するという包括的な保証より、技術的な具体性の方が価値が高い。
第3のシグナルは、当面の問題への対応後に何が起きるかである。今後数か月にわたり、定期的なリリースとセキュリティ変更への明示的な対応が続けば、配信が再び信頼できるものになったかを示すことになる。
追いつくためのリリースが1回あれば、緊急の問題は解決できる。しかしそれだけで、プロジェクトが次の修正をどう扱うかを示すことはできない。
遅延が繰り返されれば、保守依存関係への懸念は強まる。一貫した提供があれば、Mollyの追加制御を維持するには長期の不確実性を受け入れなければならないという主張は弱まる。
この最後のシグナルが重要なのは、信頼には将来の行動に関する期待が含まれるためだ。利用者は明日のコードを今日検査することはできないが、プロジェクトが明確にコミュニケーションを取り、修正を予測可能に提供しているかは評価できる。
他のセキュリティ重視フォークを保守する開発者にとっても、同じ証拠は実用的な基準を提供する。コンポーネントの状況を説明し、影響を受けるパッケージを特定し、修正からインストールまでの経路を可視化すべきだ。
読者は、確認可能な証拠に判断を置き続けてほしい。インストール済みのバージョン、文書化されたコンポーネント、関連する修正の状況である。機能一覧を、その記録の代替と見なさないこと。通話のプライバシーが仕事や個人の安全に重要なら、クライアントを選ぶ際に未解決の保守上の問題を適切に重視してほしい。次のリリースと技術ノートを追い、その記録が変わった時点で判断を見直すべきだ。Mollyの更新上の隔たりは、具体的な答えに値する具体的な問いを提起する。あなたの端末上のアプリケーションには、通話を確実に終了するために必要な修正が含まれているだろうか。
