ZabbixのWindows版に権限奪取の弱点、導入先次第で対象 CVE-2026-59781

サーバーの死活や負荷を見張る監視ソフト「Zabbix」のWindows版エージェントに、権限を奪われる恐れのある欠陥「CVE-2026-59781」が見つかりました。2026年8月18日にZabbix社が公表し、8月28日にはJPCERT/CCとIPAが運営する日本の脆弱性情報サイトJVNにも掲載されています。

Zabbixは、監視される側のサーバーに「エージェント」という小さなプログラムを入れて情報を送らせる仕組みです。今回の問題は、そのエージェントをWindowsに入れるときのインストーラにありました。

Zabbixは、ラトビアのZabbix社が開発している監視ソフトです。無償で使えることと、監視できる対象の幅が広いことから、国内でもシステム運用の現場に広く入っています。サーバーの負荷、ディスクの空き、サービスの生死、ネットワーク機器の状態などをまとめて見張り、閾値を超えたら通報する、という使われ方が中心です。

その構成上、エージェントは監視したいサーバー全台に入ります。数百台規模の環境も珍しくなく、しかも「入れたあとは触らない」種類のプログラムです。今回のように導入時の設定が問題になる案件では、この「入れっぱなし」の性質が効いてきます。

対象になるのは、既定以外の場所を指定して入れた環境だけです。案内どおり C:\Program Files\Zabbix Agent に入れている場合は、そのフォルダの権限がもともと管理者に絞られているため、この経路は成立しません。導入先を C:\zabbix のような独自の場所へ変えている環境が、確認すべき対象です。

見つけたのはGMOサイバーセキュリティ byイエラエの松本一真氏で、IPAの情報セキュリティ早期警戒パートナーシップを通じて報告されました。

何が起きるのか

CVE-2026-59781: 導入先フォルダの権限を確かめないまま入れてしまう

Zabbix社の説明はこうです。Windows版のZabbix agentを独自のフォルダへ入れるとき、インストーラはそのフォルダのアクセス権が安全かどうかを確認していませんでした。もし選んだフォルダが、管理者でないユーザーにも書き込みを許す設定になっていた場合、そこに悪意あるDLL（プログラムが部品として読み込むファイル）を置かれる余地が生まれます。

Windowsには、プログラムが部品を探すときの決まった順番があります。多くの場合、まず自分と同じフォルダの中を探します。そこに正規のものと同じ名前の偽物が置かれていれば、そちらが読み込まれます。これがDLLサイドローディングと呼ばれる手口です。

Zabbix agentはWindowsのサービスとして常駐し、既定ではLocalSystemという最上位のアカウントで動きます。したがって偽のDLLが読み込まれると、そのプログラムはサーバーを何でも操作できる権限で走ることになります。手元に一般ユーザーの権限しか持っていない攻撃者が、そこから一段上がるための足がかりになります。

Zabbix社は「攻撃が成立する経路」として、安全でない独自フォルダにファイルを書き込める攻撃者が、Windowsの探索順序を使って読み込ませる、と記載しています。

深刻度は、Zabbix社の評価で10点満点の5.4（中程度）です。JVNではもうひとつの計算方式で6.7とされています。数字が控えめなのは、攻撃者がすでにそのサーバー上にいて、かつ再起動やサービスの再開といったきっかけが必要だからです。いきなり外から乗っ取られる種類のものではありません。

影響するバージョンと、直ったバージョン

Zabbix社が課題管理システム上で公開している情報（ZBX-28077）では、対象と修正版は次のとおりです。

ここで注意が要ります。同じ案件を扱ったJVNの記載は「7.0.24より前」「7.4.8より前」となっており、Zabbix社の数字と食い違っています。開発元が自ら公開している情報の方が細かく、6.0系についても記載があるため、判断はZabbix社の表を基準にするのが安全です。JVNの数字で「うちは対象外」と結論を出すと、7.0.25から7.0.28の環境を取りこぼします。

6.4系や7.2系のように、すでに保守が終わっている系列には修正版が出ていません。これらを使っている場合は、保守が続いている6.0系・7.0系・7.4系のいずれかへ移す必要があります。

Windows版エージェントのバージョンを確認する

監視対象のWindows上で、実行ファイルに引数を付けて呼び出すと版が出ます。

"C:\Program Files\Zabbix Agent\zabbix_agentd.exe" -V

台数が多い場合は、Zabbix側からまとめて拾うのが早いです。エージェントには自分の版を返す項目が用意されているので、監視項目として agent.version を設定しておけば、管理画面の最新データ一覧で全台の版を並べて見られます。

どこに入っているかが分からない場合は、サービスの登録内容から実行ファイルの場所をたどります。PowerShellで次を実行します。

Get-CimInstance Win32_Service |
  Where-Object { $_.Name -like "Zabbix*" } |
  Select-Object Name, State, PathName

出てきたパスが C:\Program Files\ の下で終わっていれば、既定の場所です。それ以外の場所だった場合が、次の確認に進む対象になります。

導入先フォルダの権限を確認する

ここがこの件の肝です。今回Zabbix社が直したのはインストーラ側で、危険な場所を選んだときに警告を出して明示的な確認を求めるようになりました。裏を返すと、すでに緩い権限のフォルダへ入れてしまった環境は、エージェントを新しい版に更新しただけではフォルダの権限が直りません。更新と権限の見直しは別作業です。

権限は次のコマンドで確認できます。

icacls "C:\zabbix"

出力に BUILTIN\Users、Authenticated Users、Everyone といった広い対象に対して、書き込みや変更を意味する (W)、(M)、(F) が付いていれば、条件に当てはまります。読み取りと実行だけを意味する (RX) しか付いていなければ問題ありません。

特に C:\ の直下に作ったフォルダは注意が必要です。ドライブの根元には、標準ユーザーにも一定の作成権限が残る初期設定があり、そこに作ったフォルダがその設定を引き継いでいることがあります。「管理者で作ったのだから管理者しか触れないはず」という思い込みは、実際に icacls で見て確かめる価値があります。

緩かった場合の直し方は2通りです。ひとつは、そのフォルダの権限を管理者だけに絞ること。もうひとつは、いったんエージェントを削除して既定の場所へ入れ直すことです。運用の都合で場所を変えている場合は前者、そうでなければ後者の方が後々の混乱が少なくなります。

Windows版エージェントの上げ方

Zabbixのエージェントは、監視する側のサーバー（Zabbixサーバー）と版が完全に一致していなくても動きます。古いエージェントが新しいサーバーと通信することは想定されており、エージェントだけを先に上げても問題は起きません。逆に、エージェントの方が新しい場合も同様です。ここが分かっていると、監視基盤全体の入れ替え計画を待たずにエージェントだけ片付けられます。

Windows版はインストーラ（MSI形式）で配布されています。手順は、Zabbixの公式ダウンロードページから該当する版のインストーラを取得し、既存のものに上書きで実行する形です。設定ファイルの内容は引き継がれますが、念のため zabbix_agentd.conf を作業前に控えておくと戻しやすくなります。

台数が多い環境では、資産管理ツールやグループポリシー、構成管理ツールから静かに配布する方法が使えます。MSIは無人実行に対応しており、導入先やZabbixサーバーのアドレスを引数で指定できます。このとき導入先の指定を既定のままにしておけば、今回の問題そのものが起きません。過去に独自の場所を指定していた台があるなら、この配布のタイミングで既定へ寄せるのが片付けとしては早道です。

作業後の確認は、Zabbixの管理画面で該当ホストの状態が緑に戻っていること、agent.version の値が新しくなっていることの2点で足ります。値が古いままなら、サービスが再開していないか、別の場所に残った古い実行ファイルが動いている可能性があります。

攻撃されているのか

2026年8月28日時点で、この欠陥が実際の攻撃に使われたという報告は確認されていません。CISAが公開している、悪用が確認された脆弱性のカタログにも収載されていません。動作確認用のプログラムが公開されているという情報もありません。

Zabbix社の課題管理システム上でも、この案件の優先度は最も低い「Minor」に分類されています。緊急で全社を止めて対応する種類のものではなく、通常の更新計画の中で片付ける位置づけです。

ただし、監視エージェントはあらゆるサーバーに横断的に入っているという特徴があります。1台で通用する手が全台で通用するため、攻撃者から見れば効率のよい対象です。すでに社内ネットワークへ入り込んだ攻撃者が、権限を上げて横へ広がる段階で使う道具としては、十分に現実的な選択肢になります。

何をすればいいか

順番としては、まず監視対象のWindowsサーバーで、Zabbix agentがどこに入っているかを洗い出します。既定の場所しか使っていないことが確認できれば、この件での追加作業は不要です。実際、社内標準の手順書どおりに導入している組織では、大半がここで終わります。

独自の場所へ入れているものが見つかったら、icacls で権限を確認します。緩ければ絞る、あるいは既定の場所へ入れ直す。ここまでやって初めて、実際の危険は消えます。

エージェント本体の更新は、7.4.13・7.0.29・6.0.48のいずれかへ上げます。これはインストーラの改善を取り込む作業なので、今後の導入で同じ問題を繰り返さないための措置という位置づけです。Zabbix社が挙げている回避策も、権限を管理者だけに絞ったフォルダへ導入すること、既存の独自フォルダの権限を見直すことの2点で、更新そのものより権限側に重心があります。

なお、Zabbixサーバー本体やフロントエンド、Linux版のエージェントはこの件の対象外です。監視基盤全体を止めて入れ替えるような話ではありません。Windows版エージェントの版を上げると監視が数十秒止まりますが、監視の停止を検知して通報が飛ぶ設定になっている場合は、作業前に保守中の設定へ入れておくと余計な連絡が減ります。

最後に、この機会に導入先の場所を社内で揃えておくと、次に同じ種類の連絡が来たときの調査が短くなります。台数が数百規模になる環境では、導入先がばらついていること自体が、毎回の対応コストを押し上げる原因になります。導入先が揃っていれば、次に似た連絡が来たときに「既定の場所しか使っていない」と一行で答えて終われます。

参照元

• ▸ Zabbix - ZBX-28077（CVE-2026-59781）（2026年8月18日）
• ▸ JVN#42011956 - Zabbix agentにおけるDLL読み込みに関する脆弱性（2026年8月28日）
• ▸ NVD - CVE-2026-59781
• ▸ Zabbix - Security Advisories