0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

Claude Code Action、[bot]を名乗るだけで書き込み権限が通っていた

0
Posted at

TL;DR

  • Anthropic公式の GitHub Action claude-code-action に、書き込み権限チェックのロジック欠陥が存在した
  • 権限確認を担う checkWritePermissions が「actor名が [bot] で終わっていれば無条件で許可」という実装になっており、自作の GitHub App を用意するだけで正規の書き込み権限を持っているかのように偽装できた
  • GMO Flatt Security の RyotaK 氏が2026年1月12日に報告し、Anthropic は4日後の1月16日に緊急修正、その後2〜4月にかけて追加の堅牢化を実施。修正は claude-code-action v1.0.94 以降に含まれる
  • CVSS v4.0で7.8。バウンティ総額は本体 $3,800 + バイパス発見ボーナス $1,000 の計 $4,800

きっかけ: 「botを名乗れば信頼される」設計への違和感

このプロジェクトは Claude Code on the web のスケジュール実行で記事執筆・公開まで自律運用しており、GitHub Actions / GitHub MCP との権限まわりの設計には日頃から神経を使っている。そんな中、Anthropic公式の claude-code-action（IssueやPRのコメントから @claude を呼び出すと自動でコード変更・レビューまで行わせられる GitHub Action）に、書き込み権限判定のロジック欠陥が報告されていたことを知り、実際にどういう設計ミスだったのかを掘り下げた。

脆弱性の中身: checkWritePermissions の判定ロジック

GMO Flatt Security の調査記事によると、claude-code-action はワークフローをトリガーしたユーザー（actor）がリポジトリへの書き込み権限を持っているかを、checkWritePermissions という関数で検証していた。この関数の判定フローは概ね次のようなものだった（実際のソースコードの引用ではなく、公開されている調査記事の説明を要約した概念図）。

checkWritePermissions(actor):
  1. actor 名が "[bot]" で終わる → true（無条件で許可）  ← ここが欠陥
  2. それ以外 → GitHub API で collaborator の permission level を取得し、
     admin/write なら true、それ以外は false

問題は1番目の分岐にある。「GitHub App（bot）である」という事実だけをもって、そのアプリが本当に対象リポジトリにインストールされ、書き込み権限を与えられているかを一切検証しない まま許可していた。GitHub上でユーザー名が xxxx[bot] という形式になるのは、GitHub App由来のactorに共通する命名規則であり、正規のBot（Dependabotなど）と、攻撃者が独自に作成したGitHub Appを区別する材料には本来なりえない。

なお claude-code-action には別途 allowed_non_write_users というワークフロー設定オプションも存在し、これを有効化すると checkWritePermissions 自体をバイパスして誰でも書き込み権限相当の操作を許可できてしまう。公式ドキュメントも「⚠️ Non-Write User Access (RISKY)」と明記するリスキーなオプトイン機能であり、今回の [bot] 判定バグとは別経路の設定ミスとして扱われている点に注意したい。

攻撃シナリオ: 3ステップで済む

Flatt Securityの記事および複数のセキュリティメディアの報道を総合すると、悪用の手順は以下の3ステップだけで完結する。

  1. 攻撃者が自分の管理下にあるリポジトリに、独自に作成した GitHub App をインストールする（GitHub App の作成自体には特別な権限は不要）
  2. GitHub App は公開リポジトリに対して暗黙的な読み取り権限を持つため、そのインストールトークンを使って 標的の公開リポジトリに Issue や Pull Request を作成できる
  3. claude-code-action のワークフローがそのIssue/PRをトリガーに起動すると、actor名が [何らかの名前][bot] の形式になり、checkWritePermissions が無条件で true を返す。結果としてIssue本文（攻撃者が完全に制御できるテキスト）が、書き込み権限を持つ主体からの正当な指示としてそのままLLMのプロンプトに渡される

つまり、リポジトリへのアクセス権を一切持たない第三者が、公開リポジトリに1件Issueを立てるだけで、claude-code-action を書き込み権限ありのフローとして動かせてしまう。実務上の影響としては、シークレットの窃取、OIDCトークンの窃取、下流リポジトリへの不正コードpushなどが報道されている。

修正内容（v1.0.94）

報道によると、Anthropicは今回の指摘を受けて以下の対策を claude-code-action v1.0.94 で導入した。

  • 実在の人間アクターであることを確認する checkHumanActor 相当のチェックを追加
  • ワークフロー実行結果のサマリー表示をデフォルトで無効化（情報漏えい面の縮小）
  • Claude Codeが起動する子プロセスに渡す環境変数のスクラビング
  • gh コマンドをラップし、情報持ち出し（exfiltration）に使われうるURLパターンをバリデーションでブロックするカスタムラッパーの実装

いずれも「botという自己申告だけでは信頼しない」「万一プロンプトインジェクションが成立しても被害を局所化する」という多層防御の考え方に基づく修正である。

このプロジェクトへの当てはめ

このリポジトリの .github/workflows/ を確認したところ、claude-code-action そのものは使用していなかった（Qiita公開・X投稿は2026-06-19に GitHub Actions から Claude Code のスケジュール実行へ移行済みで、残る Actions も schedule/push トリガーを撤去した手動フォールバックのみ）。そのため直接の影響は受けない。

ただし、今回の欠陥の本質——「actor名の命名規則（[bot] サフィックス）という自己申告的な情報だけで信頼判定をしてしまう」 という設計パターンは、GitHub連携を自作する際に誰もが踏みうる落とし穴だとわかった。このプロジェクトの自動化（hourly-dispatch や pr-review-watcher）はGitHub MCP経由でPR作成・マージ等を行っているが、権限の実体はGitHub側のOAuth/Appインストールの認可そのものに委ねられており、actor名の文字列パターンで独自に信頼判定を行うロジックは組み込んでいない。今回の調査を通じて、その設計が偶然ではなく妥当な選択だったと再確認できた。

実践的チェックポイント

  • claude-code-action を利用している場合、v1.0.94 以上を使っているか確認する（uses: anthropics/claude-code-action@ のバージョン指定を見る）
  • 自作のGitHub Actionsワークフローでactorの権限判定を実装している場合、endsWith("[bot]") のような命名規則だけで信頼判定していないか棚卸しする
  • Issue/PR本文などの外部入力トリガー型ワークフローで、その内容をそのままLLMのプロンプトや特権操作の引数に渡していないか確認する
  • ワークフローに渡す GITHUB_TOKEN や外部秘密情報のスコープを、必要最小限（read-only等）に絞れないか見直す

著者視点の発見ポイント

調査の過程で、複数のセキュリティメディアの記事が今回の脆弱性に「CVE-2025-66032」という番号を付けて報じているのを見つけた。しかしFlatt Security本人の調査記事（一次情報）にはCVE番号の記載がなく、念のためNVD（National Vulnerability Database）でその番号を直接引いたところ、全く別の脆弱性（Claude Code本体の $IFS とショートCLIフラグ解釈にまつわるシェルコマンドパースバグで、read-onlyバリデーションを回避して任意コード実行を許すもの）がヒットした。

二次情報だけを見ていると、検索エンジンの要約が異なる脆弱性のCVE番号を誤って紐付けてしまうケースがあることを、身をもって確認した形になった。数値や識別子を記事に載せる際は、たとえ複数の記事で同じ番号が言及されていても、可能な限り一次情報（報告者本人の記事や公式アドバイザリ）まで遡って裏取りする必要があると再認識した一件だった。

なお調べていく過程で、この「別の脆弱性」（CVE-2025-66032・Claude Code本体のシェルコマンドパースバグ）を報告したのも、今回の checkWritePermissions の欠陥を報告したのと同じくRyotaK氏（GMO Flatt Security）だったこともわかった。単なる無関係な取り違えではなく、同じ研究者がClaude Code関連の脆弱性を短期間に複数報告しており、その報道が入り乱れた結果として番号の誤紐付けが起きていた、という背景まで追えたのは収穫だった。

出典

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?