世界を動かす技術を、日本語で。

Googleで発見した90,000ドルのリモートコード実行脆弱性

2026年10月12日原文(simonkoeck.com)

概要

  • Google の開発者ドキュメントサイトで 深刻な脆弱性 を発見
  • FlaskセッションCookie にOAuthクライアント情報と署名鍵が含まれていた
  • Cookie改ざんによる 任意コード実行(RCE) が可能
  • 脆弱性の修正策と 報奨金$90,000 の授与
  • 脆弱性の影響範囲と 技術的な詳細 の解説

Google開発者ドキュメントサイトのOAuthフローで発見した脆弱性

  • Google Developers サイトのOAuthフロー調査中に /oauth2authorize へのアクセスを確認
    • セッションCookieが発行され、Googleのサインインページへリダイレクト
  • curlコマンド でCookieを取得し、内容を調査
    • Cookieは Flask形式(session=<payload>.<timestamp>.<signature>)
    • サイズが約1,200バイトと大きく、内容に疑問
  • FlaskセッションCookieは 署名のみで暗号化されていない ため、内容の解析が可能
    • 先頭のドットは zlib圧縮 を示す
    • base64デコード・zlib解凍で中身を取得
  • Cookie内容例
    • _permanent: True
    • google_oauth2_csrf_token: CSRFトークン
    • google_oauth2_flow_<csrf>: バイト列(Flaskがbytes型をbase64化)
  • バイト列をデコードすると pickle 形式
    • oauth2client.client.OAuth2WebServerFlow オブジェクトが含まれ、 client_idとclient_secret が平文で格納
  • Flask SECRET_KEY としてこのclient_secretが使われており、Cookie署名の検証にも利用
    • 署名検証ロジックを再現し、完全一致を確認

セッション改ざんと任意コード実行への流れ

  • FlaskサーバはセッションCookieを受け取ると
    • 署名検証
    • google_oauth2_flow_<csrf> をbase64デコード
    • pickle.loads でオブジェクト復元
  • 署名鍵が漏洩したことで、 攻撃者が任意のセッション内容を作成可能
    • 自作pickleペイロードをセッションに埋め込むことで 任意コード実行 が成立
  • 実証例として time.sleep(N) を実行するpickleを作成
    • サーバ応答時間がN秒だけ遅延し、実行を裏付け
  • 検証パターン
    • Cookieなし:エラー
    • 署名改ざん:エラー
    • flowエントリなし:エラー
    • 正常flow:トークン交換で失敗
    • sleepペイロード:応答遅延で実行確認

影響範囲と修正策

  • developers.google.com 以外にも同じ署名鍵が利用されていた
    • firebase.google.com
    • developer.android.com
    • source.android.com
    • docs.partner.android.com
  • 修正案
    • 漏洩したOAuthクライアントシークレットの ローテーション と既存セッションの無効化
    • Flask SECRET_KEY をOAuth認証情報と分離し、サーバ側で安全に管理
    • OAuthフローオブジェクトを サーバ側に保持 し、Cookieには参照IDのみ格納
    • pickle の利用禁止、スキーマ検証付きのデータ専用フォーマットへ移行

報告と対応の経緯

  • 2026年8月6日 脆弱性報告
  • 8月7日 トリアージ・受理
  • 8月27日 報奨金$90,000決定(通常$75,000+報告品質ボーナス)
  • 10月7日 修正完了
  • Google Bug HuntersチームとDevSiteエンジニアによる迅速な対応に謝意

Hackerたちの意見

「I」を繰り返し使うのは大胆な選択だね。「Claude」じゃなくて「I」って、結局このブログ記事を書いたのはClaudeなのに。ああ、もしかして「Claude」を「I」に置き換えたのは、Claudeが一人称視点でこのブログを書いたからかな。

└

LLMはツールだよ。俺もClaudeにアクセスできたけど、バグは見つけられなかった。著者が見つけたんだ。リサーチのセンスとか、他にも人間を差別化する能力はまだまだあるよ。実際、AIによって他の制約要因が排除されることで、そういう能力がもっと重要になると思う。醜いヘッジファンドマネージャーがよりパフォーマンスを上げるのと同じメカニズムだね。問題は、トップパフォーマーの構成が変わること。トップパフォーマー(「アーティスト」、「研究者」、「ライター」など)でいることは、しばしば自分を守るために作り上げたアイデンティティだから、そこが問題なんだ。「決して壊れない強い自分」や「常に確信を持っている賢い自分」っていうマスクが、最終的には変わることを妨げる檻になってしまうこともあるから。

└

こういうことにClaudeを使うのに、どれだけの努力と前知識が必要かを過小評価してるよ。

└

こういう浅い否定は、議論に何の貢献もしないね。

└

見落としたかもしれないけど、ブログ記事にはClaudeのことが書かれてないみたい?著者はClaudeを使ったって言ってた?それと、Claudeがそんなバグを見つけるためのプロンプトに応じるかどうかも気になるな。誰か試したことある?

└

もし彼が古いソースコードスキャナーを使ったら、クレジットは彼に行くの?それともツールに?だってClaudeはツールであって、人間じゃないからね。 ;)

└

次回は石板から手で1と0を彫り込むことができるかもね。技術を正しく使わない人や、_本物_のコーダーがやるようなやり方についての愚痴は、いつも同じで飽き飽きだよ。

└

Googleからの$90kの報酬を得るのは難しいよね。Claudeを使ってもそうだし、それを軽視するべきじゃないけど、LLMの声だけで書かれた記事を読むのはちょっとイライラする。

└

クライアントにLLMへのアクセスを渡すと、初心者レベルのコードが簡単に手に入る。同じく初心者レベルのエクスプロイトもね。Googleに対するRCEは「初心者レベルのエクスプロイト」じゃないよ。AIが生成したコードを見たことがあるなら、AIが生成したセキュリティの発見も「初心者」っぽい匂いがするって言える。何をしているか分かっている専門家が、正しい場所を見つけるように導かないといけないし、専門家が好む方法を使う必要がある。

└

これは、このサイトでコメントをブロックできないのが残念な理由の明確な例だね。

└

もしこの主張をするなら、せめてClaudeじゃなくてGLM 5.3って言ってよ。Claudeは、特別なクラブに入ってない限り、こういうことには絶対手を出さないから。

バグバウンティハンターを目指している人にアドバイスはある?こういう脆弱性を見つけるための方法とか、過去の経験がたくさんあるの?

Hacker Newsで議論の続きを見る