Roundcubeに脆弱性10件、CVE採番は8日後

オープンソースのWebメールクライアント「Roundcube Webmail」に、リモートコード実行（RCE）を含む複数の脆弱性が見つかりました。開発元は2026年8月9日に修正版 1.6.18（LTS） と 1.7.3（安定版） を公開し、「すべての本番環境を更新するよう強く推奨する」としています。

ただし、この更新には情シスが引っかかりやすい落とし穴が2つあります。ひとつは、公開時点でCVE番号が1件も付いていなかったこと（採番されたのは8日後の8月17日）。もうひとつは、Roundcubeがレンタルサーバの管理パネルやLinuxディストリビューションのパッケージに同梱されていて、自社で直接更新できない構成が多いことです。

今すぐ確認すべきは「社内・委託先のメール環境でRoundcubeが動いていないか」「そのバージョンは 1.6.18 / 1.7.3 以上か」の2点です。

この記事でわかること

  • Roundcubeとは何をするもので、どこに同梱されて動いているのか
  • 2026年8月9日の更新で塞がれた脆弱性の一覧と、それぞれの成立条件
  • 最も深刻な markasjunk プラグインのRCEが、なぜ「置換の順番」で起きたのか
  • CVE番号が8日遅れたことが、脆弱性管理の実務に何をもたらすか
  • 自社が該当するかを確認する具体的な手順と、更新できない場合の考え方

Roundcubeとは何者か — 「うちは使っていない」と即断しないために

Roundcube Webmailとは、ブラウザからIMAPのメールサーバに接続してメールを読み書きするための、オープンソースのWebメールソフトです。PHPで書かれており、メールサーバそのものではなく、その「顔」にあたる画面を提供します。

使う場面は主に2つです。ひとつは自社でメールサーバ（Postfix + Dovecot など）を運用していて、社員がブラウザから読めるようにしたいケース。もうひとつは、レンタルサーバやホスティング事業者が「Webメール」機能として利用者に提供しているケースです。

問題はどこに組み込まれているかです。Roundcubeは単体でインストールした覚えがなくても、次のような形で動いていることがあります。

  • サーバ管理パネルの同梱コンポーネント：たとえばPleskでは、Roundcubeが公式ドキュメント上「Recommended（推奨）プリセットに含まれる」Webメールとして提供されています。この場合、Roundcube本体を管理しているのはパネル側です。
  • Linuxディストリビューションのパッケージ：Debian／Ubuntu には roundcube パッケージがあり、apt で導入した覚えがあるだけで実体はRoundcubeです。
  • レンタルサーバの「Webメール」機能：契約先の管理画面から使えるWebメールの中身がRoundcubeであることは珍しくありません。自社の資産台帳には「レンタルサーバ」としか載っていない可能性があります。

つまり、情シスから見ると「Roundcubeというソフトを導入した記憶がないのに、社内のどこかで動いている」という状態になりやすい製品です。後述する確認手順で、まず存在の有無を押さえてください。

何が起きたのか

Roundcube開発チームは2026年8月9日、1.6系と1.7系に対するセキュリティ更新 1.6.18 / 1.7.3 を公開しました。リリースノートには11項目のセキュリティ修正が並んでいます。内容はRCE、IMAPコマンドインジェクション、LDAPフィルタインジェクション、Sieveスクリプトの注入、SSRFフィルタの回避、格納型XSS、認証トークンの漏えいと多岐にわたります。

その後、2026年8月17日にNVDへ10件のCVEが登録されました。深刻度と成立条件を整理すると次のとおりです。

CVE 内容 CVSS 3.1 成立の前提
CVE-2026-74997 markasjunk プラグイン cmd_learn ドライバ経由のRCE（CWE-78） 8.8（重要） markasjunk を cmd_learn ドライバで使っている環境のみ
CVE-2026-74998 CSSプロキシの応答が未検証。MIMEスニッフィングで情報漏えい／XSS 7.2（重要） 認証不要
CVE-2026-75002 メール検索とLITERAL+のバイト数ずれによるIMAPコマンドインジェクション 7.1（重要） 要ログイン。攻撃条件は高
CVE-2026-75010 password プラグインの modoboa ドライバがAPI認証トークンを外部ホストへ漏えい 6.4（警告） password プラグインの modoboa ドライバ使用時のみ
CVE-2026-75000 SVG animate の by 属性のサニタイズ不備でリモート画像ブロックを回避 5.8（警告） 認証不要
CVE-2026-75003 FuncIRI属性内の閉じられていない url() でリモート画像ブロックを回避 5.8（警告） 認証不要
CVE-2026-75006 HTMLメール内のCSSサニタイズ不備によるSSRF／情報漏えい（CWE-918） 5.8（警告） 認証不要
CVE-2026-74999 「アドレス帳に追加」操作の格納型XSS 5.4（警告） 要ログイン・利用者操作
CVE-2026-75007 LDAP検索フィルタへの %u／%fu／%d 未エスケープ置換によるインジェクション 5.4（警告） LDAPアドレス帳を使っている環境
CVE-2026-75004 Sieveルール名の引用符処理不備で managesieve_disabled_actions を回避 4.3（警告） managesieve プラグイン使用時のみ
NVD掲載の10件。リリースノートの修正項目は11件で、CGNAT（100.64.0.0/10）やリンクローカル（fe80::/10）、nip.io／sslip.io 形式のホスト名を使ったSSRFフィルタ回避の一部は、独立したCVEとしてNVDに掲載されていません（2026年8月27日時点）。

表を見て分かるとおり、深刻度が高いものほど「特定のプラグイン構成を使っている場合のみ」という条件が付いています。逆に、CVSSは中程度でも認証不要で成立するものが複数あります。優先度を付ける際は、スコアだけでなくこの前提条件を自社構成と突き合わせてください。

最も深刻なRCEは、どういう条件で成立するのですか

スパム学習用の外部コマンド連携を有効にしている環境だけです。既定では無効なので、多くの環境は対象外になります。

該当するのは CVE-2026-74997 で、markasjunk（「迷惑メールとして報告」ボタンを追加するプラグイン）の cmd_learn ドライバを使っている構成です。このドライバは、SpamAssassin の sa-learn のような外部コマンドを呼び出して学習させるためのもので、プラグイン同梱の設定ファイルでは markasjunk_learning_driver が null（未使用）になっています。つまり管理者が明示的に有効化した環境が対象です。

なぜ「置換の順番」で穴が開いたのか

この脆弱性は、自分たちのコードにも起こりうる典型的な失敗なので、少し踏み込んでおきます。

cmd_learn は、管理者が設定した実行コマンドのテンプレートに含まれる %u（ユーザー名）、%s（送信者アドレス）、%h:ヘッダ名（メールヘッダの値）といったプレースホルダを、実際の値に置き換えてからシェルで実行します。値はきちんと escapeshellarg() でエスケープされていました。

問題は置換を1つずつ順番に行っていたことです。修正前のコードは %u を置換した文字列に対して、次に %s の置換をかけ、さらに %h:... の置換をかける、という作り方でした。エスケープ済みの文字列の中に別のプレースホルダが紛れ込んでいると、後続の置換がその内側に値を差し込んでしまい、引用符の対応が壊れます。エスケープ自体は正しく行われているのに、後から差し込まれた結果としてシェルのメタ文字が有効になってしまう、という筋道です。

修正版では、置換対象をいったん対応表にまとめ、strtr() で一度にまとめて置換する形に変わりました。これなら置換結果が再スキャンされないため、入れ子の問題が起きません。あわせて、ユーザー名の取得元がセッション変数の直接参照から専用メソッドへ改められています。

置換元の値には、送信者アドレスやメールヘッダといった外部から届く値が含まれます。詳細な攻撃手順は公開されていないため断定は避けますが、「入力を個別にエスケープしたから安全」という発想が、多段の文字列置換と組み合わさると崩れる、という教訓は自社の内製ツールにもそのまま当てはまります。

CVE番号は8日遅れて付いた — 脆弱性フィード頼りの盲点

実務上、今回いちばん効いてくるのはここだと考えています。

8月9日のリリースノートには、11件の修正が並んでいるにもかかわらずCVE番号がひとつも書かれていませんでした。直前の7月5日の更新（1.6.17／1.7.2）ではCVE-2026-54432・CVE-2026-54433といった番号が明記されていたので、なおさら見落としやすい形です。CVEがNVDに登録されたのは8日後の8月17日でした。

脆弱性管理をCVEフィードやスキャナの検知に任せている組織では、この8日間は「更新が出ているのに、管理台帳上は何も起きていない」状態になります。RCEを含む更新でこの空白が生まれるのは、率直に言って怖いところです。SBOMを整備してツールで回している組織ほど、逆に「ツールが鳴らない＝問題なし」と読んでしまいがちで、ここは仕組みの限界として認識しておく必要があります。

対策として現実的なのは、自社で使っている主要OSSについては、ベンダーのリリース告知そのものを購読しておくことです。Roundcubeであれば公式のニュースページやGitHubのリリース通知が該当します。すべてのソフトに適用するのは非現実的なので、「外部公開されている」「認証情報やメールを扱う」ものに絞るのが落としどころでしょう。

同じ守りが繰り返し破られている

今回の内容を過去と並べると、気になる傾向が見えます。

まずSSRFフィルタです。CVE-2026-75006 の説明には、「CVE-2026-35540、CVE-2026-48843、CVE-2026-62643 の修正が不十分だったために存在する」と明記されています。HTMLメール内のCSSを経由して内部ネットワークへリクエストを飛ばさせる攻撃に対し、同じ防御（ローカルアドレスかどうかの判定）が繰り返し回避されてきたということです。今回塞がれたのも、CGNAT帯（100.64.0.0/10）やIPv6リンクローカル（fe80::/10）、そしてIPアドレスをホスト名に埋め込める nip.io／sslip.io といった抜け道でした。「拒否リスト方式のSSRF対策は破られ続ける」という、教科書どおりの構図です。

もうひとつはSVGの animate 属性です。今回の CVE-2026-75000 は animate の by 属性のサニタイズ不備ですが、同じ animate を起点とするXSSは過去に2度、CISAの「悪用が確認された脆弱性カタログ（KEV）」に載っています（CVE-2024-37383、CVE-2025-68461）。RoundcubeはKEVに累計11件登録されている常連であり、攻撃者が継続的に狙っている対象だと考えたほうが現実的です。

自社に該当するかを確認する

資産台帳に「Roundcube」と書かれていない可能性が高いので、次の順で確認します。

  1. 存在の確認：自社メールサーバやホスティング契約に「Webメール」機能があるか洗い出します。ブラウザで開いたときのログイン画面に “Roundcube Webmail” と表示されていれば該当です。
  2. 導入経路の判別：ディストリのパッケージなら dpkg -l | grep roundcube（Debian／Ubuntu系）や rpm -qa | grep roundcube（RHEL系）で分かります。ヒットしなければ、Webルート配下に展開されたtarball導入か、管理パネル同梱の可能性が高くなります。
  3. バージョンの確認：tarball導入の場合は設置ディレクトリで grep RCMAIL_VERSION program/include/iniset.php を実行します。1.6.18 / 1.7.3 以上であれば対応済みです。
  4. プラグイン構成の確認：config/config.inc.php のプラグイン設定に markasjunk / managesieve / password が入っているか、markasjunk については plugins/markasjunk/config.inc.php の markasjunk_learning_driver が cmd_learn になっていないかを見ます。ここが最重要RCEの該当判定です。

ディストリのパッケージを使っていれば安全ですか

いいえ。2026年8月27日時点では、Debianの安定版はまだ修正版に追いついていません。

Debianセキュリティトラッカーの同日時点の情報では、trixie（安定版）のセキュリティ更新が 1.6.17、bookworm が 1.6.5系、bullseye が 1.4.15系で、いずれも今回の10件について「vulnerable（脆弱）」と表示されています。修正済みとされているのは forky／sid（開発版）の 1.6.18 のみです。apt upgrade を流しただけでは、まだ塞がっていない可能性があります。ディストリのパッケージを使っている場合は、セキュリティトラッカーで自分のリリースの状態を直接確認し、更新が降りてくるまでは後述の緩和策で凌ぐ判断になります。なお、この状況は日々変わるので、必ず最新の状態を見てください。

レンタルサーバや管理パネル経由の場合は

この構成では、利用者側でRoundcubeだけを勝手に入れ替えるべきではありません。パネル側の管理下にあるファイルを差し替えると、次回のパネル更新で巻き戻ったり、整合性が壊れて動かなくなったりします。過去の重大なRoundcube脆弱性でも、Pleskは自社の更新として修正版を配信する形をとっていました。したがって現実的な動きは、契約先・パネルベンダーの告知を確認し、修正版の配信予定を問い合わせることです。委託先が運用しているメール環境がある場合は、同じ内容を委託先に確認する必要があります。

情シスはどうすべきか

やることは「更新する」の一言なのですが、上で見たとおり自分で更新できる構成とできない構成が混在しているのが、この手のソフトの厄介なところです。手を動かす順番としては、まず存在の洗い出し、次に導入経路の判別、そのうえで更新するか待つかを決める、という流れになります。

すぐに更新できない場合の緩和策としては、Webメール画面へのアクセス元をVPNや社内ネットワークに限定する、多要素認証を挟む、といったネットワーク側の絞り込みが基本になります。今回の脆弱性のうち認証不要で成立するものは、いずれも「攻撃者が細工したHTMLメールを送り、利用者がそれを開く」ことが起点です。Webメールは、外部から届いた任意のHTMLを社内の利用者のブラウザで描画する装置だと捉えると、リスクの位置づけがしやすくなります。

そのうえで、こうした「メール経由で届く攻撃」への備えは、技術的対策だけでは閉じません。IPAが公開している以下の資料は、経営層や利用部門への説明材料としても使いやすいので、まずはこちらを参照してください。

地道な話ですが、Webメールは利用者が毎日触る画面です。「見慣れない警告が出たら開かずに情シスへ」という一言が通じる関係を作っておくほうが、個々のCVEを追いかけるより効く場面は多いと感じます。

まとめ

  1. Roundcube 1.6.18 / 1.7.3 へ更新する。11件のセキュリティ修正が入っており、最も深刻なのは markasjunk プラグインの cmd_learn ドライバ経由のRCE（CVE-2026-74997、CVSS 8.8）です。ただし既定では無効な構成なので、まず自社のプラグイン設定を確認してください。
  2. CVE番号は8日遅れて付いた。リリース時点でCVEが無いため、CVEフィード依存の脆弱性管理では空白期間が生まれます。外部公開かつ認証情報を扱うOSSは、ベンダーの告知そのものを購読対象にしておくのが現実的です。
  3. 「導入した覚えがない」経路を疑う。Roundcubeは管理パネルやディストリのパッケージ、レンタルサーバのWebメール機能として動いていることがあります。Debian安定版は本記事執筆時点で未修正、パネル同梱の場合は自力での差し替えは避け、ベンダーの配信を確認してください。

関連記事

出典

タイトルとURLをコピーしました