脆弱性対応ウォッチ重大・クリティカル脆弱性のクラウド別対応まとめ
最新更新履歴CriticalHigh回避策のみパッチありAWSGCPAzureLinux
Critical CVSS 10.0
CVE-2026-62643

Roundcube Webmail の HTML メール CSS 無害化不足(SSRF・内部情報の漏えい)

情報取得日: 2026/07/14/最終確認: 2026/08/10・本ページは公開情報の非公式まとめです

CVE IDCVE-2026-62643
製品Roundcube / Roundcube Webmail 1.6.17 未満 / 1.7.2 未満
CVSS10.0(Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
種別 (CWE)CWE-918(サーバサイドリクエストフォージェリ)
登録/公開日2026/07/14
出典https://nvd.nist.gov/vuln/detail/CVE-2026-62643

概要

Web メールクライアント Roundcube Webmail に、HTML メール中の CSS の無害化が不十分な欠陥がある。 NVD の記述によれば、1.6.17 より前と 1.7.x の 1.7.2 より前で、HTML メール内の CSS のサニタイズが不十分なため、**スタイルシートのリンクが内部ネットワークのホストを指している場合に SSRF や情報漏えいにつながり得る**。NVD の注記では、この問題は CVE-2026-35540 と CVE-2026-48843 の修正が不十分だったために残ったものだとされている。修正版は 1.6.17 と 1.7.2 である。 用語を補足する。SSRF(サーバサイドリクエストフォージェリ)は、攻撃者が用意した URL をサーバ側に取得させることで、外部からは到達できない内部ネットワークへサーバを経由して要求を送らせる攻撃である。ここでは HTML メールの CSS が入口になる。攻撃者はメールを1通送るだけでよい。 CVSS の評価が分かれている点に注意が要る。NVD の Primary(nvd@nist.gov)は 10.0(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N)で Critical、一方 cve@mitre.org の Secondary は 7.2(同 S:C/C:L/I:L/A:N)で High である。差の中心は影響度の見積もり(C と I を High と見るか Low と見るか)にある。当サイトは掲載基準に従い NVD の Primary である 10.0 を採る。 共通しているのは **S:C(スコープ変更)** である。これは、脆弱なコンポーネント(Roundcube)の権限範囲を越えて別のコンポーネント(内部ネットワーク上のサービス)に影響が及ぶことを意味する。Web メールはインターネットからの受信が前提の仕組みなので、**攻撃者は認証情報を持たなくてもメールを送るだけで到達できる**(PR:N・UI:N)。ここが、同じ SSRF でも管理画面に潜むものより深刻である理由である。 実務上のいちばんの懸念は、Web メールサーバがクラウド上にある場合のインスタンスメタデータ(169.254.169.254)への到達である。到達できてしまうと、インスタンスに付与された資格情報が読まれ得る。 2026-08-09 時点で CISA KEV には収載されていない。

クラウド/OS 別の対応状況

各ベンダー公式アドバイザリで確認できた事実に基づき整理しています。確認できていない項目は「情報確認中」と明記し、存在しないパッチ番号・バージョンは記載しません。

AWS / GCP / Azure は同じ対応区分です: パッチあり(アプリ更新)
Linux のみ異なります: 情報確認中
環境対応状況対応方法・備考
AWS (ECS/EC2) パッチあり(アプリ更新)
EC2 / ECS / EKS 上の Roundcube を 1.6.17 または 1.7.2 以上へ更新する。あわせて IMDSv2 を強制する
AWS のマネージド修正は無い。SSRF でメタデータに到達されたときの被害を抑えるため、インスタンスメタデータは IMDSv2 必須(HttpTokens=required)に設定する。
参照リンク
GCP パッチあり(アプリ更新)
GCE / GKE / Cloud Run 上の Roundcube を 1.6.17 または 1.7.2 以上へ更新する
GCP 固有のパッチは無い。メタデータサーバは Metadata-Flavor ヘッダを要求するため単純な SSRF では読めないが、egress の制限は併せて行う。
参照リンク
Azure パッチあり(アプリ更新)
VM / AKS / App Service 上の Roundcube を 1.6.17 または 1.7.2 以上へ更新する
Azure 固有のパッチは無い。IMDS は Metadata:true ヘッダを要求するが、NSG での egress 制限を併用する。
参照リンク
Linux 情報確認中
ディストリのパッケージ(roundcube 等)を使っている場合は各ディストリのセキュリティ更新を適用する。ソースから導入している場合は 1.6.17 / 1.7.2 の配布物へ入れ替える
ディストリ版は修正の取り込みが遅れることがある。稼働中の実バージョンは Roundcube の設定画面またはインストールディレクトリの version ファイルで確認する。
参照リンク

解決の方向性(パッチ/回避策/代替)

**Roundcube Webmail を 1.6.17 または 1.7.2 以上へ更新するのが恒久対応である。** 提供元の告知は roundcube.net の 2026-07-05 付セキュリティ更新である。1.6 系を使っている場合は 1.6.17、1.7 系なら 1.7.2 が対象で、系列をまたぐアップグレードは不要である。 この CVE は **過去2件(CVE-2026-35540 / CVE-2026-48843)の修正が不十分だったために残ったもの**である点を押さえておきたい。「以前に当てたから大丈夫」という判断が通用しない類の脆弱性なので、稼働中の実バージョンを確認すること。 更新までの緩和は **サーバからの外向き通信を絞ること**である。Roundcube が動くホストから内部ネットワークやクラウドのメタデータエンドポイント(169.254.169.254)へ出られないよう、egress のファイアウォール規則で塞ぐ。クラウド上なら、IMDSv2 の強制(AWS)やメタデータサーバへのアクセス制限(GCP/Azure の同等機能)も併せて有効にする。 もう一つの緩和は、**HTML メールの外部リソース読み込みを既定で無効にすること**である。Roundcube には外部画像の読み込みを既定で止める設定があり、リモートコンテンツを取りに行かせない運用にしておくと、この種の入口が狭くなる。ただし本件は CSS の処理経路の問題なので、これだけを恒久対応とはしない。 **事後の確認は外向き通信のログで行う。** Roundcube 稼働ホストからの HTTP 要求のうち、プライベートアドレス帯(10/8・172.16/12・192.168/16)や 169.254.169.254 宛のものが無いかを確認する。プロキシを経由している構成なら、プロキシのアクセスログのほうが確実に残っている。

よくある質問(CVE-2026-62643)

CVE-2026-62643(Roundcube Webmail 1.6.17 未満 / 1.7.2 未満)の影響は?

Critical(CVSS 10.0)に分類されるRoundcube Roundcube Webmail 1.6.17 未満 / 1.7.2 未満の脆弱性です。Web メールクライアント Roundcube Webmail に、HTML メール中の CSS の無害化が不十分な欠陥がある。 NVD の記述によれば、1.6.17 より前と 1.7.x の 1.7.2 より前で、HTML メール内の CSS のサニタイズが不十分なため、**スタイルシートのリンクが内部ネットワークのホストを指している場合に SSRF や情報漏えいにつながり得る**。NVD の注記では、この問題は CVE-2026-35540 と CVE-2026-48843 の修正が不十分だったために残ったものだとされている。修正版は 1.6.17 と 1.7.2 である。 用語を補足する。SSRF(サーバサイドリクエストフォージェリ)は、攻撃者が用意した URL をサーバ側に取得させることで、外部からは到達できない内部ネットワークへサーバを経由して要求を送らせる攻撃である。ここでは HTML メールの CSS が入口になる。攻撃者はメールを1通送るだけでよい。 CVSS の評価が分かれている点に注意が要る。NVD の Primary(nvd@nist.gov)は 10.0(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N)で Critical、一方 cve@mitre.org の Secondary は 7.2(同 S:C/C:L/I:L/A:N)で High である。差の中心は影響度の見積もり(C と I を High と見るか Low と見るか)にある。当サイトは掲載基準に従い NVD の Primary である 10.0 を採る。 共通しているのは **S:C(スコープ変更)** である。これは、脆弱なコンポーネント(Roundcube)の権限範囲を越えて別のコンポーネント(内部ネットワーク上のサービス)に影響が及ぶことを意味する。Web メールはインターネットからの受信が前提の仕組みなので、**攻撃者は認証情報を持たなくてもメールを送るだけで到達できる**(PR:N・UI:N)。ここが、同じ SSRF でも管理画面に潜むものより深刻である理由である。 実務上のいちばんの懸念は、Web メールサーバがクラウド上にある場合のインスタンスメタデータ(169.254.169.254)への到達である。到達できてしまうと、インスタンスに付与された資格情報が読まれ得る。 2026-08-09 時点で CISA KEV には収載されていない。

CVE-2026-62643 の対応方法・回避策は?

**Roundcube Webmail を 1.6.17 または 1.7.2 以上へ更新するのが恒久対応である。** 提供元の告知は roundcube.net の 2026-07-05 付セキュリティ更新である。1.6 系を使っている場合は 1.6.17、1.7 系なら 1.7.2 が対象で、系列をまたぐアップグレードは不要である。 この CVE は **過去2件(CVE-2026-35540 / CVE-2026-48843)の修正が不十分だったために残ったもの**である点を押さえておきたい。「以前に当てたから大丈夫」という判断が通用しない類の脆弱性なので、稼働中の実バージョンを確認すること。 更新までの緩和は **サーバからの外向き通信を絞ること**である。Roundcube が動くホストから内部ネットワークやクラウドのメタデータエンドポイント(169.254.169.254)へ出られないよう、egress のファイアウォール規則で塞ぐ。クラウド上なら、IMDSv2 の強制(AWS)やメタデータサーバへのアクセス制限(GCP/Azure の同等機能)も併せて有効にする。 もう一つの緩和は、**HTML メールの外部リソース読み込みを既定で無効にすること**である。Roundcube には外部画像の読み込みを既定で止める設定があり、リモートコンテンツを取りに行かせない運用にしておくと、この種の入口が狭くなる。ただし本件は CSS の処理経路の問題なので、これだけを恒久対応とはしない。 **事後の確認は外向き通信のログで行う。** Roundcube 稼働ホストからの HTTP 要求のうち、プライベートアドレス帯(10/8・172.16/12・192.168/16)や 169.254.169.254 宛のものが無いかを確認する。プロキシを経由している構成なら、プロキシのアクセスログのほうが確実に残っている。

自分の環境が CVE-2026-62643 の影響を受けるか確認するには?

Roundcube Roundcube Webmail 1.6.17 未満 / 1.7.2 未満 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報(https://nvd.nist.gov/vuln/detail/CVE-2026-62643)で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド/OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。

参考情報(出典)

本ページの記載は下記の一次情報に基づく非公式まとめです。数値・対応状況は各出典元で最終確認してください(最終確認: 2026/08/10)。

NVD(CVE 基本情報・CVSS スコアの出典)
免責: 本ページは CISA KEV・NVD・各ベンダー公式アドバイザリ等の公開情報をもとにした非公式まとめです。修正バージョンや対応可否は変更される場合があります。実際の対応は必ず 出典元および各ベンダー公式情報・自環境で確認してください。

« 一覧に戻る