Googleの開発者向けドキュメント基盤「DevSite」に深刻なセキュリティ脆弱性が存在し、認証なしの攻撃者が、悪意あるPythonのpickleペイロードを埋め込んだFlaskセッションCookieを偽造することで、Google運営のサービス上で任意のコードを実行できた可能性があることが分かりました。
セキュリティ研究者のSimon Köck氏がこの問題を発見しました。同氏は、Googleの開発者向けドキュメントサイトが使用するOAuth認可ワークフローを分析する中で、問題に気付きました。
この脆弱性は、developers.google.comをはじめ、Firebase、Android Developer、Android Open Source Project、Partner Androidの各ドキュメントサイトなど、共有インフラ全体に影響していました。Googleは2026年10月7日に問題を修正し、同社の脆弱性報奨金プログラム（Vulnerability Reward Program）を通じて、研究者に9万ドルを支払いました。
Google DevSiteの深刻な脆弱性
攻撃は、developers.google.comの認証不要な/oauth2/authorizeエンドポイントへのリクエストから始まります。このエンドポイントは、OAuthのCSRFトークンとリターンURLに必要な大きさをはるかに上回るFlaskセッションCookieを返していました。
FlaskのクライアントサイドセッションCookieは、整合性を保証するために署名されていますが、デフォルトでは暗号化されません。Köck氏が圧縮されたペイロードをデコードしたところ、セッションにはシリアライズされたOAuthフローのオブジェクトが含まれており、その中にGoogle OAuthのclient_idとclient_secretの値が入っていました。
問題の本質は、OAuth認証情報の露出にとどまらず、さらに深刻でした。OAuthのclient secretが、セッションCookieの署名に使うFlaskのSECRET_KEYとしても使い回されていたのです。
この使い回しにより、client secretを入手した攻撃者は、任意のセッション内容に対して有効な署名を生成できます。その結果、アプリケーションはGoogleが発行した正規のCookieと、攻撃者が細工した悪意あるCookieを区別できなくなっていました。
脆弱なコールバック処理では、署名付きセッションからOAuthフローのオブジェクトを取り出し、その値をBase64デコードして、Pythonの`pickle.loads()`関数に渡していました。
`pickle`によるデシリアライズは、信頼できないデータを扱う際にリスクを伴います。細工されたオブジェクトが、デシリアライズ中にPython関数を呼び出す場合があるためです。
通常であれば、署名付きのFlask Cookieによって、ユーザーがシリアライズされたオブジェクトを改ざんすることはできません。しかし、署名用の秘密鍵がCookie内で露出していたため、信頼境界は崩壊しました。
攻撃者は、制御可能なpickleオブジェクトと、対応するCSRFのstate値を含む偽のセッションを作成できます。サーバーはリクエストを受け取ると、偽造された署名を正規のものとして検証し、悪意あるオブジェクトを取り出してデシリアライズしていました。
研究者はGoogleの本番環境でシステムコマンドを実行してはいません。概念実証（PoC）では`time.sleep()`のペイロードを使用しました。サーバーは、攻撃者が指定した約3秒、5秒、8秒の間隔で応答を遅延させており、与えられたPython関数が実行されたことを示しました。
この脆弱性は単一のドキュメントサイトに限られませんでした。欠陥のあるセッション署名の設定が、GoogleのDevSiteプラットフォーム全体で共有されていたためです。入手した秘密鍵で、以下を含む7つのGoogleドメインに対して有効なセッションを生成できたと報告されています。
- developers.google.com
- firebase.google.com
- developer.android.com
- source.android.com
- docs.partner.android.com
このため、問題は特に深刻でした。認証なしの攻撃者がOAuthフローを開始し、返されたCookieから署名用の秘密鍵を回収して悪意ある代替Cookieを偽造すれば、Googleアカウントがなくてもサーバー側でコードを実行できる状態だったのです。
Köck氏は2026年8月6日にこの欠陥をGoogleへ報告しました。Googleは翌日にトリアージを実施し、同日中に報告を受理しました。8月27日には報奨金9万ドルを決定し、最終的な修正は10月7日に展開されました。
今回の事例は、秘密情報の露出、鍵の使い回し、クライアントサイドでの状態管理、安全でないデシリアライズといった、それぞれ単体でも危険なミスが連鎖すると、認証不要のリモートコード実行（RCE）に至ることを示しています。
MTTRを21分短縮し、サイバー脅威を被害が出る前に阻止。ANYRUNのSandboxをSOCに統合。
翻訳元: https://gbhackers.com/critical-google-devsite-flaw/
