GUARDIANWALLを使う会社はいま確認を、攻撃すでに進行中

国内の企業向けメールセキュリティ製品「GUARDIANWALL MailSuite」に、深刻度が最高ランク（CVSSスコア9.8）の脆弱性が見つかりました。JPCERT/CCの注意喚起によると、外から細工した通信を一度送るだけで、ログインなしにサーバー側で任意のプログラムを実行できる状態にされてしまうとのことです。

同製品はメールの誤送信防止や情報漏えい対策のために導入されるもので、メーカー公表によれば国内4,000社・580万ユーザー超が使っています。研究機関や通信事業者、財団など、メールが業務の中心にある組織が並びます。そしてこの脆弱性を悪用した攻撃は、すでに観測されていると開発元のキヤノンITソリューションズが認めています。

公開告知は2026年5月13日。本記事を書いている時点で8日が経過しています。それでもこの記事を出すのは、社内の管理者が「うちは影響あるのか、ないのか」をまだ判断できていない例が周辺で続いているからです。情報を整理し直し、自社の環境で今日打てる手を、順番にまとめます。

何が起きているのか

問題が見つかったのはGUARDIANWALL MailSuiteの中の「pop3wallpasswd」というコマンドです。メールの受信処理に関係する内部プログラムで、Webサービス経由で呼び出される構成になっています。ここに、想定よりも長いデータを投げ込むと処理がはみ出してしまう、いわゆる「スタックベースのバッファオーバーフロー」が成立する作りになっていました。

攻撃者は、サーバーに向けて細工したリクエストを一度送ります。それだけで、本来は管理者が手で打ち込むべきコマンドの代わりに、攻撃者の用意したプログラムがサーバー側で動いてしまいます。ログイン画面もパスワードも経由しません。ユーザー操作も要りません。

識別番号はCVE-2026-32661。米国の脆弱性管理基準であるCVSSのスコアはv3で9.8、v4で9.3です。10点満点中9点を超える評価は「緊急（Critical）」と分類され、公的機関が「最優先で対処すべき」と通知する水準にあたります。情報処理推進機構（IPA）も5月13日付で注意喚起を出しました。

影響を受けるのは「オンプレミス版」

GUARDIANWALLには社内のサーバーに置く「オンプレミス版」と、クラウドで提供される「Mailセキュリティ・クラウド版」の2系統があります。影響範囲はこの2つで分かれています。

オンプレミス版のうち、Ver 1.4.00からVer 2.4.26までの全バージョンが対象です。長期に渡る範囲のため、社内で動いているものは「ほぼ全部、何かしらの対応が要る」と考えた方が現実に近い数字です。クラウド版（GUARDIANWALL Mailセキュリティ・クラウド）は、運営側の2026年4月30日のメンテナンスで修正が完了していると発表されています。クラウド版の利用企業は、追加の操作は不要です。

対象機種の照合と対応手順

自社の環境がどの版にあたるかを確認するところから始めます。判定の早見表を置きます。

どちらに該当するかが分からない場合は、まずGUARDIANWALLの管理画面でバージョン番号を確認します。社内に管理者が複数いる場合は、運用担当だけでなく、契約担当にも「クラウド版かオンプレミス版か」の契約区分を確認した方が早いケースがあります。バージョン1系（1.4.x）と2系（2.x）はリリースが何年も離れた古い世代を含むため、長く触っていない環境ほど該当する可能性が高くなります。

オンプレミス版に該当した場合、最優先で行うのはキヤノンITソリューションズが提供する修正パッチの適用です。同社は5月1日と5月4日に、対象のお客様窓口に対して個別に通知メールを送っています。社内の受信メールを「キヤノンITソリューションズ」で全文検索すると、サポート連絡が届いていることが多いです。届いていない場合は、契約しているサポート窓口に直接連絡して、自社が対象かどうかをまず確認する流れになります。

パッチを今すぐ当てられない事情がある場合（業務時間の関係で当夜に作業できない、検証環境がまだない、など）に限り、暫定対応として管理画面プロセスを停止する方法が案内されています。具体的にはサーバー上で /etc/init.d/grdn-wgw-work stop を実行して停止し、再開時に /etc/init.d/grdn-wgw-work start で戻します。ただしこの停止は管理画面そのものを止める操作で、運用への影響が大きいと開発元自身が記載しています。あくまで「すぐにパッチが当てられない時間の橋渡し」として位置付けてください。

攻撃はすでに進行している

同種の深刻脆弱性は、公開告知の段階では「悪用は確認されていない」と書かれることが多くあります。今回は逆です。Security NEXTの報道でも繰り返し触れられている通り、開発元のキヤノンITソリューションズは「同脆弱性を悪用した攻撃がすでに確認されている」と明言しています。

攻撃者の正体や、攻撃が観測された具体的な企業の特定は今のところ公表されていません。ただしメール製品が攻撃の入口となった場合、被害は受信メールの覗き見にとどまらず、メールサーバーを足がかりにした横展開（社内ネットワーク内の他のサーバーへの侵入）に発展する例がこれまでにも繰り返し報告されてきました。GUARDIANWALLはメールの中身を見て判定する性質上、業務メールの本文や添付ファイル、宛先情報を一時的にであれ通過させる位置にあります。「関所」と呼ばれる立ち位置の機器が破られた時の波及範囲は、機器単体の話では収まりません。

脆弱性の技術的な分類はCWE-121（スタックベースのバッファオーバーフロー）。攻撃が成立する経路は前述したpop3wallpasswdコマンドで、これがgrdnwwwというユーザー権限で動いている構成のときに発火します。技術的にはよく知られた古いタイプの脆弱性ですが、認証なしで遠隔から到達できる位置にあるため、「枯れた手口」が「いま使える攻撃」に化けてしまっているのが今回の構図です。

パッチ適用までの間にやっておきたいこと

修正パッチの適用が最優先である点は変わりません。一方で、即時にパッチを当てきれない環境では、被害の兆候を見逃さないための準備も並行して進めておく価値があります。

まず、GUARDIANWALLサーバーのWebサービスへのアクセスログを保全します。攻撃の侵入経路はWebサービスのリクエストなので、調査時に手がかりになるのはここのログです。次に、メール送受信のログを通常より長めの期間で確保しておきます。攻撃が観測されているということは、社内環境でも痕跡が残っている可能性があり、後から「いつから影響を受けていたか」を遡るために必要になります。サーバーに対するインバウンドのネットワーク通信のうち、業務時間外のアクセスや、海外IPからの到達が記録されていないかも、この機会に見ておきたいところです。

攻撃を受けた疑いがある場合は、自社内で完結させずにJPCERT/CCや、契約している外部のセキュリティ事業者へ早めに連絡する判断が現実的です。攻撃の進行が観測されているケースでは、独力での状況把握に時間をかけている間に被害が広がる例が珍しくありません。

公式アドバイザリの読み方と、開発元の対応

キヤノンITソリューションズのサポート情報ページには、公開告知が2026年5月13日14時05分に掲載されています。それ以前、5月1日と5月4日には、契約顧客向けに個別の連絡が走っています。公開告知よりも先に当事者顧客に通知が行く流れは、影響範囲が大きい脆弱性で取られることがあるパターンです。

アドバイザリ本文では、修正パッチの具体的なバージョン番号は本ページ上に公開されていません。サポート契約を結んでいる顧客が、専用窓口経由でパッチを受け取る運用になっているためです。これは法人向け製品ではよく取られる配布方式で、不特定多数に修正コードを公開して攻撃者に逆解析される時間を渡さないための判断と見られます。逆に言えば、サポート窓口に未連絡のまま放置されているシステムがあると、修正パッチが社内に届かない状態が続くことになります。

サポート契約が切れている、あるいは長年連絡が途絶えている環境を運用している場合は、まず契約の再確認と、サポート窓口との連絡の復旧から始める方が結果的に早道になります。

中小企業や、IT担当者が兼任の組織はどう動くか

GUARDIANWALLは法人向け製品ですが、価格帯と機能から、専任のIT管理者がいる組織だけが入れているわけではありません。情シスが他業務と兼任になっている中堅企業や、地方自治体、研究機関で導入されている例があります。こうした「IT専任者がいない」「いてもひとり」という現場では、今回のような緊急対応はそもそも作業負荷が想定外になります。

現実的な手順としては、まず社内で「GUARDIANWALLを誰が契約していて、誰がサーバーを物理的に触れるか」を一行のメモに整理するだけでも、その後の判断が早くなります。社内に該当する人物がいない場合は、契約しているシステム保守業者が窓口を兼ねていることが多いので、メールセキュリティの管理を外注している先に「CVE-2026-32661への対応状況を教えてほしい」と問い合わせる流れになります。問い合わせる側がCVE番号を提示できると、保守業者側の確認が早く進む傾向があります。

パッチ適用の作業時間そのものは、製品によりますが数十分から数時間の範囲です。むしろ事前の確認、サポート窓口への連絡、適用後の動作確認に時間がかかります。業務時間内に終わらせる前提を組まず、夜間や休日の作業枠を確保した方が、結果的に止める時間が短くなります。

まとめと、ここからの注意点

GUARDIANWALL MailSuiteの脆弱性は、深刻度が最高ランク、認証なしで遠隔から悪用可能、すでに攻撃が観測されている、という3つの条件が揃っています。ScanNetSecurityの記事でも触れられているように、影響範囲はオンプレミス版のVer 1.4.00から2.4.26まで広く、SaaS版は4月30日に修正済みです。やるべきことの順番は、自社の利用形態を確認する、サポート窓口に連絡してパッチを受け取る、業務影響を考えてパッチを当てる、という流れに整理できます。

メールは止まると業務が止まります。だからこそ、メールセキュリティ製品はパッチが当てづらく、放置されやすい立ち位置にあります。今回の脆弱性は、その放置を狙い撃ちにできる構造を持っています。社内で「うちのメール関係の機器、最近触ったか」と一言聞いてみるところから、対応を始めても遅くはありません。

最後に、メーカーや関連機関は今後、追加情報を出していく可能性があります。JVNの該当ページとキヤノンITソリューションズのサポート情報ページは、ブックマークしておくと続報のチェックが楽になります。

参照元

• ▸ JVN#35567473 - GUARDIANWALL MailSuiteにおけるスタックベースのバッファオーバーフローの脆弱性（2026年5月13日）
• ▸ JPCERT/CC - GUARDIANWALL MailSuiteにおけるスタックベースのバッファオーバーフローの脆弱性に関する注意喚起（2026年5月13日）
• ▸ IPA - 「GUARDIANWALL MailSuite」におけるスタックベースのバッファオーバーフローの脆弱性について（2026年5月13日）
• ▸ キヤノンITソリューションズ - GUARDIANWALL MailSuite スタックベースのバッファオーバーフロー脆弱性に関するご対応依頼（2026年5月13日）
• ▸ Security NEXT - 「GUARDIANWALL MailSuite」に深刻な脆弱性 - すでに悪用も（2026年5月13日）
• ▸ INTERNET Watch - 「GUARDIANWALL MailSuite」に深刻な脆弱性、修正パッチ適用を クラウド版は修正済み（2026年5月13日）
• ▸ ScanNetSecurity - GUARDIANWALL MailSuite にスタックベースのバッファオーバーフローの脆弱性（2026年5月18日）
• ▸ Innovatopia - GUARDIANWALL MailSuiteに緊急脆弱性、悪用確認済み（2026年5月）
• ▸ キヤノンMJグループ - GUARDIANWALLシリーズ製品紹介