Puppet Serverの任意コード実行と認可回避を修正｜受付先ごとに更新を確認

Puppet Serverを運用しているなら、管理ネットワークに閉じている環境も更新対象に入れてください。Perforceが米国側の日付で2026年11月3日（日本時間4日早朝）に公開したCVEレコードによると、対象版ではCAが署名したエージェント証明書を持つクライアントが、細工した実行レポートを送り、Puppet Serverのサービスユーザーとして任意コードを実行できます。Puppet Enterprise（PE）は系列に応じて2023.8.13、2025.12.1、2026.0.1に更新し、修正コードを読み込ませるためにPuppet Serverを再起動します。

同じ修正版には、証明書名の照合に起因する別の認可回避も含まれます。運用担当者が最初に確認するのは、実行レポートを受けるサーバーの版、そこへ接続できるノード、証明書の発行条件です。インターネット非公開でも、侵害された管理対象ノードから制御側へ届く経路があれば、優先度は下がりません。

エージェントの報告がサーバー側で実行に変わる条件

Puppetは、サーバーから設定カタログを渡すだけでなく、エージェントから実行結果を受け取ります。PuppetのレポートAPI仕様によると、通常の送信には PUT /puppet/v3/report/:nodename?environment=:environment を使い、受信した報告を設定済みの処理機構に渡します。構成によってはPuppetDBにも保存されます。監視で見ているPuppetDBの検索APIと、今回の入力を受けるPuppet Server側の受付は別の経路です。

PerforceのCVE-2026-115731公式レコードによると、CVE-2026-115731ではレポート内の細工した型を復元する処理が問題です。署名済みのエージェント証明書を持つクライアントからサーバーへ到達できる場合、レポート受信がコード実行の入口になります。Perforceの評価はCVSS 4.0で9.4（Critical）です。コードの実行主体はPuppet Serverのサービスユーザーとされており、root権限を直接取得するとの説明ではありません。実際に読み書きできるファイルや接続先は、そのサービスの権限と配置に依存します。

証明書なしのクライアントが常に送信できるわけではありません。ただし、CAが十分な検証をせず証明書要求を自動承認していると、未認証のネットワーク上の攻撃者も署名済み証明書を取得できるとPerforceは説明しています。入口での証明書確認が有効でも、発行手続きが弱ければ前提条件を満たされます。逆に手動承認にしていても、すでに発行済みの証明書やその秘密鍵が侵害された場合の問題は残ります。今回確認した一次資料は、実環境での悪用の有無を明らかにしていません。

証明書名の部分一致は別の認可回避

PerforceのCVE-2026-115732公式レコードが説明するCVE-2026-115732は、Puppet Serverで使用される認可ライブラリの問題です。認可済みのホスト名より長い、または短い名前を持つ署名済み証明書が、そのホストとして認可されることがあります。攻撃には名前が衝突する証明書をCAが発行している必要があり、手動承認でも自動署名でも条件を満たし得ます。

Perforceは、この不備で他のノードへのなりすましが可能となり、PEではCA管理へのアクセスや、管理対象ノードでのリモートコマンド実行にもつながり得るとしています。こちらの評価はCVSS 4.0で9.0（Critical）です。前者が報告を受けるサーバー上での実行、後者が証明書名の誤判定による権限の獲得であり、一方を成立させるのにもう一方が必須だとは公表されていません。

更新先はPEの系列ごとに選ぶ

Perforceの両CVEレコードは、次の範囲と修正版を示しています。表はCNAが明示した範囲を整理したもので、表にない旧系列を安全と判定するためには使えません。サポート外の版を運用している場合は、サポート対象への移行経路も確認してください。

PE系列	公表された影響範囲	修正版
2023.8	2023.8.0以上2023.8.13未満	2023.8.13
2025	2025.0.0以上2025.12.1未満	2025.12.1
2026	2026.0.0以上2026.0.1未満	2026.0.1

CVE-2026-115731の対処としてPerforceは、puppet-agent 8.22.2または9.1.3を同梱したPEへ更新し、Puppet Serverを再起動するよう案内しています。ここでのパッケージ名は修正コードを含む部品を指しています。管理対象ホスト側のエージェントだけを更新して、サーバーの更新が済んだとは判断できません。また、PEの製品版とPuppet Coreの版は別の番号です。Puppet Core 9.1.3リリースノートには両CVEの修正が掲載されていますが、PEの更新先はPEの系列から選びます。個別にパッケージを組み合わせて運用している場合は、その配布元とサーバーが読み込むコンポーネントを確認します。

更新前にレポートの受付先と署名の経路を洗い出す

まず、エージェント設定上の接続名と、その名前が実際に転送される先を対応させます。プライマリサーバー、コンパイルサーバー、負荷分散のバックエンド、災害復旧用の待機系を一覧にし、そのうちどのホストがレポートを受けるかを記録します。ロードバランサーの設定だけで判断できない場合は、直近の通常運転でどこに要求が届いたかをアクセスログや既存のメトリクスで照合します。待機系が平時に受付していなくても、切り替え時に旧版を再投入する構成なら更新対象から外せません。

次に、受付先ごとに製品系列、導入済みの版、証明書を発行するCA、接続元のネットワークを記録します。同じPE環境でも、検証系だけが先に更新されていたり、交換用のマシンイメージが古いままだったりすることがあります。構成管理の台帳にある予定版と、実際のホストのパッケージ記録を比較してください。アプリのデプロイ記録は、構成管理サーバー自身の更新証跡にはなりません。

署名については、Puppet公式のCAとSSLの解説を参照し、自動承認の有無だけでなく、承認条件が申請元を信頼できる情報で照合しているかを確認します。たとえば接続元を確認せず申請された名前だけで承認する運用では、その名前を誰が要求できるかが問題になります。外部CAを使う場合は、Puppet側の自動署名設定だけを見て終わらず、外部側の発行規則と、Puppet Serverが受け入れる証明書の範囲も合わせて確認します。

更新までの露出を下げる

修正版を入れるまで時間がかかる場合は、既存の接続要件に沿ってサーバーの受付を必要なネットワークに限定し、十分な検証を伴わない自動署名を停止または厳格化することを検討します。これは本サイトの暫定対応の提案です。すでに有効な署名済み証明書を持つノードからの経路は残るため、更新の代用にはなりません。発行元や管理者が分からない証明書が見つかった場合は、そのノードが現役か、どの処理で使われるかを確かめ、通常の失効手順へ引き継ぎます。

レポートのPUTを全遮断すると、正常な構成反映の結果まで見えなくなる可能性があります。監視で使う報告が止まると、カタログの取得に成功しても、適用時の失敗や未管理状態に気付きにくくなります。ネットワーク制限を変更する場合は、対象となるエージェントと送信元の範囲を事前に突き合わせ、変更後に正常報告が届くことを確認します。アクセス制限や署名条件の変更は適用時刻も残し、後でログを調べるときに境界として使います。

再起動後はホスト単位で更新と通常動作を照合する

更新順序は構成に合ったPuppet Enterprise公式アップグレード手順で確認します。複数ノード構成では、アップグレード中にインフラノードの版差が生じると、エージェント実行や複製に影響する場合があります。保守枠を確保し、バックアップや復旧方法を確認したうえで、製品がサポートする順序で更新してください。古いホストを負荷分散から外す運用では、新しいホストで通常処理を確認してから戻し、未更新のホストがそのまま待機系に残っていないことも確かめます。

各受付先で、導入済みのパッケージ、Puppet Serverの再起動時刻、サービス起動結果の三つを記録します。パッケージの更新だけでは起動済みプロセスが新しいコードを読み込んだ証拠になりません。逆に再起動時刻だけでは正しい版が入ったか分かりません。サービス管理の記録とパッケージ管理の記録を同じホスト名で突き合わせます。構成管理システムのホスト名とロードバランサーの登録名が違う場合は、台帳で対応付けます。

そのうえで、検証用エージェントで通常のカタログ取得と適用を行い、新しい実行レポートが想定した受付先に届くことを確認します。PuppetDBなどへ転送する構成では、送信側の成功に加え、転送先で該当ノードの新しい報告が確認できるところまで見ます。負荷分散名で一度成功しただけでは、すべてのバックエンドの確認にはなりません。通常の要求がどのサーバーに処理されたかをログで結び付け、試験が通っていない受付先を明示します。悪用用のレポートを本番へ送る必要はありません。

たとえば、プライマリと二台のコンパイルサーバーがあり、そのうち二台がレポートを受ける構成なら、各受付先の版と再起動を別々に記録します。検証用ノードの通常実行を一回行って一台に届いた場合、もう一台の判定にはそのログを流用しません。承認済みの保守手順で送り先を切り替えるか、普段の報告を受付先別に確認します。認可を独自設定している場合は、隔離した検証環境で、既知の証明書名には必要な操作が許可され、同名の一部しか一致しないテスト用の名前には意図しない権限が付かないことも確認します。

侵害の調査は更新結果と分けて記録する

修正版の稼働が確認できても、それは過去の不正操作がなかったという意味ではありません。更新前の期間について、CAの発行・承認記録、Puppet Serverやプロキシに残るレポート受付ログ、ホスト側で取得しているプロセスや外向き通信の記録を同じ時刻軸で照合します。普段は接続しないノードからの受付、登録直後の証明書による予想外の通信、似た名前の証明書の承認などは、調査対象を絞る手掛かりになります。アクセスログの成功や失敗だけで悪用を断定できるわけではなく、証明書名が記録されていない構成では送信元や時刻を補助情報として扱います。

管理サーバーで通常見ない子プロセスやファイル変更が見つかった場合は、変更管理の履歴と比較し、該当する時点のログを確保して初動対応へ引き継ぎます。管理対象ノードまで調査する範囲は、当時のサービス権限、CA管理操作、設定の配布記録から判断します。保持期限より古い期間や監視対象外のホストは「記録なし」として残します。「異常を確認できなかった」ことと「観測できなかった」ことを区別すると、追加の証跡を探すべき範囲が明確になります。