Googleの9万ドル相当のバグ：OAuthシークレットの再利用とpickle逆シリアル化

Otark GmbHのソフトウェアエンジニアであるSimon Köck氏は、2026年8月にGoogleのDevSiteインフラストラクチャにおいて、深刻なリモートコード実行の脆弱性を発見しました。この欠陥により、認証されていない攻撃者がdevelopers.google.comおよび関連するドキュメントサイトをホストするサーバー上で任意のコードを実行することが可能でした。Googleはこの問題を最高深刻度レベルであるS0と評価し、Köck氏に9万ドルの報奨金を支払いましたが、修正プログラムの展開には2か月を要しました。

何が起きたか

この脆弱性は、7つのGoogle開発者ドキュメントドメインを支える共有プラットフォームであるDevSiteに存在していました。Köck氏は、アプリケーションが非推奨のoauth2clientライブラリからのシリアライズされたOAuth2WebServerFlowオブジェクトをFlaskセッションクッキー内に保存していることを特定しました。この設定により、意図せずOAuthクライアントシークレットがクッキーデータ内で公開されていました。さらに重大なことに、Googleは同じOAuthクライアントシークレットをFlaskセッションの署名キーとして再利用していました。

シークレットがクッキー内で公開されると同時に、そのクッキーの署名にも使用されていたため、Köck氏はオフラインで署名を再現することができました。これにより、サーバーが無条件に受け入れる有効なセッションクッキーを偽造することが可能になりました。彼は、異なる2つの署名キーに依存していた影響を受けるすべての7つのドメインで、偽造セッションが受け入れられることを実証しました。また、これらのうち3つのホスト（developers.google.com、docs.partner.android.com、web.dev）で概念実証コードの実行に成功しました。

Köck氏は、Pythonのsleepペイロードを送信し、応答遅延を測定することで、認証なしのリモートコード実行を確認しました。実際の損害を防ぐため、ファイル、資格情報、または内部サービスに触れるコマンドの実行は意図的に避けていました。Googleは、通常のアプリケーションティアでのS0リモートコード実行に対して基本報酬7万5千ドルを授与し、彼の報告書の卓越した品質に対して1.2倍の乗数を適用しました。

仕組み

エクスプロイトチェーンは、3つの特定のセキュリティ上の不備が同時に重なることに依存していました。第一に、アプリケーションがクライアント側クッキー内でシークレット値を公開していました。第二に、同じシークレットがセッションの暗号署名キーとして再利用されており、攻撃者が変更されたクッキーに対する有効な署名を作成することを可能にしていました。第三に、アプリケーションがOAuthコールバック処理中にセッションデータを逆シリアル化するためにPythonのpickleモジュールを使用していました。

Pickleは、逆シリアル化中に任意のコードを実行できる可能性があるため、信頼できないデータに対して安全ではないことが知られています。Köck氏は、クッキー内の正当なフローオブジェクトを悪意のあるpickleペイロードに置き換え、公開されたシークレットで署名することで、サーバーがセッションを処理する際に自分のコードを実行するように強制しました。これらの3つの問題のうちいずれか一つでも修正すれば—シークレットを隠すこと、別の署名キーを使用すること、またはpickleを避けること—攻撃チェーンは破綻していました。

主要な詳細

• 影響を受けたシステム: developers.google.com、docs.partner.android.com、web.devを含む7つのGoogle開発者ドキュメントドメイン。
• 脆弱性のタイプ: 安全でない逆シリアル化とキーの再利用による認証なしのリモートコード実行。
• 根本原因: OAuthクライアントシークレットのFlaskセッション署名キーとしての再利用と、セッションデータへのPython pickleの使用。
• 深刻度: GoogleによってS0と評価され、これは彼らの深刻度スケールでの最高レベルです。
• 報奨金: 研究者Simon Köck氏に9万ドルが支払われました。
• 修復期間: 2026年8月6日に報告；2026年10月7日に修正プログラムを展開。

なぜ重要なのか

エンジニアリングチームにとって、この事件は暗号キーの再利用とレガシーライブラリの依存関係の危険性を浮き彫りにします。認証やセッション署名など複数の目的でシークレットを使用することは、単一障害点を生み出します。一つの用途でシークレットが露出すると、そのシークレットに依存する他のすべての保護策が崩壊します。さらに、google-authのような現代的な代替品ではなく、oauth2clientのような非推奨ライブラリを使い続けることは、既知のアンチパターンや脆弱性を新しいインフラストラクチャに持ち込む可能性があります。

報奨金の承認とパッチ展開の間にあった2か月のギャップも、運用上の懸念を引き起こします。Googleは遅延について説明しませんでしたが、ベンダーが欠陥を認識した後、こうした期間はシステムを潜在的な悪用のリスクにさらします。セキュリティ研究者は、特に全体的な影響範囲が不明な場合、暫定的な緩和策が適用されているかどうかを心配することがよくあります。今回のケースでは、攻撃者がGoogleの内部Stubbyサービス間通信システムにアクセスしたり、サプライチェーン攻撃のためにドキュメントコンテンツを変更したりできたかどうかは依然として不明です。

あなたができること

• 署名や暗号化など、異なる暗号機能間でシークレットが再利用されていないか、アプリケーションを監査してください。
• ユーザー由来のデータに対しては、PythonのpickleモジュールをJSONやProtocol Buffersなどの安全なシリアル化形式に置き換えてください。
• oauth2clientのような非推奨ライブラリから、google-authのようなサポートされている代替品に移行してください。
• セッション署名キーが、OAuthクライアントシークレットやその他の認証資格情報とは別のものであることを確認してください。
• コードベース内の安全でない逆シリアル化パターンを検出するための自動スキャンを導入してください。
• 脆弱性修復時間の明確なサービスレベル目標を設定し、露出期間を最小限に抑えてください。