---
title: "Roundcube 脆弱性：1.7.5・1.6.20の20件の中身と版確認・更新手順"
url: "https://www.issoh.co.jp/tech/details/18807/"
published: 2026-10-23
updated: 2026-10-23
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# Roundcube 脆弱性：1.7.5・1.6.20の20件の中身と版確認・更新手順

オープンソースのWebメールRoundcubeは2026年10月19日、1.7系の1.7.5と長期サポート版1.6系の1.6.20を公開し、20件の脆弱性を修正しました。10月20〜22日にはNVDにCVE番号が付き、CVSSは最大8.5です。この記事では、20件の内訳と攻撃に要る条件、iniset.phpを使った版の判定、プラグインと設定から該当範囲を絞るコマンド、installto.shとDockerでの更新手順、すぐ上げられない場合の暫定策までを順に整理しました。内容は2026年10月23日時点の公開情報にもとづきます。

## まとめ：1.7.5・1.6.20未満は全て更新対象、1.5系以前は系列ごと移行

影響を受けるのは1.7.5より前の1.7系と、1.6.20より前の1.6系のすべてです。修正は両系列に同じ20件が入っており、どちらの系列でも最新版へ上げれば済みます。1.5系は1.7.0の公開時にサポートを終えており、修正版は出ません。

10月23日時点で悪用の報告はありません。それでもRoundcubeは過去に11件がCISAの悪用済み脆弱性カタログに載った製品で、修正の差分から攻撃手法を組み立てられる前に更新を終えるのが筋です。社外に公開しているWebメールは今週中、社内限定のものは次の保守枠までを期限にします。自社で抱えるWebメールや周辺システムの版と露出をまとめて棚卸ししたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で一覧化すると漏れが減ります。

## 1.7.5・1.6.20で直った20件のCVEとCVSS、攻撃に要る条件の整理

公式の[セキュリティ更新の告知](https://roundcube.net/news/2026/10/19/security-updates-1.6.20-and-1.7.5)と[1.7.5のリリースノート](https://github.com/roundcube/roundcubemail/releases/tag/1.7.5)には、修正内容が20行の箇条書きで並んでいます。CVE番号は告知に無く、あとからNVDに登録されました。

### CVSS7以上の6件：IMAP注入・ImageMagick・セッションの穴

NVDの値はCVE番号を割り当てたMITREによる評価で、NVD自身の分析は10月23日時点で終わっていません。7点以上は次の6件です。

| CVE                                                                 | 内容                         | CVSS | 攻撃者の条件          |
| ------------------------------------------------------------------- | -------------------------- | ---- | --------------- |
| [CVE-2026-114716](https://nvd.nist.gov/vuln/detail/CVE-2026-114716) | インライン画像のメディアタイプ経由のヘッダ注入    | 8.5  | ログイン済み          |
| [CVE-2026-114727](https://nvd.nist.gov/vuln/detail/CVE-2026-114727) | SVG・EPSをImageMagickへ渡していた  | 8.3  | ログイン済み          |
| [CVE-2026-114724](https://nvd.nist.gov/vuln/detail/CVE-2026-114724) | セッション復元時のPHPオブジェクト注入       | 7.4  | セッションデータに干渉できる者 |
| [CVE-2026-114730](https://nvd.nist.gov/vuln/detail/CVE-2026-114730) | NAT64アドレスでSSRFフィルタを迂回      | 7.2  | 認証不要            |
| [CVE-2026-113386](https://nvd.nist.gov/vuln/detail/CVE-2026-113386) | \_uidパラメータのCRLFでIMAPコマンド注入 | 7.1  | ログイン済み          |
| CVE-2026-114720                                                     | \_flagのCRLFでIMAPコマンド注入     | 7.1  | ログイン済み          |

上位の多くはログインした利用者が起点です。社員が使う社内Webメールでも、乗っ取られた1アカウントからIMAPサーバーへ任意のコマンドを送れる点は軽く見られません。CVE-2026-114727は連絡先の顔写真のアップロードと変換でSVGとEPSを受け付けていた問題で、どちらも外部の資源を参照できる形式です。セッションの件は、セッションの中身を書き換えられる立場が前提のため攻撃元がローカル扱い（AV:L）になっています。PHPのデシリアライズがRCEにつながる仕組みは[安全でないデシリアライゼーションの解説](https://www.issoh.co.jp/tech/details/16369/)で扱っています。このほかReferences・In-Reply-To・Message-ID・Fromの各パラメータ経由のヘッダ注入（CVE-2026-114725・5.0）も、ログイン済みの利用者が起点です。

### 受信メールの開封・転送時に成立する外部読み込み・CSSなどの7件

認証の要らない経路は、攻撃者が送ったメールを利用者が受け取って開く、転送する場面に集中しています。

- SVGのSMILアニメーションのby属性と、CSSエスケープを使ったFuncIRI属性で外部画像のブロックをすり抜ける（各5.3）。開封とIPアドレスが送信者に知られる
- @layerなどのat-ruleを使い、本文用のCSSを画面全体に効かせる（6.5）。偽のボタンや表示で利用者を誘導できる
- From表示名にCRLFを埋めたメールを「再送（Bounce）」すると、送出メールにヘッダを足される（5.8）
- 件名にCRLFを含むメールを添付として転送すると、MIMEパートのヘッダを足される（4.0）
- スタイルシートを中継するCSSプロキシにサイズ上限が無く、メモリを使い切らされる（5.3）
- サムネイル生成でGDへ切り替わったときにメモリ確認がWindowsでしか効かない（3.7）

外部読み込みの回避は9月の1.7.4でも「CSSエスケープ」の同種の穴が直っており、今回の告知にも「(again)」と書かれています。点数は中位ですが、Webメールでは標的型攻撃の下調べ（開封確認）に使われる種類の穴です。

### 使用中のプラグインと設定条件から該当する6件を見分ける確認基準

残る6件は、特定のプラグインや構成を使っている場合にだけ効きます。表のpassword・markasjunk・squirrelmail\_usercopyはプラグイン名で、Modoboa・DirectAdmin等はpasswordプラグインのドライバを指します。squirrelmail\_usercopyの該当条件は、ファイル型を使っていることです。手元の設定と照らせば対象外を外せます。

| 該当する構成                     | 内容                        | CVSS |
| -------------------------- | ------------------------- | ---- |
| passwordでModoboaドライバ使用     | 別アカウントのパスワードを変更できた        | 6.8  |
| 単一Roundcubeで複数IMAPホストを扱う   | エイリアスでのログインが別ホストの利用者に結び付く | 6.8  |
| squirrelmail\_usercopy     | ログイン名のスラッシュで指定外のファイルを読む   | 5.3  |
| password（DirectAdmin等）     | ドライバのエラー文をそのまま表示するXSS     | 4.7  |
| markasjunkプラグイン            | 迷惑メール登録でCSRF対策をすり抜ける      | 3.7  |
| disabled\_actionsで機能を止めている | 旧名の別名を使うと止めた機能に届く         | 3.1  |

disabled\_actionsの件は、設定で塞いだつもりの機能が開いていたという種類です。1.7.5の[defaults.inc.php](https://github.com/roundcube/roundcubemail/blob/1.7.5/config/defaults.inc.php)では初期値が空の配列なので、明示的に機能を止めているサイトだけが対象になります。

### 10月23日時点の悪用状況：KEV・JPCERT/CCに記載なし

[CISAのKEVカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)（10月21日版）には、Roundcubeの項目が11件あります。直近の追加は2026年2月20日のCVE-2025-68461（XSS）と[CVE-2025-49113](https://nvd.nist.gov/vuln/detail/CVE-2025-49113)（認証後のRCE）で、今回の20件は入っていません。JPCERT/CCの注意喚起一覧にもRoundcubeの項目はありませんでした。

KEVの11件のうち7件はXSSで、メールを開かせるだけで成立する種類が繰り返し実際の攻撃に使われてきました。今回の受信メール経由の7件は点数が5〜6点台でも、過去の悪用の型に近いと見ておきます。点数の読み方は[CVSSv3の計算式とスコアの目安](https://www.issoh.co.jp/tech/details/5094/)を参照してください。

## 影響版の確認：iniset.phpの版定数とプラグイン・設定を点検するコマンド

判定に要るのは、導入中の版と、上の表の構成に当てはまるかの2点です。

### 配布版のiniset.phpにある版定数と系列別の修正版を比べる方法

配布パッケージでは、版が program/include/iniset.php の定数RCMAIL\_VERSIONに書かれています。1.7.5と1.6.20の配布tarballの中身で、それぞれ「1.7.5」「1.6.20」と入っていることを確かめました。

```
# インストール先で実行（パスは環境に読み替える）
cd /var/www/roundcube
grep -o "RCMAIL_VERSION', '[^']*'" program/include/iniset.php
# 出力例: RCMAIL_VERSION', '1.7.4'
```

複数のサーバーを判定するなら、次のPythonスクリプトで系列ごとの修正版と比べます。標準ライブラリだけで動きます。

```
import re
import sys
from pathlib import Path

# 2026年10月19日時点の修正版（系列ごと）
FIXED = {"1.7": (1, 7, 5), "1.6": (1, 6, 20)}

root = Path(sys.argv[1] if len(sys.argv) > 1 else "/var/www/roundcube")
src = (root / "program/include/iniset.php").read_text(encoding="utf-8")
ver = re.search(r"define\('RCMAIL_VERSION', '([^']+)'\)", src).group(1)

m = re.fullmatch(r"(\d+)\.(\d+)\.(\d+)", ver)
branch = f"{m.group(1)}.{m.group(2)}" if m else None
if branch not in FIXED:
    print(f"{ver}: サポート外の系列。1.6.20か1.7.5へ移行")
    sys.exit(2)

cur = tuple(int(x) for x in m.groups())
fix = FIXED[branch]
if cur >= fix:
    print(f"{ver}: 修正済み（{'.'.join(map(str, fix))} 以上）")
else:
    print(f"{ver}: 要更新（{'.'.join(map(str, fix))} 未満）")
    sys.exit(1)
```

2026年10月23日に模擬ファイルで実行したところ、1.7.4と1.6.19は「要更新」で終了コード1、1.7.5・1.7.10・1.6.20は「修正済み」で0、1.5.15とリリース候補の1.7-rc6は「サポート外」で2を返しました。Gitから取得した作業コピーは版が「1.7-git」と書かれており、このスクリプトではサポート外と出ます。その場合は git describe –tags で取得元のタグを確かめてください。

### 有効プラグイン・セッション保存先・画像変換の設定による該当CVEの絞り込み

次に、表の構成に当てはまるかを設定ファイルから拾います。項目名は1.7.5の設定の既定値と同梱プラグインの一覧で確認したものです。

```
# 有効なプラグイン（password・markasjunk・squirrelmail_usercopy の有無）
grep -n -A12 "\$config\['plugins'\]" config/config.inc.php

# セッションの保存先・ImageMagickのパス・止めている機能
grep -n -E "session_storage|im_convert_path|disabled_actions" config/config.inc.php

# passwordプラグインのドライバ（modoboa・directadmin なら表の該当行を確認）
grep -n "password_driver" plugins/password/config.inc.php 2>/dev/null

# PHPの画像拡張（imagick があれば ImageMagick を経由しうる）
php -m | grep -i -E "^(imagick|gd)$"
```

session\_storageは既定が「db」です。redisやmemcacheにしていて、その保存先を他のアプリと共用しているなら、CVE-2026-114724の前提条件に近づくので優先度を上げます。im\_convert\_pathが未設定でもImagick拡張があれば画像の変換に使われるため、最後の行の結果も合わせて見てください。

## 更新手順：installto.shで1.7.5へ上げる流れとDocker版の差し替え

手順はリポジトリの[UPGRADING.md](https://github.com/roundcube/roundcubemail/blob/1.7.5/docs/UPGRADING.md)に沿います。新しい版を一時ディレクトリに展開し、そこから既存のインストール先へ上書きする方式です。

### 署名の確認からbin/installto.shの実行までの5工程

1.7系の例です。1.6系は版番号を1.6.20に読み替えます。

```
# 1. インストール先とDBをバックアップ（MySQLの例）
cp -a /var/www/roundcube /var/backups/roundcube-$(date +%Y%m%d)
mysqldump roundcubemail > /var/backups/roundcubemail-$(date +%Y%m%d).sql

# 2. 一時ディレクトリへ取得
cd /tmp
wget https://github.com/roundcube/roundcubemail/releases/download/1.7.5/roundcubemail-1.7.5-complete.tar.gz
wget https://github.com/roundcube/roundcubemail/releases/download/1.7.5/roundcubemail-1.7.5-complete.tar.gz.asc

# 3. 署名とハッシュを確認（公開鍵は事前に取り込んでおく）
gpg --verify roundcubemail-1.7.5-complete.tar.gz.asc roundcubemail-1.7.5-complete.tar.gz
sha256sum roundcubemail-1.7.5-complete.tar.gz

# 4. 展開して、展開先から既存のインストール先へ更新
tar xzf roundcubemail-1.7.5-complete.tar.gz --no-same-owner
cd roundcubemail-1.7.5
./bin/installto.sh /var/www/roundcube

# 5. 版を確かめる
grep -o "RCMAIL_VERSION', '[^']*'" /var/www/roundcube/program/include/iniset.php
```

installto.shは新しいファイルを写したうえで、設定とDBスキーマの更新も確かめます。sha256sumの出力を照合する相手は、[ダウンロードページ](https://roundcube.net/download/)に載っている値（1.7.5の完全版は93a66c94で始まる）です。展開後のファイルの所有者がWebサーバーの実行ユーザーとずれると表示が崩れるため、UPGRADING.mdも –no-same-owner を勧めています。

### 1.6系から1.7.5へ上げる場合のpublic\_htmlとPHP 8.1の条件

1.6系のまま1.6.20へ上げるのが最短です。1.7系へ移る場合は、[1.7.0の告知](https://roundcube.net/news/2026/05/10/roundcube-1.7.0-released)にある互換性のない変更が効いてきます。PHP 8.1未満は動かず、Webサーバーの公開ディレクトリを public\_html に向け直す必要があり、MS SQL ServerとOracleのDBは使えません。

今回の修正のためだけに系列をまたぐのは避け、まず1.6.20で穴をふさぎ、1.7系への移行は別の作業として試験を通します。1.6系はLTSとして重要なセキュリティ修正だけを受け取る段階で、終了日は公表されていません。

### Docker Hubの1.7.5-apacheなど固定タグでpullし直す手順

[公式のDockerイメージ](https://hub.docker.com/r/roundcube/roundcubemail)には、10月22日に1.7.5-apache・1.7.5-fpm・1.7.5-fpm-alpineと、それぞれのnonroot版のタグが出ています。latestのような動くタグを使っていると、どの版で動いているかを後から説明できません。固定タグに書き換えてから入れ替えます。

```
# compose.yaml の image を固定タグへ書き換える
#   image: roundcube/roundcubemail:1.7.5-apache

docker compose pull roundcubemail
docker compose up -d roundcubemail
docker compose images roundcubemail
```

サービス名のroundcubemailは手元のcompose.yamlに合わせて読み替えます。OSのパッケージやホスティングの管理画面に同梱されたRoundcubeは、提供元が修正版を配るまで版が上がりません。提供元の告知で1.7.5か1.6.20相当の修正が入ったかを確かめ、入っていなければ次章の暫定策で待ちます。

## すぐ更新できないときの暫定策：プラグイン停止と外向き通信で狭める範囲

暫定策で全件はふさげません。受信メール経由の7件はRoundcube本体の処理なので、更新以外に止める手段がないと考えてください。

### パスワード変更・迷惑メール登録・設定移行のプラグインを一時停止する判断

プラグイン起因の4件は、config.inc.phpの$config\[‘plugins’\]から該当のプラグイン名を外せば止まります。外している間、利用者はWebメールからパスワードを変えられず、迷惑メール登録のボタンも消えます。パスワード変更は別の窓口で受け付けると告知したうえで外すのが現実的です。

squirrelmail\_usercopyはSquirrelMailからの移行時に設定を写すためのもので、移行が終わったサイトなら更新後も外したままで構いません。使っていないプラグインを残さないこと自体が、攻撃面を減らす手当てになります。

### ImageMagickの形式制限とNAT64経由のSSRFへの出口制御

CVE-2026-114727には、ImageMagick側の設定でSVGやEPSを読ませない手当てが効きます。[ImageMagickのセキュリティ方針の解説](https://imagemagick.org/security-policy/)に示されているWeb向けの例は、全モジュールを止めてから安全な形式だけを許す書き方です。policy.xmlのpolicymapの中に次の2行を置くと、GIF・JPEG・PNG・WEBP以外を扱えなくなります。

```
<policy domain="module" rights="none" pattern="*"/>
<policy domain="module" rights="read | write" pattern="{GIF,JPEG,PNG,WEBP}"/>
```

同じサーバーで他のアプリがPDFなどをImageMagickで扱っている場合は、そのアプリが壊れるので先に影響を確かめます。SSRFの件は、64:ff9b::7f00:1のようなNAT64のアドレスでループバックやクラウドのメタデータに届くというものです。サーバーからの外向き通信を、IMAPやSMTPなど必要な宛先だけに出口で絞れば被害の範囲を抑えられます。SSRFとメタデータの関係は[SSRFの仕組みと防御実装](https://www.issoh.co.jp/tech/details/16362/)で詳しく扱っています。

前段の[WAF](https://www.issoh.co.jp/tech/details/13275/)で止める案は、効き目が限られます。上位の穴の多くはログイン後のリクエストかメール本文の中身が経路で、WAFが見るリクエストの形に現れにくいからです。WAFは更新までの補助と割り切ります。

## 優先順位の判断：毎月の修正に追いつく運用か、運用を外へ出すかの基準

Roundcubeのセキュリティ更新は、1.7.0が出た5月以降、5月24日・7月5日・8月9日・9月6日・10月19日と毎月のように続いています。単発の対応で終わらない前提で判断します。

### 1.5系以前と社外公開のWebメールは今週中、社内限定は次の保守枠

最優先は1.5系以前で動いているサーバーです。[リリース管理の方針](https://github.com/roundcube/roundcubemail/blob/1.7.5/docs/RELEASE%5FMANAGEMENT.md)では修正を出すのは最新の系列と1つ前の系列までで、1.5系には今回の20件もその前の修正も入りません。今週中に1.6.20へ上げます。

次が、インターネットから誰でもログイン画面に届くWebメールです。受信メール経由の7件は外部の誰でも送り込めるので、これも今週中とします。VPNの内側だけで使う社内向けは、次の定期保守での更新で足ります。ただし「社内限定だから」を理由に更新を見送り続けるのは誤りです。同じ月に公表された[Exchange OWAの悪用済みXSS](https://www.issoh.co.jp/tech/details/12219/)のように、Webメールは社内向けでも最初の侵入口として狙われます。

### 月1回の更新・検証に人を割けない組織が運用ごと外へ出す判断基準

毎月の更新に、検証・バックアップ・入れ替え・版の確認で半日ずつ割けるかを目安にします。割けるなら自社運用を続け、[公式ニュースのAtomフィード](https://roundcube.net/feeds/atom.xml)を監視して公開から1週間以内に上げる手順を決めておきます。

割けない組織が自前でRoundcubeを抱え続けるのは過剰な負担です。ホスティング事業者のWebメールやクラウドのメールサービスへ移すか、保守を外部へ委託します。同じ月に起きた別のPHP製ソフトの対応例は[Drupalの脆弱性SA-CORE-2026-014の版確認と回避](https://www.issoh.co.jp/tech/details/18803/)に整理した内容を参照してください。外部委託の範囲や費用から考えたい場合は、[脆弱性診断の進め方と外注時の判断基準](https://www.issoh.co.jp/column/details/13101/)が出発点になります。

## Roundcube 1.7.5・1.6.20の更新でよくある質問と回答

今回の更新で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

### 1.6系のまま使い続けても問題ありませんか？

1.6.20へ上げれば、今回の20件は1.7.5と同じく修正されます。1.6系は1.7.0の公開以降、重要なセキュリティ修正だけを受け取るLTSの扱いで、新機能や通常のバグ修正は入りません。終了日は公表されていないため、当面は1.6.20で運用し、PHP 8.1以上とpublic\_htmlの構成を整えてから1.7系へ移る計画を並行して立てるのが無難です。

### CVE番号とCVSSはどこで確認できますか？

Roundcubeの告知とリリースノートにはCVE番号が書かれていません。2026年10月20〜22日にNVDへ登録されたCVE-2026-113386とCVE-2026-114714〜114732の計20件が今回の修正に対応します。CVSSは番号を割り当てたMITREの値で、NVD自身の分析は10月23日時点で終わっていません。NVDの評価が付くと点数が変わる場合があります。

### 実際の攻撃や悪用は確認されていますか？

2026年10月23日時点で、今回の20件はCISAのKEVカタログにもJPCERT/CCの注意喚起一覧にも載っていません。ただしRoundcubeはKEVに11件が載る、攻撃者に狙われてきた製品です。2025年のCVE-2025-49113は公開後に悪用が確認され、2026年2月にKEVへ追加されました。悪用報告を待ってから動く理由はありません。

### installto.shで更新すると自分の設定ファイルは上書きされますか？

UPGRADING.mdによれば、installto.shは新しいファイルをインストール先へ写したうえで、設定とDBスキーマの更新を確かめます。手作業で更新する場合の説明では、置き換える対象はconfig/defaults.inc.phpとconfig/mimetypes.phpで、自分で書いたconfig.inc.phpは含まれていません。とはいえ公式も作業前のバックアップを求めているので、インストール先とDBの両方を控えてから実行してください。

### 次のセキュリティ更新はいつ出ますか？

Roundcubeは定期的な公開日を決めていません。2026年は5月から10月までほぼ毎月セキュリティ更新が出ており、[セキュリティポリシー](https://github.com/roundcube/roundcubemail/security/policy)には報告から数日で修正版を用意すると書かれています。公式ニュースのAtomフィードかGitHubのリリース通知を購読しておき、出たら1週間以内に上げる体制を前提にします。

## 関連記事

- [脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説](https://www.issoh.co.jp/tech/details/13546/)：公表から修正までの流れの基礎です。
- [CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化](https://www.issoh.co.jp/tech/details/5092/)：CVE番号がNVDに載るまでの関係を整理しています。
- [安全でないデシリアライゼーションとは？RCEに至る仕組みと言語別の防御実装を解説](https://www.issoh.co.jp/tech/details/16369/)：セッション復元の穴の背景にある攻撃手法です。
- [XSSとCSRFの違いとは？仕組み・被害・対策を実装レベルで徹底比較](https://www.issoh.co.jp/tech/details/4109/)：passwordプラグインのXSSとmarkasjunkのCSRFの理解に役立ちます。
- [Nextcloudとは？オープンソースで自社構築するファイル共有基盤の機能と実装・採用判断](https://www.issoh.co.jp/tech/details/15313/)：Roundcubeの脆弱性報告の窓口も担うNextcloudを自社構築する判断です。

---

出典: [Roundcube 脆弱性：1.7.5・1.6.20の20件の中身と版確認・更新手順](<https://www.issoh.co.jp/tech/details/18807/>)（株式会社一創）