Checkmk RCE：1つのパッチに3つの重大な脆弱性（CVE-2026-121374）

Checkmk の3つの脆弱性により、ルール編集者、悪意あるリモートサイト、侵害されたホストがサイトユーザーとしてコードを実行できます。2.5.0p19 で修正されました。

Ostorlab Team 2026年11月11日

要点

Checkmk 2.5.0p19 と 2.4.0p40 は、いずれもサイトユーザーとしてのコード実行につながる3つの重大な脆弱性を修正します。ベンダーは2026年11月11日に両方の修正版を公開しました。
2.5系の 2.5.0p19 より前、または2.4系の 2.4.0p40 より前のすべてのサイトが影響を受けます。バージョン 2.3.0 はサポート終了のため修正されません。
3つとも CVSS v4.0 9.4 の重大です。公開された実証コードや実際の悪用は確認されておらず、2026年11月11日時点で CISA の KEV カタログにも登録されていません。
2.5.0p19 または 2.4.0p40 に更新してください。更新できない場合は、ルール編集を制限し、信頼できないリモートサイトをセントラルサイトに接続しないでください。制限の詳細は「修正方法」を参照してください。

影響を受けますか？

バージョン条件はすべての脆弱性に共通で、その他の条件は記載された各 CVE に個別に適用されます。

2.5.0p19 より前の 2.5.0、または 2.4.0p40 より前の 2.4.0 で Checkmk サイトを運用している。バージョン 2.3.0 は影響を受け、サポートも終了しています。
CVE-2026-121374 では、少なくとも1人のユーザーが少なくとも1つのフォルダーでルールを編集できる。既定では、フォルダーの権限を持つ「Normal monitoring user」ロールが該当します。
CVE-2026-118965 では、セントラルサイトが、完全には信頼していないリモートサイトから検出済みホストラベルを同期している。
CVE-2026-120495 では、Pro、Ultimate、Cloud、Ultimate MT のいずれかで Robotmk 合成監視を使用しており、監視対象ホストが細工したエージェントデータを送信できる。

1つ目の脆弱性に Kubernetes は不要です。ルールを作成できるユーザーは、サイトがクラスターを監視していなくても Kubernetes スペシャルエージェントのルールを追加できます。3つ目の脆弱性では、ホストの自動サービス検出が有効か、監視管理者が Robotmk サービスを手動で追加する必要があります。

系列	影響を受けるバージョン	修正バージョン
2.5	2.5.0 から 2.5.0p18	2.5.0p19（2026-11-11 公開）
2.4	2.4.0 から 2.4.0p39	2.4.0p40（2026-11-11 公開）
2.3	すべての 2.3.0	なし。サポート終了
3.0	3.0.0b1	未公開。修正を含む

リモートサイトを含むすべてのサイトでバージョンを確認します。

omd version

サイト内では、監視コアが同じバージョンを報告します。

sudo -u <site> cmk --version

Web インターフェースでは Help > About に表示されます。どのサイトが存在するかわからない場合は、omd sites でサイト名を一覧できます。

修正方法

お使いのエディションとディストリビューションに対応する 2.5.0p19 または 2.4.0p40 のパッケージをインストールし、各サイトを更新します。ベンダーの werk ページでは、更新後に手動操作が不要な互換バージョンとして記載されています。

お使いのエディションに対応するパッケージをインストールします。たとえば check-mk-raw-2.5.0p19、check-mk-enterprise-2.5.0p19、または同等の 2.4.0p40 パッケージです。
リモートサイトを含むすべてのサイトを更新します。 omd update <site>
Checkmk アプライアンスでは、アプライアンスの画面で 2.5.0p19 または 2.4.0p40 のイメージをアップロードし、そこで更新を実行します。
結果を確認します。 omd version
分散構成の各サイトで繰り返します。ホストラベルの脆弱性はセントラルサイトで修正され、Kubernetes と Robotmk の脆弱性はそれらのチェックを実行するサイトで修正されます。

すぐに更新できない場合は、次の対策で露出を減らしてください。いずれも攻撃経路を1つ制限するものであり、パッチの代わりにはなりません。

管理以外のすべてのロールから「Edit rules」権限を外し、それらのロールが到達できるフォルダーを確認します。管理者は CVE-2026-121374 を依然として悪用できるため、この対策は通常の監視ユーザーの既定経路をなくすだけです。
管理していないリモートサイトをセントラルサイトに接続しないでください。CVE-2026-118965 には設定スイッチがなく、修正は更新だけです。
CVE-2026-120495 では、監視対象ホストを信頼しないものとして扱います。サービスを追加できる人を制限し、管理していないホストでは自動サービス検出を無効にします。エージェントデータを送信できるホストは、管理者がそのサービスを追加すると依然として脆弱性に到達します。
2.3.0 のサイトは 2.4.0p40 または 2.5.0p19 に移行してください。2.3.0 系はサポート終了で、修正版がありません。

根本原因は何ですか？

3つの脆弱性には共通のパターンがあります。低い権限の主体が制御する値が、制限なしにコマンドラインまたはファイルパスに到達します。そしてサイトユーザーの権限が、その書き込みをコード実行に変えます。入口はそれぞれ異なるため、修正もそれぞれ異なります。

1つ目は Kubernetes スペシャルエージェントにあります。ルールオプション「Cluster resource aggregation > Exclude nodes based on their role」はロール名を集めます。サーバー側の呼び出しは、その名前を1つのオプションの後に個別のコマンドライン引数としてエージェントに渡します。

match params.cluster_resource_aggregation:
    case ("cluster_aggregation_exclude_node_roles", list(excluded_roles)):
        args.append("--cluster-aggregation-exclude-node-roles")
        args.extend(excluded_roles)

エージェントは argparse で引数を解析します。脆弱なパーサーはこのオプションを nargs="+" で宣言していたため、オプションに見えない後続のトークンをすべて消費しました。

group.add_argument(
    "--cluster-aggregation-exclude-node-roles",
    nargs="+",
    default=["control-plane", "infra"],
    dest="roles",
)

--profile で始まるロール値は、argparse にとって値ではありません。新しいオプションであり、次のロール値がその引数になります。--profile オプションはプロファイルデータをファイルに書き込み、同じディレクトリに、プロファイルのパスをソースに含む実行可能な Python ランチャーを書き込みます。

f'stats = pstats.Stats("{self._profile_file}")\n'

したがって、二重引用符と Python 構文を含むパスはランチャーのソースを変えます。werk の評価では、ルール編集者は内容を制御した実行可能な Python スクリプトを書き込み、サイトユーザーとしてのコード実行に到達できます。

2つ目はホストラベルの同期にあります。セントラルサイトは各リモートサイトにホストの検出済みラベルを問い合わせ、返された内容をディスクに書き込みます。脆弱なコードは、リモートサイトが提供したファイル名を確認せずにラベルディレクトリに連結していました。

def save_updated_host_label_files(updated_host_labels: list[UpdatedHostLabelsEntry]) -> None:
    for file_name, mtime, content in updated_host_labels:
        file_path = cmk.utils.paths.discovered_host_labels_dir / file_name
        store.save_text_to_file(file_path, content)
        os.utime(file_path, (mtime, mtime))

../ を含むファイル名はディレクトリの外に出て、別の拡張子で終わる名前はサイトが後で読み込むまたは実行するファイルを書き込みます。侵害されたリモートサイトは、セントラルサイトに任意のファイルを書き込めます。

3つ目は Robotmk テストサービスにあります。このサービスはエージェントデータのテストケース名を受け取り、HTML ログのフォルダーを作成するために使います。最終的なパスが検証されていなかったため、細工したテストケース名はログディレクトリの外に出ます。ログの内容もユーザーが定義するため、ベンダーの評価ではこの書き込みがコード実行になります。

どのように悪用されますか？

各脆弱性には異なる出発点が必要です。3つ目を除き、監視対象ホスト自体の脆弱性は不要です。3つ目は、エージェントデータを送信できるホストが必要です。

CVE-2026-121374 の場合：

ルールを編集できるユーザーが Kubernetes スペシャルエージェントのルールを作成または変更します。
「Exclude nodes based on their role」で、ユーザーは --profile をロールとして、パスを次の値として入力します。
スペシャルエージェントが実行されると、argparse は --profile をオプションとして、パスをその引数として読み取ります。
エージェントはプロファイルデータとランチャースクリプトを指定されたパスに書き込みます。ランチャーはパスを Python 文字列の中に含みます。
引用符と Python コードで細工したパスはランチャーのソースを変えます。ベンダーは、結果として得られる実行可能スクリプトをサイトユーザーとしてのコード実行と見なしています。

CVE-2026-118965 の場合：

攻撃者が分散構成のリモートサイトを制御するか、侵害します。
リモートサイトは、../ を含むファイル名でセントラルサイトのラベル要求に応答します。
セントラルサイトの同期は、指定された内容を解決されたパスに書き込みます。
攻撃者は、サイトユーザーが読み込むまたは実行するパスを選び、セントラルサイトでコード実行を得ます。

CVE-2026-120495 の場合：

攻撃者は、悪意あるエージェントプラグインやスプールファイルなどで、監視対象ホストのエージェントデータを追加できます。werk によると、通常は監視対象ホストの root 権限が必要です。
細工したデータは、HTML ログディレクトリの外に出る Robotmk テストケース名を定義します。
サイトは、攻撃者が内容を制御する HTML ログを解決されたパスに書き込みます。
ベンダーはこの結果をサイトユーザーとしてのコード実行と評価しています。

攻撃の流れは？

3つの異なる入力が同じ結果に到達します。Checkmk のサイトユーザーとしてファイルが書き込まれ、ベンダーはそれをコード実行と見なします。

flowchart LR A["ルール編集者が除外する
ノードロールを設定"] --> B["ロールが --profile
オプションとして読まれる"] C["悪意あるリモートサイトが
ラベルファイル名を返す"] --> D["パス確認なしで
ラベルディレクトリに
ファイル名を連結"] E["侵害されたホストが
Robotmk テスト名を送信"] --> F["パス確認なしで
テスト名をログの
フォルダーに使用"] B --> G["サイトユーザーとして
ファイルを書き込み"] D --> G F --> G G --> H["サイトユーザーとして
コードを実行"] style D fill:#f8d7da style F fill:#f8d7da

攻撃者に何ができますか？

コード実行に到達した攻撃者は、Checkmk のサイトユーザーとしてコマンドを実行します。このアカウントは、監視設定、Checkmk が監視対象機器に接続するための認証情報、サイトのファイルを読み取れます。条件は脆弱性ごとに異なります。

CVE-2026-121374：攻撃者には、少なくとも1つのフォルダーでルールを編集できるユーザーが必要です。攻撃者がルールを作成するため、サイトが Kubernetes を監視している必要はありません。結果はサイトユーザーとしてのコード実行です。
CVE-2026-118965：攻撃者には、分散構成のリモートサイトの制御が必要です。結果はセントラルサイトへの任意のファイル書き込みと、セントラルサイトのユーザーとしてのコード実行です。
CVE-2026-120495：攻撃者は監視対象ホストの細工したエージェントデータを提供する必要があり、werk によると通常はそのホストの root 権限が必要です。さらに自動サービス検出か、管理者による Robotmk サービスの追加が必要です。結果はサイトユーザーとしてのコード実行です。

サイトユーザーは Checkmk サーバーの root ではありません。それでも監視データと監視対象システム用に保存された認証情報を読めるため、侵害はそれらのシステムの露出としても扱ってください。

修正が機能する理由

修正は、値とオプションの曖昧さをなくし、サイトが書き込むパスを制限します。

Kubernetes の修正は、各ロールを値付きの独立したオプションとして渡し、パーサーはそれを1つずつ追加します。

     match params.cluster_resource_aggregation:
         case None:
-            args.extend(["--cluster-aggregation-exclude-node-roles", "control-plane", "infra"])
+            args.extend(
+                f"--cluster-aggregation-exclude-node-role={role}"
+                for role in ("control-plane", "infra")
+            )
         case ("cluster_aggregation_include_all_nodes", None):
             args.append("--cluster-aggregation-include-all-nodes")
         case ("cluster_aggregation_exclude_node_roles", list(excluded_roles)):
-            args.append("--cluster-aggregation-exclude-node-roles")
-            args.extend(excluded_roles)
+            args.extend(
+                f"--cluster-aggregation-exclude-node-role={role}" for role in excluded_roles
+            )

     group.add_argument(
-        "--cluster-aggregation-exclude-node-roles",
-        nargs="+",
-        default=["control-plane", "infra"],
+        "--cluster-aggregation-exclude-node-role",
+        action="append",
+        default=None,
         dest="roles",
+        metavar="ROLE",
     )

ロールは --cluster-aggregation-exclude-node-role=<role> トークンの一部になったため、argparse はそれを独立したオプションとして読めません。エージェントは --profile を ~/tmp/check_mk/debug に制限し、パスを Python リテラルとしてランチャーに書き込みます。

+def _profile_file(filename: str) -> Path:
+    path = Path(filename).resolve()
+    allowed = (Path.home() / _PROFILE_DIR).resolve()
+    if not path.is_relative_to(allowed):
+        raise argparse.ArgumentTypeError(f"Profiles can only be stored in {allowed}")
+    return path

-                f'stats = pstats.Stats("{self._profile_file}")\n'
+                f"stats = pstats.Stats({str(self._profile_file)!r})\n"

ホストラベルの修正は対象を解決し、ラベルディレクトリの下に留まること、.mk 接尾辞を持つこと、有効なホスト名を語幹に持つことを要求します。

+def _make_secure_path(base: Path, leaf: str) -> Path:
+    path = Path(base).resolve()
+    resolved = (path / leaf).resolve()
+    if not resolved.is_relative_to(path):
+        raise ValueError(f"Path {resolved} is not relative to {path}")
+    if resolved.suffix != ".mk":
+        raise ValueError(f"Path {resolved} does not have .mk suffix")
+    HostName(resolved.stem)  # would raise if validation fails
+    return resolved
+
+
 def save_updated_host_label_files(updated_host_labels: list[UpdatedHostLabelsEntry]) -> None:
     for file_name, mtime, content in updated_host_labels:
-        file_path = cmk.utils.paths.discovered_host_labels_dir / file_name
+        file_path = _make_secure_path(cmk.utils.paths.discovered_host_labels_dir, file_name)

Robotmk の変更は、生成されるログを ~/var/robotmk/html_logs に限定し、その外にログが置かれる場合はサービス状態を UNKNOWN にします。Robotmk の変更は同じ修正版で提供され、その werk が新しいパス規則の公開記録です。

侵害されたかどうかを確認するには？

Checkmk はこれらの脆弱性に関する侵害指標を公開していません。失敗した試行や、サイトが実行しないファイルを書き込んだだけの試行は、ファイル自体以外に痕跡を残さないことがあります。脆弱性が触れる3か所を確認してください。

Kubernetes スペシャルエージェントのルールを追加したり、「Exclude nodes based on their role」を変更したりするルール変更を監査ログで確認します。Web インターフェースで Setup > General > Audit log を開き、Kubernetes ルールセットで絞り込みます。
サイトのデバッグディレクトリに予期しないファイルがないか確認します。 sudo -u <site> find ~/tmp/check_mk/debug -type f -name '*.py' 2>/dev/null
検出済みホストラベルのファイルを一覧し、すべての名前が監視しているホストであることを確認します。 sudo -u <site> ls -la ~/var/check_mk/discovered_host_labels
Pro、Ultimate、Cloud、Ultimate MT のサイトでは、想定されたディレクトリの外にある HTML ログを探します。 sudo -u <site> find ~/var/robotmk/html_logs -type f 2>/dev/null .. を含むパスはリテラルな名前としては存在できないため、親ディレクトリが認識しているテストケースのフォルダーでないファイルを確認します。

ヒットは調査すべき手がかりであり、悪用の証明ではありません。監査ログは、攻撃者のルール変更が記録され、その後ログが改変されていない場合にのみ役立ちます。

年表

2026-10-29：CVE-2026-118965 の修正が Checkmk リポジトリにコミットされました。
2026-11-02：CVE-2026-120495 の修正が werk に記録されました。
2026-11-03：CVE-2026-121374 の修正が Checkmk リポジトリにコミットされました。
2026-11-11：Checkmk が 2.5.0p19 と 2.4.0p40 を公開し、3つの CVE レコードを公開しました。

修正は2026年10月29日から11月11日の間に行われ、修正版が13日間の窓を閉じました — 図1：最初の修正コミットから修正版まで。出典：Checkmk の werk とリリースノート、2026年11月11日確認

よくある質問

Community エディションも影響を受けますか？

CVE-2026-121374 と CVE-2026-118965 については、はい、すべてのエディションに影響します。CVE-2026-120495 は Pro、Ultimate、Cloud、Ultimate MT のみに影響します。Robotmk 合成監視が Community エディションに含まれないためです。修正済みの 2.5.0p19 と 2.4.0p40 パッケージはすべてのエディションに存在します。

Kubernetes を監視していません。1つ目の脆弱性の影響を受けますか？

ルールを編集できるユーザーがいれば、はい。攻撃者が Kubernetes スペシャルエージェントのルールを作成するため、サイトがクラスターを監視している必要はありません。更新するまで、管理以外のロールからルール編集権限を外してください。

バージョン 2.3.0 は修正されていますか？

いいえ。2.3.0 系はサポート終了で、3つの werk は修正版なしの影響ありとして記載しています。これらのサイトを 2.4.0p40 または 2.5.0p19 に移行してください。

実際の悪用は確認されていますか？

2026年11月11日時点で悪用は確認されておらず、3つの CVE はいずれも CISA の KEV カタログにありません。Kubernetes の脆弱性は内部レビューで見つかり、ホストラベルの脆弱性はベンダーのセキュリティ開示プロセスを通じて報告されました。状況は変わり得るため、長期間の延期を計画する前に KEV カタログを確認してください。

更新後に設定を変更する必要がありますか？

いいえ。3つの werk は手動操作不要の互換変更として記載されています。Kubernetes エージェントは新しいロールごとのオプションを受け入れ、ホストラベルと Robotmk のチェックは新しいパス規則を自動的に適用します。

どのエディションを実行しているかはどう確認しますか？

omd version は各サイトのバージョンを表示し、サーバー上のパッケージ名がエディションを示します。たとえば Community は check-mk-raw、Enterprise は check-mk-enterprise です。Web インターフェースでは Help > About にエディションが表示されます。

Ostorlab で公開された Checkmk サーバーを特定する

Ostorlab Attack Surface Discovery を使って、所有するインターネット公開のホストと Web インターフェースを棚卸しし、どの Checkmk サイトに到達でき、どれを先に更新すべきかを把握してください。公開されたサービスを可視化するものであり、この CVE を検出するものではありません。

参考資料

Checkmk werk 17994「Kubernetes: Arbitrary file write and code execution via excluded node roles」、CVE-2026-121374、2026-11-03 付：https://checkmk.com/werk/17994（2026年11月11日確認）
Checkmk werk 22120「Code execution through compromised remote site」、CVE-2026-118965、2026-10-29 付：https://checkmk.com/werk/22120（2026年11月11日確認）
Checkmk werk 22624「Code execution through Robotmk HTML log test service」、CVE-2026-120495、2026-11-02 付：https://checkmk.com/werk/22624（2026年11月11日確認）
CVE-2026-121374 レコード、Checkmk CNA、2026-11-11 公開：https://www.cve.org/CVERecord?id=CVE-2026-121374（2026年11月11日確認）
CVE-2026-118965 レコード、Checkmk CNA、2026-11-11 公開：https://www.cve.org/CVERecord?id=CVE-2026-118965（2026年11月11日確認）
CVE-2026-120495 レコード、Checkmk CNA、2026-11-11 公開：https://www.cve.org/CVERecord?id=CVE-2026-120495（2026年11月11日確認）
CVE-2026-121374 の修正コミット 5a2c448efa、2026-11-03：https://github.com/Checkmk/checkmk/commit/5a2c448efafb1e3f2dab75babdecb5f99d0a0618（2026年11月11日確認）
CVE-2026-118965 の修正コミット 8efcf83a15、2026-10-29：https://github.com/Checkmk/checkmk/commit/8efcf83a153b201ce640a6c1da9de9c52d9c3650（2026年11月11日確認）
CVE-2026-120495 の修正コミット 4ba4c9f638、2026-11-03：https://github.com/Checkmk/checkmk/commit/4ba4c9f638cf83509970e78468f79bf846327d7b（2026年11月11日確認）
Checkmk 2.5.0p19 リリースノート索引、2026年11月11日付：https://checkmk.com/werks?version=2.5.0p19（2026年11月11日確認）
Checkmk 2.4.0p40 リリースノート索引、2026年11月11日付：https://checkmk.com/werks?version=2.4.0p40（2026年11月11日確認）
CISA の Known Exploited Vulnerabilities カタログ、バージョン 2026.11.10、3つの CVE は未登録：https://www.cisa.gov/known-exploited-vulnerabilities-catalog（2026年11月11日確認）
図1、修正からリリースまでの年表：日付は参考資料に記載の3つの werk と2つのリリース索引による、2026年11月11日確認。

ostorlab/KEV オープンソース

# 無料のオープンソース：このような既知の悪用された脆弱性がないか、自分のホストをスキャンしましょう。

$ pip install -U ostorlab
$ git clone https://github.com/Ostorlab/KEV && cd KEV
$ ostorlab scan run --install -g agent_group.yaml domain-name example.com

Ostorlab KEVは無料のオープンソース（Apache-2.0）です。1つのコマンドで、CISA KEVカタログ、Google Tsunami、バグバウンティプログラム由来の脆弱性を対象に、Nuclei、Tsunami、Nmap、Asteroid、Metasploitの検出器を実行します。

github.com/Ostorlab/KEV

タグ：

security, CVE, Checkmk, RCE, vulnerability

要点