何が起きたか・対象

Umbraco CMSで、Usersセクションへアクセスできる非管理者のAPI利用者が、自分を管理者グループへ追加できる問題がありました。識別子はGHSL-2026-065、CVE-2026-31834です。

攻撃者は一括変更APIへ自分の利用者IDと管理者グループのIDを送ります。APIはその利用者を編集してよいかを確認しますが、そのグループを付与してよいかは確認せず、所属変更を保存していました。グループに結び付いた管理者権限が自分にも与えられるため、対象利用者の編集許可だけでは防げません。認証とUsers権限などが必要で、全ての外部利用者が無条件に使える問題ではありません。 Usersへのアクセスだけで全対象を編集できるという意味ではなく、攻撃対象である自分の利用者情報の編集確認も通る構成が必要です。グループは権限のまとまりで、所属を保存するサーバーの処理が管理者グループへ追加すると、その権限が適用されます。

報告・修正・公開の時系列

17.2.0で検証され、2026-02-25に報告、02-26に重複報告と確認されました。03-10に16.5.1、17.2.2で修正され、開発元が公表しています。研究記事の公開は09-21です。

正常ならどう動くはずだったか

ユーザーの情報を変更できる人でも、自由に強い権限を付与してよいとは限りません。グループは権限をまとめる仕組みなので、対象ユーザーの編集許可と、指定グループの付与許可を別に確認する必要があります。 例えば呼び出し元が管理者グループを付与する権限を持たなければ、対象が自分で編集可能でも、そのグループへの追加は拒否します。

技術的な原因

一括変更APIは、指定された利用者を呼び出し元が編集できるかを確認しますが、その利用者へ指定のグループを付与してよいかを確認していませんでした。単体の利用者編集で使うUserEditorAuthorizationHelperの検査を通さず、UserGroupServiceへグループ変更を渡していたためです。自分の利用者情報を編集できることが、管理者権限を自分へ付与できることに変わってしまいます。

攻撃が成立する条件と流れ

Usersセクションへアクセスできる、認証済みの非管理者API利用者が必要です。攻撃者は一括変更APIへのHTTPリクエストに自分の利用者IDと管理者グループのIDを指定します。対象利用者の編集確認だけを通ると、サーバーが自分を管理者グループへ追加します。ログインしていない外部の人が無条件に使える問題とは区別します。 Usersへのアクセス許可と、対象利用者を編集できるという検査の両方を満たすことを確認します。前者だけを全構成での十分条件とは扱いません。

確認された事実と、想定される影響

研究が示すのは、条件を満たす非管理者がCMSの管理者権限を得る経路です。管理者権限で許可される機能の影響例として、公開記事を偽の案内へ編集する、別の管理者アカウントを追加して後からログインする、CMSの設定を変更することが考えられます。いずれも管理者向け機能への認可と実際の構成に従い、OSの管理者権限を得たという意味ではありません。既定ではUsers権限を持つ人が既に管理者である場合もあり、全利用者が昇格できるわけではありません。実悪用は未確認です。

実際の修正・対応方針

開発元・研究資料は16.5.1と17.2.2での修正を案内しています。各コミットの詳細はここでは直接確認していません。一般的には、一括APIにも付与する権限の認可を適用して、単体APIとの差をなくします。

利用者・運用者が確認すること

利用系列の修正済みサポート版へ更新し、Users権限を持つAPIユーザーとグループ変更履歴を確認します。画面から操作できなくても、管理APIが同じ操作を拒否するか確認します。

開発者への教訓（教材としての考察）

認可では「誰を編集するか」「何をするか」に加えて「どの権限を付けるか」も確認します。強い権限を与えるAPIは、対象編集の認可だけでは守れません。

出典・確認範囲

  1. [1] Unauthorized group assignment enables privilege escalation in Umbraco CMSGitHub Security Lab / 確認日 2026-10-29
  2. [2] Vertical Privilege Escalation via Missing Authorization ChecksUmbraco / 確認日 2026-10-29
未確認事項・限界

修正コミットの詳細と実悪用の有無は確認できません。