Google's $90k bug: OAuth secret reuse and pickle deserialization

Simon Köck, a software engineer at Otark GmbH, discovered a critical remote code execution vulnerability in Google’s DevSite infrastructure in August 2026. The flaw allowed unauthenticated attackers to execute arbitrary code on servers hosting developers.google.com and related documentation sites. Google rated the issue S0, its highest severity level, and paid Köck a $90,000 bounty, yet it took two months to deploy a fix.

What happened

The vulnerability existed in DevSite, the shared platform powering seven Google developer documentation domains. Köck identified that the application stored a serialized OAuth2WebServerFlow object from the deprecated oauth2client library inside a Flask session cookie. This configuration inadvertently exposed the OAuth client secret within the cookie data. More critically, Google had reused this same OAuth client secret as the signing key for Flask sessions.

Because the secret was both exposed in the cookie and used to sign it, Köck could reproduce the signature offline. This allowed him to forge valid session cookies that the server would accept without question. He demonstrated that forged sessions were accepted on all seven affected domains, which relied on two different signing keys. He successfully executed his proof-of-concept code on three of these hosts: developers.google.com, docs.partner.android.com, and web.dev.

Köck confirmed unauthenticated remote code execution by sending a Python sleep payload and measuring the response delays. He deliberately avoided running commands that would touch files, credentials, or internal services to prevent actual damage. Google awarded him a $75,000 base payout for an S0 remote code execution in a normal application tier, multiplied by 1.2 for the exceptional quality of his report.

How it works

The exploit chain relied on three specific security failures aligning simultaneously. First, the application exposed a secret value inside a client-side cookie. Second, that same secret was reused as the cryptographic signing key for the session, allowing an attacker to create valid signatures for modified cookies. Third, the application used Python’s pickle module to deserialize session data during the OAuth callback process.

Pickle is known to be unsafe for untrusted data because it can execute arbitrary code during deserialization. By swapping the legitimate flow object in the cookie with a malicious pickle payload and signing it with the exposed secret, Köck forced the server to execute his code when it processed the session. Fixing any single one of these three issues—hiding the secret, using a separate signing key, or avoiding pickle—would have broken the attack chain.

Key details

• Affected systems: Seven Google developer documentation domains, including developers.google.com, docs.partner.android.com, and web.dev.
• Vulnerability type: Unauthenticated remote code execution via insecure deserialization and key reuse.
• Root cause: Reuse of an OAuth client secret as a Flask session signing key and use of Python pickle for session data.
• Severity: Rated S0 by Google, the highest level on their severity scale.
• Bounty: $90,000 paid to researcher Simon Köck.
• Remediation time: Reported on August 6, 2026; fix deployed on October 7, 2026.

Why it matters

For engineering teams, this incident highlights the dangers of cryptographic key reuse and legacy library dependencies. Using a secret for multiple purposes, such as authentication and session signing, creates a single point of failure. If one usage exposes the secret, all other protections relying on that secret collapse. Additionally, continuing to use deprecated libraries like oauth2client instead of modern alternatives like google-auth can introduce known anti-patterns and vulnerabilities into new infrastructure.

The two-month gap between the bounty approval and the patch deployment also raises operational concerns. While Google did not explain the delay, such windows leave systems exposed to potential exploitation after the vendor is aware of the flaw. Security researchers often worry about whether interim mitigations are applied, especially when the full blast radius is unknown. In this case, it remains unclear if the attacker could have accessed Google’s internal Stubby service-to-service communication system or modified documentation content for supply-chain attacks.

What you can do

• Audit your applications for any reuse of secrets across different cryptographic functions, such as signing and encryption.
• Replace Python’s pickle module with safe serialization formats like JSON or Protocol Buffers for any data originating from users.
• Migrate away from deprecated libraries, such as oauth2client, to supported alternatives like google-auth.
• Ensure session signing keys are distinct from OAuth client secrets and other authentication credentials.
• Implement automated scanning for insecure deserialization patterns in your codebase.
• Establish clear service-level objectives for vulnerability remediation times to minimize exposure windows.