2025年のIIJ、2026年のTOKAIコミュニケーションズやKDDI。メール基盤が繰り返し破られている。RoundcubeのCISA KEV入り2件は「メールを開くだけ」でサーバ奪取まで至る連鎖を成立させ、その一部はベンダーすら知らないゼロデイでパッチが存在しなかった。そして海外拠点には、誰も管理していないwebメールが残り続ける。攻撃手法、影響範囲、確認方法、そしてなぜ「見えていないものは守れない」のかを整理する。
最近、海外子会社が攻撃されるインシデントを目にする機会が増えた。
日本の親会社が「海外グループ会社のサーバーに不正アクセスがあった」と公表する。だが個別の事案について、何が起きたのかは分からないことが多い。どのシステムが、どう破られたのか。公表されないまま終わることも珍しくない。
だから、これは特定の事案の話ではない。一般論として、こういう構図なら何が起きうるか、という話だ。
そう考えたとき、候補の一つとして浮かぶものがある。
webメールだ。
理由は二つある。
一つは、webメールのインシデントが、実際に多いこと。国内でも海外でも、この1〜2年、メール基盤が繰り返し破られている。
もう一つは、グローバル企業を見渡すと、今もwebメールが使われている事例が見受けられること。特に海外拠点で。本社の統合されたメール基盤ではなく、現地が独自に立てた、小さなwebメールが。
この二つが重なる場所に、何が起きるのか。
順に見ていきたい。
2025年4月、インターネットイニシアティブ（IIJ）が提供する「IIJ セキュアMXサービス」への不正アクセスが公表された。
最大400万人分に影響する可能性があり、最終的にメールアドレス31万1,288件・586契約の漏えいが確定。総務省は報告徴収を経て行政指導を行った。
原因は、クオリティア社のwebメールシステム「Active! mail」の脆弱性 CVE-2025-42599（CVSS 9.8）。スタックベースのバッファオーバーフローによる遠隔コード実行だ。
問題は、これが完全なゼロデイだったことにある。
攻撃が行われた時点で、開発元のクオリティアすら、この穴の存在を知らなかった。パッチは存在しなかった。どれだけ真面目にパッチ管理をしていても、防げなかった。
Active! mailは、日本のwebメールの標準と言っていい。
累計2,250法人、1,300万アカウント。官公庁、一般企業、国公立大学。
脆弱性が公表された2025年4月18日前後、レンタルサーバのカゴヤ・ジャパンは攻撃を確認してサービスを一時停止し、KDDIウェブコミュニケーションズも「安全な利用が保証できない」としてサーバを止めた。
そして、これは過去の話ではない。
メール基盤が、狙われ続けている。
海外に目を向けると、攻撃の形がもっと鮮明に見える。
2026年2月20日、米CISAがRoundcube Webmailの脆弱性2件を「悪用が確認された脆弱性（KEV）」カタログに追加した。
この2件は、組み合わせると1本の連鎖になる。
第1段：メールを開く
CVE-2025-68461（CVSS 7.2）は、SVG画像の中の <animate> タグを使ったクロスサイトスクリプティング（XSS）だ。
SVGは画像フォーマットだが、中身はHTMLに似たテキストで、動作を記述できる。
細工したSVGを含むメールを送り、受信者がwebメールの画面でそれを開く、あるいはプレビューするだけで、攻撃者のコードがブラウザ上で動く。
リンクのクリックも、添付ファイルを開く操作も要らない。
表示しただけだ。
第2段：セッションを奪う
ブラウザ上で攻撃者のコードが動けば、その利用者として許されている操作を実行できる。
他のメールを読む。本人になりすまして送る。認証済みのセッションを利用する。
第3段：サーバごと乗っ取る
そして、CVE-2025-49113（CVSS 9.9）。
PHPのオブジェクトを復元する処理の不備により、サーバ上で任意のコードが実行できる。ログイン済みであることが条件だが、第1段で奪ったセッションがそれを満たす。
ここで、被害の性質が変わる。
第2段までは「一人のメールボックス」の話だった。
だがサーバを取られれば、そのwebメールを使っている全員のメールボックスが攻撃者の手に入る可能性がある。
さらに、どこまで被害が広がるかは、そのサーバに何が同居しているかで決まる。
小さな拠点では、Webサイト、メール、webメール、FTPが同じサーバや同じホスティング環境に載っていることがある。
FTPで受け渡していた図面や見積書が、同じディスクに残っている。webメールを取られたつもりが、設計データまで一緒に持っていかれる。
同居させるなら、少なくとも権限を分けなければならない。
webメールのプロセスがFTPの領域を読めてはいけない。データベースの認証情報を、必要のないプロセスが持っていてはいけない。
一つ破られたとき、どこまで届くのか。
それを事前に制限しておくのが、権限の隔離だ。
細工したメールを送る → 相手が開く → セッションが渡る → サーバごと奪われる → 同居しているシステムやデータにも届く。
被害者がしたことは、メールを開いただけだ。
なぜ、そんな穴が残っていたのか
CVE-2025-49113が影響するのは、Roundcube 1.1.0から1.6.10。
コードに埋まっていた期間は10年以上。誰も気づかなかった。
そして皮肉なことに、その穴が塞がれた瞬間に、攻撃が始まった。
修正パッチは、穴の場所を教える地図でもある
オープンソースのソフトウェアでは、修正内容が公開される。
「このファイルのここを、こう直しました」という差分を、誰でも読める。
攻撃者もそれを読む。
どこが直されたかは、どこが壊れていたかと、ほぼ同じ意味だからだ。
修正前と修正後を見比べれば、問題の場所を逆算できる。
2025年6月1日に修正版が出た。攻撃者は差分を読み、2日後には動く攻撃コードを完成させていた。
つまり、パッチが公開された瞬間から、まだ更新していない組織だけが狙われる時間が始まる。
「様子を見てから上げよう」
その様子見期間が、いちばん危険な期間になる。
2026年に入っても、続いている
href 属性経由のXSS。実証コードも公開されているそして4月には、Zimbra Collaboration SuiteのXSS脆弱性もKEVに追加されている。
「メールが読まれた」で済む話ではない。
製造業なら、図面が添付で飛び交う。見積、仕様書、契約書、価格表、取引先との交渉履歴。
ファイルサーバより濃い情報が、何年分も溜まっている。
そして、パスワードを忘れたときのリセットリンクは、どこに届くか。
メールだ。
メールボックスを取られることは、そのアドレスで登録した他のサービスの鍵を渡すことに等しい。
クラウド、SaaS、社内システム。メールを起点に、別のシステムへ移られる。
さらに、本物のメールボックスから、本物のスレッドの続きとして、本物の署名で届く偽の請求書。
ビジネスメール詐欺（BEC）は、こうして自社が踏み台となり、取引先が損害を受ける。
そして最大の問題は、何を読まれたのか分からないことだ。
攻撃者は、正規のセッションで、正規のメールを、正規の手順で読む。
ログに残るのは、「本人がログインして、メールを見た」という記録だけかもしれない。異常に見えない。
だから侵入が分かっても、どのメールが読まれたのかを再構成できない。
インシデントの公表で「調査中」が何か月も続くことがある。その一部は、これが理由だ。
隠しているのではなく、本当に分からない。
技術の問題だけではない。
海外拠点のwebメールを調べると、ガバナンスの状態が一目で分かるような光景に出会うことがある。
ドメインの登録者が、すでに退職した現地社員の個人名のまま。
レンタルサーバの支払いは、誰かの個人カード。
管理画面のパスワードを知っていた人は、もう社内にいない。
最初から正式なシステムとして導入されたわけではない。
海外に営業所を開く。とりあえずドメインを取り、現地のホスティングを借り、webメールを使い始める。
「事業が大きくなったら、本社の基盤へ統合する」
しかし、その日は来ない。
事業が大きくなるほど、移行のコストも上がるからだ。
駐在員は交代する。次の担当者は「ここではこうやっている」と引き継ぐ。
"暫定"だった記憶だけが消え、仕組みだけが残る。
そして5年後。
始めたときは空だったメールボックスに、5年分の契約書、見積書、図面、顧客との交渉履歴が溜まっている。
本社ITが導入を断ったのではない。
誰も本社ITに頼まなかった。
頼まれていないなら、判断の記録も残らない。
資産台帳にも、脆弱性管理にも載らない。
知られていないものは、更新も監視もされない。
最初にやることは、難しくない。
webmail.、mail.、owa. などのホストが公開されていないか特に自動転送は重要だ。
攻撃者はメールボックスを取ると、自分が追い出された後も読み続けられるよう、転送ルールを追加することがある。
パスワードを変更しても、転送ルールが残っていれば、その日から漏れ続ける。
調べてみると、意外なほど簡単に「誰も管理していなかったwebメール」が見つかることがある。
更新は当然必要だ。
パッチが公開されたら、様子を見るのではなく、影響を確認して速やかに適用する。
多要素認証も必要だ。セッションを直接奪う攻撃には万能ではないが、パスワードだけが漏れたケースには効く。
ただし、IIJやTOKAIコミュニケーションズの事例が示したように、ゼロデイはパッチでは防げない。
だから重要なのは、攻撃対象と、侵害された後の到達範囲を減らすことだ。
webメールを、世界中から直接アクセスできる状態にしておく必要があるのか。
VPNやゼロトラスト経由にできないか。接続元を地域やIPで制限できないか。
同じサーバにWeb、メール、FTPを載せる必要があるのか。分離できないなら、少なくとも権限と認証情報を分けられないか。
脆弱性があっても、攻撃者から見えず、破られた後も横に進めなければ、被害は小さくできる。
そして、侵害を完全には防げない前提で、ログを残す。
webメール、IMAP、認証基盤、前段のプロキシ。誰が、いつ、どこから接続し、何を取得したのか。
平時には誰も見ないログでも、有事にはそれしか残っていない。
何が読まれたのか説明できる組織と、何も説明できない組織の差は、侵入後ではなく、侵入前に決まっている。
パッチ管理は重要だ。
しかし、ここまで挙げてきた対策——更新も、公開範囲の制限も、権限の分離も、ログの保全も、すべて「その存在を知っている」ことが前提になっている。
知らないシステムには、パッチも当たらない。公開範囲も見直されない。権限も分離されない。ログも取られない。
だから、本当に問われているのは「何を更新するか」ではない。
組織は、自分たちが守るべき資産を、本当に把握しているのか。
Aikido Securityが重視しているのも、個々の脆弱性を見つけることだけではない。
コードと依存関係、クラウド、公開されているアプリケーション——何が存在し、どこが外部から到達可能で、そこに既知の弱点があるのかを、一つの視界にまとめることだ。
もちろん、すべてをツールだけで可視化できるわけではない。
海外拠点が個人のカードで借りたレンタルサーバまでは、どんな製品も自動では見つけてくれない。それを見つけ、正式な管理対象として台帳に載せるのは、人と組織の仕事だ。
だが、管理対象として載れば、その後の脆弱性把握や継続的な確認は仕組み化できる。
存在を知らないシステムは、更新も監視もできない。
見えていないものは、守れない。
Aikido Community Japan
公開日: 2026/7/16
最終更新: 2026/7/16
セキュリティの最新情報をお届けします。