Wazuh の脆弱性 CVE-N/A (CVSS 10.0) が FIX:危険なインジェクション・プリミティブ

Critical Wazuh Flaw Enables Threat Actors to Alter Alerts and Remove Logs

2026/06/15 gbhackers — Wazuh Manager に存在する深刻なセキュリティ脆弱性 CVE-N/A (CVSS 10.0) を悪用する未認証の脅威アクターが、新しいインベントリ同期パイプラインにおける入力検証の弱点を突く可能性がある。それにより、アラートの改竄/フォレンジック証拠の削除/任意の OpenSearch 操作の実行などが引き起こされる恐れがある。この脆弱性は、GitHub アドバイザリ GHSA-ff9g-85jq-r3g3 として追跡され、Wazuh Manager バージョン 5.0.0-beta1 に影響を及ぼす。

この脆弱性は、エージェントが制御すべき入力が、inventory_sync モジュールにおいて適切に無害化されない点に起因する。その結果として、Wazuh の OpenSearch バックエンドに保存されるセキュリティ・テレメトリの完全性を損なう、強力な NDJSON インジェクション攻撃が可能となる。

深刻な Wazuh の欠陥

根本的な原因は、登録済みエージェントから提供される DataValue.index フィールドを、Wazuh が処理する方法にある。それにより、このフィールドは、サニタイズや検証を受けることなく、OpenSearch の _bulk API リクエストに直接埋め込まれる。

_id などのフィールドではエスケープ処理が行われるが、_index の値は生の入力として追加されるため、攻撃者に任意のバルク操作を許すインジェクション・プリミティブが生じる。

Wazuh のデフォルト・コンフィグでは、TCP ポート 1515 経由で匿名のエージェント登録 (use_password=no) が許可されるため、攻撃者は認証なしで不正なエージェントを登録できる。

登録後の攻撃者は、改行文字と追加の JSON アクションを取り込んだ、悪意の DataValue.index ペイロードを作成できる。これにより、Wazuh Manager から送信されるバルクリクエストに対して、不正な操作を紛れ込ませることが可能となる。

脆弱なコードパスの簡略な例で分かるのは、サニタイズされていない入力が NDJSON ペイロードへ直接追加されていることである。

m_bulkData.append(R"({"index":{"_index":")");m_bulkData.append(index); // Untrusted inputm_bulkData.append(R"("}})");m_bulkData.append("\n");

以下のようなペイロードを注入する。

wazuh-states-inventory"}}{}{"delete":{"_index":"wazuh-alerts-*","_id":"target-doc"}}{"index":{"_index":"x

Wazuh Manager が意図していない操作を、攻撃者の権限で実行させることが可能になる。通常の Manager は、keystore に保存された認証情報を用いて OpenSearch に対して認証を行う。デフォルトのデプロイメントでは、admin および all_access ロールが設定されることが多いため、注入されたコマンドはクラスタ全体に対する完全な権限で実行される。

それにより可能となる攻撃シナリオには、wazuh-alerts-* のアラートログ削除/エージェント全体にわたる脆弱性データやインベントリ・データの操作/分析担当者が閲覧する .kibana_1 ダッシュボードへの永続的ペイロード挿入といったものがある。

マルチテナント環境で、インデックス単位の分離のみが制御境界となっている場合には、テナントをまたいだデータ改竄が可能になり得る。

注目すべき点として、この脆弱性はユーザー操作を必要としない。標準の Wazuh リモート・プロトコル (TCP/1514) 経由でリモートから実行可能であり、実環境における悪用可能性は高い。

研究者が実証したのは、End-to-End での悪用の成功と、指定したドキュメントの削除である。その際に、OpenSearch は正規の Manager 認証情報の下で “result”:”deleted” を返していた。

この問題は、CWE-74 (インジェクション)/CWE-93 (CRLF インジェクション)/CWE-863 (不正な認可) などの、複数の CWE に分類されている。それらが示すのは、入力検証の失敗と、エージェント/Manager 間の信頼境界の破綻である。

PoC repository (Source: Github)
PoC repository (Source: Github)

すでに Wazuh は、バージョン 5.0.0-beta3 をリリースし、_index フィールドに適切なエスケープ処理を導入することで、この問題に対処している。さらに、取り込みポイントでの厳格な検証を推奨している。

安全な実装は、既存の _id フィールド向け保護と同様の方式を採用している。

appendEscapedIndex(m_bulkData, index); // Sanitized input handling

さらに、管理者に対して推奨されるのは、OpenSearch のインデックス命名規則を強制し、Manager の keystore 認証情報において admin/all_access などの過度に強力なロールを使用しないことである。たとえば、最小権限のロールである wazuh-server などへ移行することで、悪用時の影響範囲を大幅に縮小できる。

悪用の容易さと、データの完全性/可用性に対する深刻な影響を踏まえると、Wazuh 5.x ベータ版を使用している組織は直ちにアップグレードすべきである。さらに、インデックスのアクセス制御/エージェント登録設定/OpenSearch のロール構成を見直し、リスクを軽減する必要がある。