Puppet・OpenVox ― サーバーでのコード実行とノードなりすましの脆弱性を修正

要点

影響を受けるもの

Puppet Enterprise 2023.8.13・2025.12.1・2026.0.1 より前（Puppet）。
Puppet Core 9.1.3・8.22.1 より前（Puppet Core 9.1.3 リリースノート）。
OpenVox（オープンソース版Puppetのフォーク）の openvox-server・openvoxdb 9.1.0 以前と 8.17.0 以前（Vox Pupuli）。
Vox Pupuliは「既知のすべてのPuppet実装が影響を受ける」としている。

今すぐやること

Puppetサーバーを修正版に上げ、サーバーを再起動して修正済みのコードを読み込ませる。
証明書の自動署名（autosign）を使っているなら、無効にするか条件を厳しくする。
Puppetサーバーに接続できるネットワークを、必要な範囲に絞る。

何が起きているか

事実（Puppet by Perforce、Vox Pupuli、CVEの記述）

2026年11月3日、Puppet by PerforceとOpenVoxプロジェクトが足並みをそろえて修正版を公開した。2件はNeodymeの研究者が10月中旬にOpenVoxへ報告したもので、Perforceの修正版公開に合わせて11月3日を公表日にした（Vox Pupuli）。

CVE	内容	CVSS 4.0（Perforce）	攻撃に必要なもの
CVE-2026-115731	エージェントが送る実行レポートの逆シリアライズで、Puppetサーバー上で任意のコードが実行される	9.4	CAが署名した任意のエージェント証明書
CVE-2026-115732	証明書名の照合の不備で、別のノードとして認可される	9.0	認可された名前を延ばした・縮めた名前の署名済み証明書

CVE-2026-115731：CVEの記述によると、署名済みのエージェント証明書を持つクライアントが、細工したデータ型を含むレポートをPUTで送ると、Puppetサーバーのサービスユーザーの権限で任意のコードを実行できる。CAが十分な確認なしに証明書を自動署名する設定なら、認証されていないネットワーク上の攻撃者でも証明書を得られる（OpenCVEに転載されたCVEの記述）。Red HatはCVSS 3.1で9.9と評価している。
CVE-2026-115732：アクセス制御ライブラリ trapperkeeper-authorization が、auth.conf の通常の名前のルールにもワイルドカードのような照合をしていた。このため、例えば evil.target.example.com の証明書で target.example.com になりすまし、そのノード向けのカタログ（配布される設定。秘密情報を含むことがある）を取得したり、偽の情報を送ったりできる（OpenVoxの勧告）。CVEの記述によると、Puppet Enterpriseでは、さらに認証局（CA）の管理機能に届き、管理下のノードでコマンドを実行できる。
OpenVoxの勧告は、自動署名は既定では無効だが「実環境ではよく使われている」としている。
同時に、OpenVoxDBのコンテナイメージで、証明書の許可リストが効かず任意の証明書でAPIに接続できた問題も修正された（Vox Pupuli）。
2026年11月4日までのCISAのKEV追加の発表に、この2件は含まれていない。公開の攻撃コードや悪用の報告も見当たらない。

影響を受ける製品・バージョン

製品	修正版
Puppet Enterprise	2023.8.13、2025.12.1、2026.0.1
Puppet Core	8.22.1、9.1.3
OpenVox（openvox-server、openvoxdb）	8.18.0、9.2.0
OpenVox（openvox-agent）	8.32.0、9.3.0
OpenVoxDBコンテナ	タグ 8.18.0 以降、または `latest`

Vox Pupuliによると、オープンソース版のPuppetには今後、セキュリティ修正を含む更新が出ない。同プロジェクトはOpenVoxへの移行を勧めている。
Puppet Enterpriseの今回の更新では、失効したeMudhraの中間認証局も同梱の信頼ストアから外された（Puppet）。

修正版・回避策

修正：上の表の版に更新する。CVE-2026-115731の修正はサーバー側で読み込まれるため、更新後にPuppetサーバーを再起動する（CVEの解決策の記述）。
回避策（Vox Pupuliが挙げるもの。リスクを消すものではないと明記）：
- Puppetサーバーに届くネットワークを、必要なセグメントだけに絞る。
- 自動署名を無効にするか、検証付きの仕組みで条件を厳しくする。
- サーバーを置かない構成では、個々のノードからOpenVoxDBへのアクセスを止める。
- 古い版向けに単体のパッチ適用スクリプトも公開されている。

今すぐやること

Puppet Enterprise、Puppet Core、OpenVoxのどれを、どの版で使っているか確認する。
修正版に上げ、Puppetサーバーを再起動する。
auth.conf に独自のルールを書いている場合は、更新後に意図どおり動くか確かめる。Vox Pupuliは、不具合の挙動に頼っていたルールは書き直しが必要になる場合があるとしている。
自動署名の設定（autosign.conf など）を見直し、誰でも証明書を得られる状態になっていないか確認する。
自動署名を有効にしていた環境では、身に覚えのない証明書が発行されていないか、CAの署名済み証明書の一覧を確認する。

考察

構成管理サーバーは「全台の鍵」: Puppetサーバーは管理下の全マシンに設定を配る。そこでコードを実行されれば、配布する設定を通じて社内のサーバー群にまで影響が広がりうると考える。悪用の報告はまだないが、優先度は高い。
自動署名が前提条件を消してしまう: どちらの脆弱性も「署名済み証明書」が必要だが、自動署名を緩く使っている環境では、その前提が実質的に無いのと同じになる。今回の更新とあわせて、証明書の発行手順そのものを見直す機会にしたい。
カタログに含まれる秘密情報: なりすましで取得できるカタログには、パスワードやAPIキーが埋め込まれていることがある。自動署名を有効にしていた環境では、念のためカタログで配っている秘密情報の入れ替えも検討したほうがよいと考える。
オープンソース版Puppetを使い続けている環境: 更新が出ないとされる以上、OpenVoxへの移行かPuppet Coreへの切り替えを決めるきっかけになる。

出典

原文をGitHubで読む ↗