Active! mailのゼロデイ脆弱性（CVE-2025-42599）を悪用したサイバー攻撃とは
Active! mail（クオリティア社製）のゼロデイ脆弱性（CVE-2025-42599）を悪用したサイバー攻撃が2025年4月に発生し、複数の日本企業や組織に深刻な影響を与えています。この脆弱性は、スタックベースのバッファオーバーフローに起因するリモートコード実行（RCE）が可能な重大な欠陥です。CVSS v3スコアは9.8（緊急）と評価され、認証なしでネットワーク経由の攻撃が可能な点が特徴です。細工されたHTTPリクエストを送信することで、攻撃者がシステムの制御を奪い、任意のコードを実行したりサービスを停止させたりできます。
1．ゼロデイ脆弱性とは
ゼロデイ脆弱性とは、ソフトウェアやシステムに存在するセキュリティ上の欠陥（バグや設計ミスなど）が、開発元や利用者にまだ知られておらず、修正プログラム（パッチ）も提供されていない状態の脆弱性を指します。この「ゼロデイ（0-day）」という言葉は、開発元がその問題を認識してからユーザーが対策を取れるまでの「猶予期間がゼロ日」であることに由来しています。
ゼロデイ脆弱性は、発見された直後から攻撃者に悪用されるリスクが高く、利用者や管理者が防御策を講じる手段がないため、非常に危険です。攻撃者はこの脆弱性を突いて、システムへの不正侵入や情報窃取、サービス停止などを引き起こすことができます。特に、修正パッチが提供される前に攻撃が始まる「ゼロデイ攻撃」は、被害が拡大しやすく、企業や組織にとって大きな脅威となります。
ゼロデイ脆弱性が発見された場合、ソフトウェアメーカーやセキュリティ研究者は速やかに調査・修正に取り組みますが、パッチがリリースされるまでの間は、利用者側でできる対策が限られます。そのため、日頃から多層防御や脆弱性情報の早期収集、迅速なアップデート適用など、総合的なセキュリティ対策が求められます。
2．脆弱性の本質的な仕組み
この脆弱性は「スタックベースのバッファオーバーフロー」と呼ばれる仕組みに起因しています。コンピュータのメモリ領域の一部（スタック）に、プログラムが想定していない量のデータを送り込むことで、メモリの境界を超えて不正なコードを仕掛けることが可能になります。例えば、郵便受けの容量を超える大量の手紙を投函し、隣の部屋にまであふれさせてしまうようなイメージです。この現象を悪用されると、攻撃者が任意の操作を実行したり、システムをダウンさせたりできます。
この脆弱性が特に危険なのは、認証が不要で「ネットワーク経由」の攻撃が可能な点です。通常のWebリクエストを装った細工されたデータを送信するだけで、サーバーが不正な命令を受け入れてしまうため、外部からの侵入が容易になります。
3．社会的な影響範囲の広がり
2025年4月に判明した攻撃では、インターネットイニシアティブ（IIJ）やカゴヤ・ジャパン、WADAXなどの主要事業者が被害を受けました。特にIIJでは、最大400万人分の個人情報流出の可能性が指摘され、最終的に31万件のメールアドレスと586契約の情報漏洩が確認されています。
影響は特定の企業に留まらず、官公庁・大学・金融機関を含む2,250以上の組織、1,100万を超えるアカウントに及びました。ある調査によると、インターネット上に公開されているActive!サーバーの約3割（227台中63台）が大学のシステムで使用されており、教育機関へのリスクも浮き彫りになりました。攻撃の痕跡は2024年8月から確認されており、数か月間にわたり情報が窃取されていた可能性が指摘されています。
4．攻撃の兆候を確認する方法
システムが侵害されたかどうかを判断するには、セグメンテーションフォルト（メモリ違反エラー）の発生記録が手がかりになります。これは、プログラムが許可されていないメモリ領域にアクセスした際に発生するエラーで、ログファイル（例：/var/log/messages）に「segmentation fault」や「signal 11」といったキーワードが記録されます。
具体的な確認方法としては、サーバーのログを以下のコマンドで検索します。
grep -E "(amaddr|amadmin|amapi|amcache|amcoop|amfile|amguest|amhelp|amlogin|ammain|amoption|amupload|mlogin|mmain|slogin|smain). segfault" /var/log/messages
具体的なログとして、例えば
Apr 23 11:30:00 hostname ammain[12345]: segfault at 7f8a1b234000
のようなものを検索します。
Active! mailは複数の機能モジュールやプロセスによって構成されています。代表的なものには以下のようなものがあります。
amaddr：アドレス帳管理
amadmin：管理者用機能
amapi：API関連処理
amcache：キャッシュ管理
amcoop：協調作業関連
amfile：ファイル管理
amguest：ゲストユーザー処理
amhelp：ヘルプ機能
amlogin：ログイン処理
ammain：メインプロセス
amoption：オプション機能
amupload：ファイルアップロード
mlogin、mmain、slogin、smain：メールやセッション関連のサブプロセス
これらのプロセスは、Active! mailの各種機能を分担して処理しており、システム内で個別に動作しています。
上のコマンドはこれらのプロセスでセグメンテーションフォルトが発生しているログが無いかを確認します。
ただし、攻撃者がログを改ざんしている可能性もあるため、WAF（Webアプリケーションファイアウォール）の記録やネットワーク通信の異常（例：不審な海外IPアドレスからの接続）を併せて確認することが重要です。また、システムのメモリ使用量が急増したり、通常とは異なる時間帯に管理者権限の操作が記録されたりする場合も注意が必要です。
5．企業が取るべき多層的な対策
即時対応としては、開発元が4月16日に公開した修正版（BuildInfo: 6.60.06008562）へのアップデートが最優先です。ただし、アップデートがすぐに実施できない場合、WAFで「multipart/form-data」形式のリクエストのサイズを制限する暫定対策が有効です。
中長期的な対策では、以下の3つの視点が求められます。
①検知能力の強化：EDR（Endpoint Detection and Response）やSIEM（Security Information and Event Management）を導入し、異常なプロセスや通信をリアルタイムで監視します。
②サプライチェーンリスクの管理：ベンダーが提供するセキュリティ情報を迅速に収集する体制を整え、自社システムのソフトウェア資産を可視化します。
③インシデント対応の訓練：定期的なサイバー攻撃訓練を通じ、ログの保全手順や外部連絡窓口の運用フローを実践的に確認します。
対策全般にログが欠かせません。JPCERT/CCは「十分な期間（目安として1年以上）のログ保存」を推奨しており、攻撃の痕跡調査やインシデント対応のためには、各組織のリスクや運用実態に合わせて保存期間や世代管理を決定することが望ましいとされています。
また、パスワードの一括変更や多要素認証の導入により、情報漏洩時の被害拡大を防ぐ「被害封じ込め」の視点も欠かせません。
6．今後に備えて
今回の事例は、セキュリティパッチの適用遅延が重大な結果を招くことを改めて示しました。特に、Active! mailのような基幹システムでは、定期的な脆弱性診断と「ゼロトラストモデル」（あらゆる通信をデフォルトで不信とみなす設計）への移行が急務です。
技術的な対策に加え、人的な要素も重要です。例えば、開発元のクオリティアとユーザー企業が協力してCSIRT（Computer Security Incident Response Team）体制を強化し、情報共有を迅速化する仕組みが求められます。また、大学などの非営利組織でも、セキュリティ予算の確保と専門人材の育成が課題として浮上しています。
この攻撃は、単一の脆弱性が社会全体に波及する「サプライチェーン攻撃」の典型例です。企業は自社の防御だけでなく、取引先や利用サービスのセキュリティ状況を把握する「攻撃面管理（ASM）」の視点を持ち、リスクを総合的に評価する必要があります。
