Wazuh（オープンソースのセキュリティ監視・脅威検知プラットフォーム）のManager（エージェントからのログを集約し、ルール照合やアラート生成を担う中核コンポーネント）を運用しているなら、見過ごせない脆弱性が報告されています。CVE-2026-74041です。今回はフロントエンド技術の文脈とは少し離れますが、監視基盤を自前で構築している開発チームにも関わる内容として整理します。
対象はWazuh Manager 4.14.3から4.14.7です。修正版は4.14.8以降となります。INCIBE-CERT（スペインの国家サイバーセキュリティ機関の下にあるCERT組織）が2026年10月16日に「INCIBE-2026-753」としてクリティカル評価の勧告を出しています。
何が起きるか
この脆弱性の恐ろしさは、攻撃の起点が「特別な権限」ではない点にあります。
manager:update_configという、設定変更を行うための一般的な権限を持つ認証済みユーザーであれば、root権限でのコマンド実行まで到達できます。設定変更権限を持つ管理者アカウントは、どの組織にも最低一人は存在するはずです。
必要な操作はただの「リロード」です。設定を書き換えたあとManagerを再起動・再読み込みする、日常的な運用操作の中に攻撃の最終ステップが紛れ込みます。特別な侵入手段を使わずとも、通常業務の延長線上で権限昇格が成立してしまう構造です。
なぜ起きるか
原因はossec.conf（Wazuhの中核設定ファイル）のバリデーター（入力値を検証する処理）と、実際にログを処理するwazuh-logcollectorの間にある、大文字小文字の扱いの不一致です。
設定ファイルの検証を行うモジュールは、ある書き方のLOG_FORMATディレクティブ（ログ形式を指定する設定項目）を「正しい値」として通します。ところが実行時にログを処理するコンポーネントは、大文字・小文字の違いを別の意味として解釈してしまいます。
この解釈のズレこそが本質です。バリデーターが「安全」と判定した入力が、実行エンジン側では想定外のコマンド実行経路を開いてしまいます。入力検証とランタイムの実装が別々のコードベースで管理されている場合、こうした仕様の乖離はしばしば発生します。Webアプリケーションにおけるフロントエンドのバリデーションとバックエンドのバリデーションが食い違うケースと構造はよく似ています。見た目は通っても、裏側の処理系では別物として扱われるという典型的な「検証の二重化によるすり抜け」です。
自分の環境が該当するか確認する
まず現在のManagerのバージョンを確認します。
/var/ossec/bin/wazuh-control info出力に含まれるWAZUH_VERSIONが4.14.3から4.14.7の範囲にあれば対象です。クラスタ構成の場合は全ノードで実行してください。
次に、設定ファイル内のLOG_FORMATディレクティブの大文字小文字の書き方を確認します。
grep -i "log_format" /var/ossec/etc/ossec.conf通常と異なる大文字・小文字の組み合わせ（例えば一般的でない表記ゆれ）が見つかった場合は、特に優先して調査する価値があります。
あわせて、現在manager:update_config権限を保持しているアカウント一覧をWazuh APIまたは管理画面のロール設定から洗い出します。この権限は設定変更に必要な権限ですが、今回の脆弱性の前提条件でもあるため、保持者の数を把握しておくことが対策の土台になります。
本番環境だけでなく、ステージング環境にも注意してください。本番と同じ設定を流用したステージング用Managerは、環境ラベルに関係なく同じ欠陥を抱えています。脆弱性はソフトウェアのバージョンに紐づくものであり、環境の重要度とは無関係です。
対策の手順
1. スコープの洗い出し
稼働中の全Managerインスタンスとそのバージョンを一覧化します。セカンダリノードやステージングのコピーも漏らさず含めてください。
2. アップグレードの順序を決める
4.14.8以降へのアップグレードパスは公式ドキュメントに従います。クラスタ構成の場合、ノードごとに順次アップグレードするか、計画停止でまとめて切り替えるかを事前に決め、判断の記録を残します。どちらを選ぶかは可用性要件とメンテナンスウィンドウの確保しやすさで判断してください。
3. 証跡を残す
変更前の設定ファイル、変更チケット、変更後の各ノードのバージョン出力をすべて保存します。これはコンプライアンス上の体裁ではなく、後日「特定の期間、特定のホストが脆弱な状態だったか」を答えられるようにするための記録です。
4. ロールバック条件を事前に確認する
万一アップグレード後に問題が起きた場合、どのバージョンに戻すかを事前に決めておきます。ただし4.14.7以前に戻すことは、この脆弱性を再び開くことを意味します。インシデントが起きてから気づくのではなく、計画の時点で明記しておくべき事実です。
5. アップグレードまでの間の緩和策
アップグレード作業までに時間がかかる場合、次の緩和策で発生確率と検知確率を下げられます。
manager:update_config権限の保持者を必要最小限に絞り込むLOG_FORMATディレクティブの大文字小文字の表記を定期的に監査する- 設定リロードの実行ログを変更チケットと突き合わせて確認する
これらはあくまで緩和策であり、根本原因であるバリデーターとログコレクターの解釈の不一致そのものは、アップグレードでしか解消できません。
公開時点の補足情報
公開時点で、この脆弱性が実際に悪用された記録はありません。インターネット上に公開されているWazuh関連の資産数を調べるZoomEye（中国発のIoT・サーバー検索エンジン）の調査では、app="Wazuh"で18,031件がヒットした一方、CVE番号で絞り込んだ件数はゼロでした。
この数字の読み方には注意が必要です。前者は単にWazuhらしき指紋を持つ資産の総数であり、後者は脆弱性情報としてインデックスされた件数にすぎません。どちらも「実際に脆弱なサーバーの数」を示すものではない点を押さえておいてください。
まとめ
CVE-2026-74041は、設定検証ロジックと実行時ロジックの解釈違いという、監視基盤特有ではなく一般的なソフトウェア設計の落とし穴から生まれています。
対応の優先順位は次の3点に整理できます。
- まず
wazuh-control infoでバージョンを確認し、4.14.3〜4.14.7に該当するか判断する - 該当する場合は4.14.8以降へのアップグレード計画を、スコープ・順序・証跡・ロールバック条件まで含めて文書化する
- アップグレードまでの間は
manager:update_config権限の保持者を絞り込み、LOG_FORMATの表記ゆれを監査する
セキュリティ監視基盤そのものが攻撃対象になるという構図は皮肉ですが、だからこそ変更管理のプロセスを丁寧に踏むことが、他のミドルウェアの脆弱性対応以上に意味を持ちます。