GLPI のテンプレート注入 RCE：管理者権限が root と等しいべきでない理由

GLPI は広く使われているオープンソースの IT 資産管理ソフトウェアです。CVE-2026-26026 は 11.0.0 から 11.0.5 に影響し、11.0.6 で修正済み、CVSS 9.1 で critical 判定。報告は 2026 年 4 月 6 日です。

一行で言えば、認証済みの管理者がテンプレート注入を通じてサーバ上の任意コード実行に到達する。

攻撃チェーンの形

公開された分析によれば：

1. 攻撃者が GLPI の管理者権限を取得する（弱い資格情報、クレデンシャルスタッフィング、あるいは単なる内部者）
2. テンプレートの変更が許された画面へ移動する
3. 注入ペイロードを含むテンプレートを作成して保存する
4. GLPI がテンプレートを描画する際に注入されたコードを実行する
5. サーバ上の任意コマンド実行を得て、リバースシェルで永続化する
6. 横展開するか、データを持ち出す

本当に議論すべき点

技術的な詳細 —— どのテンプレートエンジンか、注入点はどこか —— は、このソフトウェアを運用する人にとって行動価値がありません。パッチは出ています。アップグレードしてください。立ち止まる価値があるのは、手順 3 と 4 の間に横たわる前提です。

なぜ「テンプレートを編集できる」が「サーバ上でコマンドを実行できる」を意味するのか。

テンプレートエンジンは非プログラマが画面を変えられるように存在します。その暗黙の約束は「ここで編集したものはページの見た目にしか影響しない」です。テンプレートが任意のコードを呼べる瞬間、その約束は無効になります —— そしてこの脆弱性はまさに「画面の編集」から「コード実行」へ直結する配線です。

権限モデルはさらに悪化させます。GLPI の管理者が管理するのは資産、ユーザー、チケット —— すべてアプリケーション層のものです。このチェーンはアプリケーション層の権限をオペレーティングシステム層の権限へ直接変換します。その間に「その人が本当にサーバアクセスを必要としているか」を問う手順はありません。

GLPI 固有の問題ではない

同じ前提は至る所にあります。

• 管理画面の「カスタムスクリプト」「コードスニペット」欄
• レポートやメールのテンプレートで許された式言語
• 拡張を入れることがコードを入れることになるプラグイン機構
• CI の設定ファイルさえ —— パイプラインを編集できる者は runner 上でコマンドを実行できる

共通する形はこうです。設定として扱われているが、実体はチューリング完全な実行入口であり、権限は設定であるかのように設計されている。

防御側にできること

GLPI を運用しているなら：

1. 11.0.6 以降へアップグレードする。 実際に解決する唯一の行動です。
2. 管理者が誰かを把握する。 認証済み管理者が必要なので、管理者が少なく、発行が統制されているほどリスクは下がります。
3. GLPI を制約された環境で動かす。 コンテナ、読み取り専用ファイルシステム、明示的な外向き通信ポリシー。テンプレートが実行されても、届く範囲は限られます。

三番目はこの種の脆弱性への一般的な答えです。アプリケーション層に注入が決して無いことを保証はできませんが、「注入されてもマシン全体を渡さない」ことは保証できます。

私の結論

9.1 の一部は「高い権限が必要」という前提を割り引いた結果です。私はその割引は誤りだと考えます。多くの組織で管理者アカウントは共有され、外部委託され、退職者のまま残っています。 それを強い前提として扱うのは、ほとんどの組織が持たない運用規律を仮定することです。

テンプレートエンジンがコードを実行できるかどうかは、明示的で、文書化され、切り替え可能な選択であるべきで、既定で有効な副作用であるべきではありません。「管理画面で編集できる何か」が最終的にコードを実行する製品は、権限画面でそれを明記すべきです。ユーザーが「テンプレートを保存」を押すとき、頭にあるのは「色を変えた」だけなのですから。