A security researcher decoded a Flask session cookie on developers.google.com and found Google's OAuth client secret sitting in plaintext inside a pickle-serialized object. That alone would be a finding. But the same secret also served as the Flask signing key, meaning anyone who received a cookie could forge one. And the server's callback handler passed the forged payload straight to Python's pickle.loads — a known arbitrary-code-execution sink. Two GET requests, zero authentication, full remote code execution on Google production infrastructure. The chain is elegant in its simplicity. Flask session cookies are signed but not encrypted, so the contents are readable by anyone holding one. The researcher base64-decoded the cookie, zlib-decompressed it, and found an oauth2client.client.OAuth2WebServerFlow object serialized via pickle, containing the clientid and clientsecret in cleartext. The clientsecret doubled as the Flask SECRETKEY, verified by recomputing the HMAC signature offline — byte-for-byte match. One secret doing two jobs meant leaking one capability handed over both. Proof of exploitation was responsible and precise. Rather than executing arbitrary commands, the researcher injected time.sleep(N) payloads via pickle's REDUCE opcode and measured response times: 0 seconds of sleep returned in 207ms, 3 seconds in 3,193ms, 5 seconds in 5,194ms, 8 seconds in 8,283ms. Controls with no cookie, flipped signature bytes, and missing flow entries all returned immediate errors. The timing correlation is unambiguous. The blast radius extended well beyond a single site. The shared DevSite platform meant the same signing key validated sessions across developers.google.com, firebase.google.com, developer.android.com, source.android.com, and docs.partner.android.com. A single compromised cookie from any of these domains would have unlocked code execution on all of them. This is the architectural fragility that comes from shared infrastructure with shared secrets. Google's response was fast by industry standards: triaged within 10 hours, accepted within 18, reward decided in three weeks, fix deployed in two months. The $90,000 bounty — $75,000 base for S0 RCE on a T2 (Normal Google Applications) target, multiplied by 1.2 for exceptional report quality — signals that Google's internal assessment matched the severity. Four remediation steps were required: rotate the exposed OAuth secrets, assign per-deployment high-entropy Flask keys from a server-side store, move OAuth flow objects server-side with only opaque references in cookies, and eliminate pickle deserialization on any client-facing boundary. The deeper lesson is about monoculture and secret reuse. Each individual design decision — pickle serialization, secrets in cookies, one key for signing and OAuth — is a known antipattern documented in security textbooks. The vulnerability existed because four separate teams or decisions never coordinated, and each assumed the adjacent layer provided the safety margin. Any one fix would have broken the chain. The fact that all four had to be absent simultaneously made it feel unlikely, which is precisely why it persisted. This is generative security research at its cleanest. The researcher created new knowledge about a real systemic risk, disclosed responsibly, provided clear remediation steps, and Google paid market rate for the information. The extractive element is minimal — the vulnerability existed because of engineering shortcuts, not because anyone was rent-seeking. The fix makes Google's platform meaningfully more resilient. The writeup teaches the broader community exactly how these chains form.
