Takumi's Daily LogEN

OpenClawの権限昇格脆弱性（CVE-2026-33579）を分かりやすく解説する

背景: 自分の判断が正しかった話

OpenClawの導入を検討していたが、「セキュリティ的にまだ早い」と判断して見送った。その翌日、Hacker Newsのトップに権限昇格の脆弱性（CVE-2026-33579）が上がっていた。CVSS 8.6 HIGH。見送って正解だった。

せっかくなので、この脆弱性が何なのか、なぜ危険なのかを整理する。

ホテルで例える

この脆弱性を理解するには、ホテルをイメージすると分かりやすい。

登場人物

| 役割 | システム上の概念 | |------|------------------| | ホテルのフロント | OpenClawの認可システム | | 宿泊客 | 一般ユーザー（pairing権限のみ） | | スイートルームの鍵 | admin権限 | | 新しいゲストの入館申請 | デバイスペアリングリクエスト |

正常なフロー

  1. 新しいゲストが「スイートルームに泊まりたい」と申請する
  2. フロントが申請を受け付ける
  3. マネージャー（admin権限を持つ人） が申請を確認し、承認する
  4. ゲストにスイートルームの鍵が渡される

脆弱性があるフロー

  1. 新しいゲストが「スイートルームに泊まりたい」と申請する
  2. フロントが申請を受け付ける
  3. 一般の宿泊客 が /pair approve を実行する
  4. フロントは「この人は承認する権限があるか？」を 確認しない
  5. ゲストにスイートルームの鍵が渡されてしまう

問題は、フロントが「承認者の権限」をチェックしていなかったこと。

技術的に何が起きていたか

OpenClawのデバイスペアリング機能では、新しいデバイスがシステムに参加する際に「承認」が必要になる。

デバイスA → 「admin権限でペアリングしたい」→ リクエスト送信
ユーザーB → `/pair approve` → リクエスト承認

このとき、ユーザーBが本当にadmin権限を持っているかの検証（スコープ検証）が抜けていた。

具体的には2つのファイルに問題があった:

入口（index.ts）で呼び出し元のスコープ（権限範囲）を取得していたが、コア部分（device-pairing.ts）に 渡していなかった。コア部分は「誰が承認したか」を知らないまま、リクエストを承認してしまう。

index.ts: 「ユーザーBはpairing権限だけ持ってるな」 → ここで止まるべき
device-pairing.ts: 「承認リクエストが来た。OK、承認！」 → スコープを見ていない

なぜCVSS 8.6なのか

| 評価項目 | 値 | 意味 | |----------|-----|------| | Attack Vector | Network | リモートから攻撃可能 | | Attack Complexity | Low | 特別な条件不要 | | Privileges Required | Low | 最低限の権限（pairing）があれば実行可能 | | User Interaction | None | 被害者の操作不要 | | Confidentiality Impact | High | admin権限で機密情報にアクセス可能 | | Integrity Impact | High | admin権限でデータ改ざん可能 |

攻撃の難易度が低く、影響が大きい。典型的な「簡単に悪用できて、被害が深刻」なパターン。

CWE-863: Incorrect Authorization

この脆弱性は CWE-863（不適切な認可）に分類される。認証（Authentication: 誰であるか）はできているが、認可（Authorization: 何をして良いか）が正しく実装されていない。

よくある間違い:

教訓

  1. 権限チェックは処理の入口だけでなく、コアロジックでも行う — 入口で取得した情報がコアに渡されていなければ意味がない
  2. 「取得」と「検証」は別 — スコープを取得していても、それを使って判定しなければ無防備と同じ
  3. 新しいツールの導入前にセキュリティアドバイザリを確認する — GitHubのSecurity Advisoriesタブ、NVDのCVE検索は習慣にすべき

直感的に「まだ早い」と感じた判断が、CVEによって裏付けられた。セキュリティの勘は、こうした事例の積み重ねで磨かれていく。